[Openmcl-devel] New snapshots available

[Gary Byers]

All that I know about the ObjC 2.0 GC is what's in Apple's Leopard
documentation (i.e., virtually nothing interesting or useful).  To
be fair to Aoole, I wouldn't expect there to be wide demand for
a "How to get your GC and ours to cooperate" document.

Apple does release source to some of of their libraries; as I
understand it, an early version of the library that implements their
ObjC GC was actually shipped as part of Tiger, apparently because a
few applications quietly tried to use it (or perhaps just some
functionality it provides).  I can't remember the name of that library
at the moment, but when I first heard this story I looked for its
source on the Darwin opensource site and didn't find it.  I don't
know if or when Apple plans to release source to that library.  (And
it's "libauto.dylib", btw.)

One of the things that the lisp should do if it ever hopes to 
work correctly with ObjC GC is to ensure that a store of an :ID-valued
instance variable (via (SETF SLOT-VALUE)) goes through the ObjC
runtime to enforce the generational GC write-barrier.  The runtime
function that handles this kind of assignment doesn't do much of
anything when the ObjC GC is disabled and - outside of initialization -
it's probably pretty rare to do this sort of kind of assignment, so 
doing a call into the runtime instead of a (SET (%GET-PTR ...)) wouldn't
cost too much.

Beyond that, questions like "how if at all can the ObjC GC be
persuaded to look at the stacks of lisp threads - and possibly at the
lisp heap- to find references to GCable ObjC objects ?" are hard to
answer at this point.  It'd obviously be good to have answers to
those questions and it'd obviously be good to (someday) have the
GCs cooperating.

The testing that I did that enables me to say "well, basic ObjC
bridge/ObjC 2.0 stuff seems to work under Leopard" depends on
having 64-bit ObjC 2.0 interface definitions, which in turn
depends on a version of the interface translator that understands
ObjC 2.0, which in turn depends on version of GCC that provides
that support and also supports x86-64 on Darwin.  I was able
to combine a few different publically available sets of GCC sources
into something that seemed to work, and I need to package that up
and release it somehow.  I tried to avoid distributing Leopard
interfaces with the last snapshots (because I'm not sure of the
legality of doing so), but it should be possible to distrbute
a modified version of GCC (whose sources are all GPLed) that
would enable people who have access to Leopard prereleases to
generate lisp interfaces from Leopard header files.

On Wed, 14 Feb 2007, Rainer Joswig wrote:

> In article <20070214032600.J57842 at clozure.com>,
> Gary Byers <gb at clozure.com> wrote:
>
>> There are now new (070214) self-contained archives containing OpenMCL
>> source, binaries, and interfaces for DarwinPPC32/64, LinuxPPC32/64,
>> DarwinX8664, LinuxX8664, and FreeBSDX8664 available in
>> <ftp://clozure.com/pub/testing>.  The release notes entry says:
>>
>> OpenMCL 1.1-pre-070214
>
> Cool stuff. I have to check it out under Leopard.
>
> As GC is an announced feature of Objective C, do you have an
> idea/opinion if the Objective-C GC would make the Cocoa bridge and Cocoa
> using OpenMCL code simpler? In theory one should be able to get rid with
> release/retain stuff. Would it be useful to support GCed Cocoa with
> OpenMCL?

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