[Openmcl-devel] DeLurking...

[Gary Byers]

On Mon, 7 Feb 2005, Brent Fulgham wrote:

>
> --- I wrote:
>
> > > So, I'm interested in writing applications for
> > > OS X in Lisp, but I'm not sure what resources are
> > > out there for picking this up.  The Bosco
> > > framework looks promising, but perhaps there are
> > > better choices.
> >
>
> --- Dan Knapp <dankna at accela.net> wrote:
> >    Well, to write native apps you'll need to learn
> > the Cocoa API, if you aren't already familiar with
> > it from other languages.
>
> [ ... snip useful links ... ]
>
> Thanks for the references.  I've read through them,
> and had a couple of initial questions that perhaps
> some of you can answer:
>
> 1.  The documents indicate that the (require 'COCOA)
> takes several seconds to perform.  Launching hemlock
> is certainly slow (in fact, I thought I had made
> an error building it and was thinking about killing
> the session when it finally popped up!)
>

The element of surprise ...

> However, Alpaca is very quick to start up.  Is this
> some selective importing on Alpaca's part (avoiding
> the need to bind all of those symbols)?  Or, is the
> slowness just a by-product of dynamically creating
> the linkage from Obj-C to Lisp (which probably isn't
> done in a compiled application).
>

I believe that Alpaca may have been based on earlier versions of the
Cocoa bridge, where there was less ObjC<->CLOS integration (which
is good news and bad.)

> 2.  A more to-the-point rephrasing of Question #1:
> Will a compiled image of an application in OpenMCL
> suffer the same slowness in launching that the
> listener does?
>
> 3.   I see lots of lamentations about updates of OS X
> causing applications using the Obj-C bridge to fail.
> Can anyone provide the 5,000 foot overview of why
> this happens?  Is it like trying to link against the
> wrong version of a C library?  (I.e., OS X 10.4 has
> probably modified some function signatures, etc.  Is
> this the cause of the problem)?

The Cocoa bridge currently works by introspection: it asks the
Objective C runtime for information about every ObjC class (at least
those in AppKit and Foundation) and builds CLOS metainformation about
every class (and every instance variable/slot of every class) and
records type- signature and other information about every method.

This is a time-consuming process (it's possible that it could be sped
up some, but I doubt that anyone's really tried).  The end result of
the process is that there's a fairly complete and fairly deep model of
the Cocoa class hierarchy, as it's implemented in a particular version
of the AppKit and Framework libraries (in particular, there's tons of
information about internal, undocumented classes, methods, and slots.)

If you save an image that contains all of this metainformation
(assuming that that isn't broken for some other reason ...) and try to
run that in an environment in which there are slightly different
versions of those libraries installed, then reconciling the saved
metainformation with reality is a potentially complicated and
time-consuming process.  (Even if there aren't major API changes
between different minor releases, there are often minor changes
in the large layer of undocumented classes, methods, and slots.)
Rather than even trying to attempt this reconciliation, the bridge
compares the runtime library version numbers with those in effect
when the image was saved and give up if they differ.  (It's very
common for AppKit and/or Foundation version numbers to change between
dot releases - 10.3.x and 10.3.y.)

The general plan (and it's been the plan for about a year now ...)
is to modify the interface translator to save information about
ObjC classes and methods and to use that information (the exported,
documented API) to build the CLOS metainformation.  That's likely
to be somewhat faster (if only because substantially fewer classes/
methods/instance variables are involved), might be more incremental
(we -might- not have to know much about a method's type signature
until we need to compile a call to it) and would likely be less
sensitive to arcane and obscure differences between minor releases.
(There may be some other advantages to this approach: it's currently
necessary to have opened the Cocoa libraries - and done the massive
introspective import - before it's even possible to compile code
which uses the ObjC bridge.)

>
> 4.  Finally, does anyone have any small Cocoa apps
> written with the Obj-C bridge that I could look at for
> educational purposes?
>
> Thanks,
>
> -Brent
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>