[Openmcl-devel] COCOA IDE, Libraries and Frameworks

alex crain alexcrain at mail2.widgetworks.com
Thu Nov 4 16:14:51 PST 2004

I've gotten hemlock and the IDE to a position of relative stability - 
it doesn't crash very often and behaves predictably most of the time. 
It still needs a better feature set to compete with Slime, but it 

I want to do a couple of things before I actually push it back to the 
community. First I want to add two new packages to the system: "COCOA" 
and "IDE". The former would get all the COCOA/CLOS Bridge code and 
would be available for inclusion in applications while the latter would 
be IDE specific and would be used by the development environment. From 
there I want to add the ability to create COCOA apps, ala XCode.

The last bit means overcoming the problem where dumped images are OS 
version specific. My  idea is to create a way to generate bundles, 
where the executable is a simple bootstrap application that sets up the 
environment variables and then execs the lisp binary which loads that 
standard image (a compiled version of the openmcl shell script). The 
bootstrap loader would then instruct the lisp environment to load a 
boot.lisp file that would look like this:

(require "COCOA")

This works reasonable well in my prototype, although boot time is a bit 

My test application works because the lisp kernel, the image and the 
library files are all part of the application bundle. That doesn't make 
much sense, however, since the only application specific code is 
boot.lisp and the application package. I'm thinking that whats needed 
is a framework that would contain the lisp binary, image and libraries. 
Applications would then "link" to the framework at runtime and would be 
otherwise identical to normal obj-c apps.

I can assemble all this stuff, of course, but I wanted to brain dump 
here and take some input from the rest of the group. Frameworks and 
bundles are darwin specific and the linux folks should have their say, 
although something similar would work with linux for making GTK based 

We should probably consider some kind of version identifiers as well, 
so that applications could load specific versions of the system 
libraries if they should feel the need.


More information about the Openmcl-devel mailing list