SDL on OSX

(ql:quickload 'lispbuilder-sdl) worked right away on an ubuntu box, but failed (couldn’t find `cocoahelper) when I tried the sam on my Macbook.

The fix is to install SDL, then go to ~/quicklisp/dists/quicklisp/software/lispbuilder-20140113-svn/lispbuilder-sdl/cocoahelper and type make. After this, the ql:quickload form succeeds.

However, the same dummy blank screen test program that worked fine on the linux box doesn’t seem to work anymore:

(defpackage :simple-sdl
  (:use :common-lisp
    :lispbuilder-sdl))

(in-package :simple-sdl)

(defun main-screen ()
  (sdl:with-init ()
    (sdl:window 300 300
        :title-caption "Simple SDL"
        :icon-caption "Simple SDL")
    (sdl:with-events ()
      (:quit-event () t)
      (:key-down-event ()
               (sdl:push-quit-event)))))

It fails with this backtrace:

Backtrace:
  0: ("bogus stack frame")
  1: ("foreign function: CGSScanconverterRenderRGBMask")
  2: ("foreign function: create_rgb_bitmap")
  3: ("foreign function: CGGlyphBitmapCreateWithPath_32")
  4: ("foreign function: CGFontCreateGlyphBitmap")
  5: ("foreign function: _ZN14CGGlyphBuilder22create_missing_bitmapsEPK17CGGlyphIdentifiermPPK13CGGlyphBitmap")
  6: ("foreign function: render_glyphs")
  7: ("foreign function: draw_glyph_bitmaps")
  8: ("foreign function: ripc_DrawGlyphs")
  9: ("foreign function: draw_glyphs")
 10: ("foreign function: CTFontDrawGlyphsAtPositions")
 11: ("foreign function: -[CUITextEffectStack drawGlyphs:inContext:usingFont:atPositions:count:lineHeight:inBounds:atScale:]")
 12: ("foreign function: -[CUICatalog drawGlyphs:atPositions:inContext:withFont:count:stylePresetName:styleConfiguration:foregroundColor:]")
 13: ("foreign function: -[NSLineFragmentRenderingContext drawAtPoint:inContext:]")
 14: ("foreign function: _NSStringDrawingCore")
 15: ("foreign function: _NSDrawTextCell")
 16: ("foreign function: -[NSTitledFrame _drawTitleStringIn:withColor:]")
 17: ("foreign function: -[NSThemeFrame _drawTitleStringInClip:]")
 18: ("foreign function: -[NSThemeFrame drawFrame:]")

Just when I was getting excited about it … so what other platform-independent Lisp GUI should I use 😦 ?

BTW, while we’re knocking this (unfairly, of course), I should point out it doesn’t support SDL 2.x

I then stumbled on this library which seemed better maintained, and modified my example:

(defun main-screen ()
  (sdl2:with-init (:everything)
    (sdl2:with-window (win :w 300 :h 300
               :title "Simple SDL")
    (sdl2:with-event-loop (:method :poll)
      (:quit () t)
      (:keydown ()
        (sdl2:push-quit-event))))))

Now a window did get created, but it didn’t play well with OSX (it wasn’t a “window” so much as a blank square of real estate on the screen, with a spinning beachball and no response).

So … the search for a basic simple drawing facility continues 😦

Alan Kay: The Computer Revolution Hasn’t Happened Yet

Watching this amazing video by Alan Kay, at OOPSLA 1998.

It starts off fairly normal, with some reminiscing about Smalltalk, but then slowly spirals onward and upward, generating one BIG insight after another. Here are just a few extracts — but think of this as a trailer, it’s no substitute for watching the talk itself.

The realization here—and it’s not possible to assign this realization to any particular person because it was in the seeds of Sketchpad, and in the seeds of [the] air training command file system, and in the seeds of Simula. That is, that once you have encapsulated, in such a way that there is an interface between the inside and the outside, it is possible to make an object act like anything.

 

The reason is simply this, that what you have encapsulated is a computer. You have done a powerful thing in computer science, which is to take the powerful thing you’re working on, and not lose it by partitioning up your design space. This is the bug in data and procedure languages. I think this is the most pernicious thing about languages a lot like C++ and Java, is that they think they’re helping the programmer by looking as much like the old thing as possible, but in fact they are hurting the programmer terribly by making it difficult for the programmer to understand what’s really powerful about this new metaphor. People who were doing time-sharing systems had already figured this out as well. Butler Lampson’s thesis in 1965 was about what you want to give a person on a time-sharing system, is something that is now called a virtual machine, which is not the same as what the Java VM is, but something that is as much like the physical computer as possible, but give one separately to everybody.

 

UNIX had that sense about it. The biggest problem with that scheme is that a UNIX process had an overhead of about two thousand bytes just to have a process, and so it was going to be very difficult in UNIX to let a UNIX process just be the number three. You would be going from three bits to a couple of thousand bytes, and you have this problem with scaling. A lot of the problem here is both deciding that the biological metaphor is the one that is going to win out over the next twenty-five years or so, and then committing to it enough to get it so it can be practical at all the levels of scale we actually need.

 

Here’s one we haven’t faced up to much yet, that, now we have to construct this stuff and soon we’ll be required to grow it. It’s very easy, for instance, to grow a baby six inches. They do it about ten times in their life and you never have to take it down for maintenance. But if you try and grow a 747, you are faced with an unbelievable problem, because it’s in this simple-minded mechanical world, in which the only object has been to make the artifact in the first place. Not to fix it. Not to change it. Not to let it live for a hundred years.

 

There is not one line of code in the Internet today that was in the original ARPANET. Of course, if we had IBM main frames in the original ARPANET, that wouldn’t have been true. This is a system that has expanded by a hundred million, has changed every atom and every bit, and has never had to stop. That is the metaphor we absolutely must apply to what we think are smaller things.

 

This notion of meta-programming. Lots of different ways of looking at it. One of them is that, any particular implementation is making pragmatic choices, and these pragmatic choices are likely not to be able to cover all of the cases, at the level of efficiency, and even at the level of richness required. Of course, this is standard OOP lore. This is why we encapsulate. We need to hide our messes. We need to have different ways of dealing with the same concepts in a way that does not distract the programmer. But in fact, it is also applicable, as the LISP people found, and we at Xerox PARC found; you can also apply it to the building of the language itself. The more the language can see its own structures, the more liberated you can be from the tyranny of a single implementation. I think this is one of the most critical things that very few people are worrying about in a practical form.

 

What they missed was, to me, the deepest thing I would like to communicate with you today, and that is we don’t know how to design systems yet. Let’s not make what we don’t know into a religion, for God’s sake. What we need to do is to constantly think and think and think about what’s important. We have to have our systems let us get to the next levels of abstraction as we come to them.

… and my favorite one:

When we think programming is small, that’s why your programs are so big. That’s why they become pyramids instead of gothic cathedrals.

However, given some massively inferior “tools”, you can get sufficient challenge and fun out of a day’s work that you never get your head above the water and see what is really going on: An industry-wide job-creation racket …

… you would realize at least one of several really uncomfortable things: (1) The way people store “information” in files is so approximate as to make you crazy, (2) Those who use databases usually do so because they master no data structures of their own, and (3) Programming for the Web is so insanely boring and incredibly worthless work that you would find yourself inventing at least one new language to do it for you.

Hash table utilities

People have referred to the usage of hashtables in ANSI common lisp as archaic. This isn’t necessarily true, but if you do feel this way there’s no need to stick with it. Here’s an example of how “radical utils” can simplify your life.

> (setf myhash (hash-table-from-alist '((apple . 2) (berry . 5) (lemon . 1))))
#<HASH-TABLE :TEST EQL :COUNT 3 {10060EA0B3}>
> (let ((acc 0))
          (dotable (_ val myhash acc)
        (incf acc val)))
8
> (print-hash-table myhash)
#{
  APPLE 2
  BERRY 5
  LEMON 1
 } 
#<HASH-TABLE :TEST EQL :COUNT 3 {10060EA0B3}>

So, converting from an alist or a plist to a hash table is straightforward, as is iterating over it (notice the use of _ for the ignored “key” value).

(I’m slowly working my way through the (https://github.com/vseloved/rutils), so I hope it’s ok to post little snippets like these as I go along, even though this is a blog and I really should gather them up together. OTOH if I wait that long I’ll never get around to it)

Another nice thing about Suns is their simplicity. You know how a LispM is always jumping into that awful, hairy debugger with the confusing backtrace display, and expecting you to tell it how to proceed? Well, Suns ALWAYS know how to proceed. They dump a core file and kill the offending process. What could be easier? If there’s a window involved, it closes right up. (Did I feel a draft?) This simplicity greatly decreases debugging time because you immediately give up all hope of finding the problem, and just restart from the beginning whatever complex task you were up to. In fact, at this point, you can just boot. Go ahead, it’s fast!

Lisp is dead ? No, just lispers.

Came across this quote from the “Naggum-mine”:

An uncomfortable answer is that the Common Lisp community is hostile to creativity. People argue that Lisp is dead, but it is the Lispers who are dead. With a few exceptions, people who use Lisp have given up, and they only require, they do not provide.

Many Lisp programmers demand that sockets and multiprocessing should be standardized before they want to use it, which penalizes creativity like nothing else. Many Lisp programmers think it sucks to interface with other (inferior) languages, some in general, some because it isn’t standardized, some because they fail to understand how software is organized and want a perfect world.