[Openmcl-devel] apple-objc.lisp and %associate-jmp-buf-with-catch-frame

[Gary Byers]

On Mon, 22 Dec 2003, John Wiseman wrote:

> Hi, I'm not sure if maybe this was fixed recently, but it looks like
> apple-objc.lisp uses %associate-jmp-buf-with-catch-frame without
> requiring objc-support.lisp, which is where that function is defined.
>
>

apple-objc.lisp recently got renamed to objc-runtime.lisp, but there are
still circular dependencies among/between it and (at least) bridge.lisp
and objc-support.lisp.

If you do (require "OBJC-SUPPORT") as "cocoa.lisp" does, all of these
dependencies should get resolved.  That typically involves loading a
set of .lisp files, and I suppose that it might take slightly longer
to load them than it would to load a corresponding set of fasl files.
Compiling these files (via COMPILE-FILE) might expose thsee
dependencies in differnt ways.

Setting things up so that this set of files could be compliled before
being used is tricky (or at least seemed to be the last time I tried
or thought about it.)  A lot of information about Objective C classes
and methods needs to be imported from the shared libraries in order
for things like SEND to work, and the way that the Cocoa demo tries
to fool these libraries into thinking that they're being loaded by
a bundled application makes the business of opening these shared
libraries a little more complicated than it would otherwise need to
be.

I've always assumed that whatever effort would be involved in getting
these files to compile would have minimal impact on startup time, and
that most of the time between (require "COCOA") and the appearance of
a barely functional listener window was being spent in foreign code
anyway (loading a few dozen other shared libraries, connecting to
the window server, reading .nib files, etc.)  Ordinarily, we'd have
a bouncing dock icon to distract us while all of this is going on ...

Summary:

a) doing

? (require "OBJC-SUPPORT")

should load all of the low-level ObjC stuff, which is contained in
a handful of files that are somewhat interdependent.

It's currently necessary to define *DEFAULT-BUNDLE-PATH* and
*DEFAULT-BUNDLE-EXECUTABLE-PATH* before doing this, in order to
trick some of the code in the Core Foundation library into using
the right bundle ("cooca.lisp" tries to use the "OpenMCL.app"
bundle.)

b) compiling these "support" files before loading them (which you
may or may not have been asking about) is at least somewhat tricky
and it's not clear that it'd offer much benefit.

Mikel Evins has been working on a different approach to Cocoa
application development: in his "Bosco" system (see http://evins.net)
he creates a skeletal bundle, copies a Cocoa-aware lisp image into
that bundle, then incrementally turns the prototype application into
something ... less prototypical.  There may be some tradeoffs
involved, but his approach certainly avoids the "pretend I'm over here"
*DEFAULT-BUNDLE-EXECUTABLE-PATH* nonsense ...



> Thanks,
> John Wiseman

I hope that something in this message actually answered your question.

>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>