[Openmcl-devel] Re: Status of Cocoa under Tiger?

[Gary Byers]

On Wed, 11 May 2005, Raffael Cavallaro wrote:

> I was wondering what the status of the Cocoa bridge is under Tiger. I've 
> tried accessing the bleeding edge tree via cvs, but repeatedly failed - I can 
> login, but any attempt to get ccl in the ccl-0.14-dev tree just  spins its 
> wheels endlessly with no result. I've managed to download the bleeding edge 
> sources via the view-cvs web interface, but make fails. Is it just that the 
> sources are in an inconsistent state now? Admittedly I haven't tried too 
> recently - my last attempt was about a week ago.

As far as I know, the CVS server works.

The bleeding-edge tree is pretty volatile these days (keep telling yourself:
"that's a GOOD thing.")  I try to put up bootstrapping images every few days.
The FASL version has changed a couple of times since 0.14.3; even if it
doesn't officially change, it's a good idea to delete old FASLs before
recompiling.

>
> Anyway, I was just wondering how I could get started with Cocoa development 
> under Tiger as openmcl 0.14.3 barfs on (require 'cocoa).

The bleeding-edge stuff that'll become 0.14.4 includes new interface
databases, which in turn include information about ObjC classes and methods
derived from the header files.

The Cocoa bridge has historically derived this info via introspection.  That:
(a) is a little slow 
(b) means that the model is tied to the information in a particular
     dot-releases' libraries.
(c) depends on the ability to parse ObjC type strings.  Some Tiger classes
     and methods contain type encodings that the bridge can't parse, either
     because the ObjC compiler used to build the libraries encodes things
     a little differently than older C compilers did or because the Tiger
     libraries simply contain different constructs.

The Cocoa bridge in the bleeding-edge tree uses the interface database
information to derive informations about ObjC classes and to implement
SEND when the message name is known at compile time.  That seems to
be enough to allow the demo IDE to run under Tiger; there are still
some cases (MAKE-INSTANCE, MAKE-OBJC-INSTANCE) that use the old scheme,
and I haven't gotten around to fixing them yet.

> As long as I'm pestering with questions, is there any notion of
> when an  openmcl Mac OS X app will not require recompilation for
> each point release of  Mac OS X? Is there any way one could help
> this process along? I'm happy to apply my limited skills to this
> effort if they would be of any use.

At least in theory, the new approach (using the interface database rather
than introspection to build the bridge's model) should be less sensitive
to minor dot-release changes and should make it easier to deal with
major version changes.

In practice, there's at least one mundane problem involved in saving
Cocoa based images (at least when the Hemlock stuff is involved): Hemlock's
list of all globally named buffers isn't cleared out properly when an
image is saved, so attempts to create a buffer named "Listener" in the
new image signal an error (and attempt to create a buffer named "Listener"
to report this error.)  I may be misremembering the details, but I'm
pretty confident that the problem was about this stupid/mundane, and
that there was a lot of stack-overflowing going on.

[There's also an issue with an early call to #_GetCurrentEventQueue
that seems to cause problems on 10.3.9; it doesn't seem to be necessary
on 10.3.8 or on 10.4, but I haven't tried early 10.3 dot releases.]

>
> Thanks in advance for any insights into this,
>
> warmest regards,
>
> Raffael Cavallaro, Ph.D.
> raffaelcavallaro at mac.com
>
>