[Openmcl-devel] COCOA IDE, Libraries and Frameworks
alexcrain at mail2.widgetworks.com
Fri Nov 5 00:14:51 UTC 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:
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