[Openmcl-devel] New snapshots available

[Phil]

On Feb 14, 2007, at 7:18 PM, Gary Byers wrote:

>
>
> On Wed, 14 Feb 2007, Phil wrote:
>
>> Gary,
>>
>> Great to see progress on supporting Leopard/Obj-C 2.0.  I did have  
>> a couple of questions re: the release notes...
>>
>> On Feb 14, 2007, at 5:32 AM, Gary Byers wrote:
>>
>>> - There are new interface files for all platforms.  These files
>>>   encode some foreign type information a little differently
>>>   than older ones did (notably information about foreign functions
>>>   that return structures or accept structure args by value.)  The
>>>   new .cdb files can't be used by older versions of OpenMCL; using
>>>   older .cdb files with this version is "allowed, but not supported
>>>   or recommended."
>>
>> Do any of the changes made address the issue of multiple  
>> signatures for a method (i.e. size, display, etc.) which result in  
>> ambiguous return types?
>
> The bug that I'm aware of has to do with the fact that SEND considers
> the set of method type signatures in effect when it's used to be  
> closed,
> so if "foo" is a message declared to return :int at some point in  
> time,
> a (SEND x 'foo) will compile to something that expects an integer
> to be returned and doesn't expect any sort of ambiguity.
>
> If new interfaces are loaded (after that first SEND was compiled) and
> some disjoint class defines a method on FOO that returns :FLOAT, then
> any subsequent SEND -should- consider the message to have an ambiguous
> type signature and should expand into code which does runtime  
> typechecking
> of the receiver and does a CASE or COND or something to select the
> right implementation.
>
> The original SEND - compiled in a simpler world - won't get  
> recompiled.
>
> Is this what you're referring to ?  Or are there other cases which
> lose ?
>

That would be the issue as I've generated CDB's for many additional  
frameworks which work flawlessly for all methods which don't result  
in the ambiguous return type scenario.  All releases I've tried  
including OpenMCL 1.1-pre-061024, do not appear to be successful in  
performing the runtime check so, effectively these ambiguous methods  
become uncallable.

>>
>>> - The ObjC bridge has had a long-standing bug whereby a standalone
>>>   Cocoa application may have needed to find the interface databases
>>>   at runtime in order for MAKE-OBJC-INSTANCE and MAKE-INSTANCE of
>>>   an ObjC class to work.  (These functions needed to be able to
>>>   send an "init" message to the newly-allocated instance, and needed
>>>   to know the type signature of that init message in order to do  
>>> that.)
>>>   The current scheme tries to avoid this by pre-compiling helper
>>>   functions to enable calling all known "init" message signatures.
>>>   (More accurately, all fixed-argument "init" message signatures.)
>>>   This scheme avoids the need to send messages whose argument
>>>   and result types are computed at runtime (via %SEND), and %SEND
>>>   (a) was known to be inefficient and (b) would have a lot of
>>>   difficulty handling all known structure return/passing conventions
>>>   on supported platforms.  Accordingly, %SEND has been deprecated
>>>   (with extreme prejudice, e.g., removed.)
>>
>> Ugh... I was using %SEND.  Is there a way to accomplish the  
>> following without %SEND: take an arbitrary object (unknown at  
>> compile-time), either look at the type of the object or a list of  
>> methods for the object, and call a series of methods belonging to  
>> a list or matching a pattern?
>
> Yes (at least in theory); the general idea would be to do something
> similar to what's done for "init" methods now (try to map a signature
> to a compiled helper function that knows how to do ff-calls of that
> signature, maybe create that function at runtime if it didn't  
> already exist, and funcall the helper function.)
>
> %SEND basically tried to build the arguments to to CCL:%FF-CALL and
> call it.  That worked reasonably well on ppc32 Darwin (it was at
> least Turing-complete), since sending a message ultimately just
> involved doing a foreign function call and making sure that the
> arguments and result wound up in the right place.  On other platforms,
> dealing with structure arguments/return values requires a lot of
> additional complexity wrapped around the (simple) foreign function  
> call,
> and it'd be difficult for %SEND (or something like it) do decide what
> to wrap around that call and how to do it.

Thanks for the information... I didn't realize that %SEND would cause  
such grief on other platforms.  I'll look into going the helper  
function route.