[Openmcl-devel] Deploying Cocoa Apps

[Gary Byers]

On Thu, 2 Mar 2006, Francesco Pierfederici wrote:

> Hi,
>
> I am in the process of learning Lisp (coming from Python/C++) and
> have chosen a simple project just to get my hands dirty. The idea is
> to rewrite one of my Cocoa applications (currently in Python) in Lisp
> using OpenMCL.
>
> Looking at the documentation and at the mailing list archives I came
> up with what seems to be a contradiction:
>
> http://openmcl.clozure.com/Doc/Building-an-Application-Bundle.html
>> Because of the way that the ObjC bridge currently works, a saved
>> image is dependent upon the exact versions of the Cocoa libraries
>> which were present when it was saved. Specifically, the interface
>> database is. So, for example, an application produced under OS X
>> 10.3.5 will not work under OS X 10.3.6.
>
> Whereas this:
> http://clozure.com/mailman/htdig/openmcl-devel/2005-May/002726.html
> seems to imply the opposite.
>
> Which one is true? I guess I could try out for myself, but the
> practicalities of such a test would be non trivial for me (all the
> Mac OS X boxes I have access to run the same version of Tiger).

The email message is closer to the truth.

Prior to version 1.0 (which the email message referred to as
"0.14.4"), information about ObjC classes and methods was obtained via
introspection (e.g., by asking the runtime to enumerate everything,
including obscure, internal, undocumented things that change between
minor releases.  It would have been difficult to reconcile differences
between the view of the ObjC world that was formed when an applicaton
was built and the reality that the application found itself in when it
was run under a different OS release.  (At least part of the
difficulty had to do with the fact that there was no good way of
knowing which differences were "obscure internal" ones and which were
somehow of critical importance.)

The approach used in the Cocoa bridge in 1.0 avoids that problem by
building its model of what ObjC classes and methods exist by using
the header files (the headers distributed with 1.0 for OSX 10.3 and
described functionality common to 10.3 and 10.4).  That happens to
be a much smaller model and a much more stable one, and that approach
avoids the OS-release dependencies that the docs should be updated
to say are no longer relevant.

There are some tradeoffs: using Cocoa add-on libraries is possible,
but harder than it needs to be.  There's an example that uses the
WebKit framework that's distributed with 1.0 that seems to work,
but people who've tried using other frameworks have found that it's
necessary to jump through more hoops than were necessary to jump
through when you could just say "new libraries have been loaded,
go learn about their classes and methods."

There's also a stupid bug that I don't think has been fixed in the
main CVS tree: although a saved application will adjust the addresses
of ObjC classes that it knows about (those addresses may have changed
if the application was saved under a different OS release than it's
run under), the startup code neglects to do the same thing for the
ObjC metaclass pointers.   This causes an obscure and misleading
"class not found" error if the saved application tries to define
new classes at runtime.  (It might also affect saved applications that
try to define new class methods at runtime; I don't think that it
affects applications that just use the classes and methods that were
defined when it was built.)

The fix to that is (IIRC) fairly simple; remembering to check it in
to CVS is the hard part ...



>
> Thanks for any information you can give me on this!
>
> Cheers
> fra
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>