[Openmcl-devel] Building on a G5

[flip phillips]

On Apr 7, 2005, at 7:43 PM, Gary Byers wrote:

>
>
> On Thu, 7 Apr 2005, flip phillips wrote:
>
>> On Apr 7, 2005, at 5:49 PM, Gary Byers wrote:
>>
>>> On Thu, 7 Apr 2005, flip phillips wrote:

> Privately then: 0.14.3 (the released and -dev versions) should run
> fine under Tiger, with the unfortunate exception of the Cocoa demo.

I cannot provide evidence to the contrary : ) (that's NHST / NDA 
compatible speak)

>> Now- as for Hemlock / the IDE, compiles fine, but subsequent loading
>> of 'cocoa':
>>
>> ? (require "COCOA")
>> Unhandled exception 11 at 0x90000c18, context->regs at #xbfffe718
>> Read operation to unmapped address 0x0000000c
>> In foreign code at address 0x90000c18
>>
>
> Was this under Tiger or Panther ?  (I don't think that things even
> get that far under Tiger; GCC 4.0 encodes ObjC types a little 
> differently,
> and the Cocoa bridge has difficulty making sense out of some things.)
>
> Things -should- work under Panther; the address above looks like
> something may be trying to send a message to a non-object.

This is under Panther on a G5

Under Tiger it seems to get this far and complains about not seeing an 
ObjC ARRAY type if I recall (Tiger is on a laptop machine that isn't 
with me right this second.) which makes sense from your above note.


>> which looks a little nastier. is this possibly related to the foreign-
>> function database? I haven't had the time/guts to play with ffigen
>> yet (which I am presuming generates the catalogs?)
>
> ObjC methods and instance variables have "type strings" associated
> with them; a method parameter or ivar whose type string is "i" is
> of type "int", for instance.  Once we get beyond "i is for int", it
> starts to get a lot more complicated, and the cocoa bridge has 
> difficulty
> parsing some of the encodings produced by GCC 4.0.

gotcha. makes sense.

> Even if/when this parsing works, it's slow, and the good news and the
> bad news is that it provides an incredibly detailed model of how every
> class and method in the Cocoa libraries is implemented (including lots
> of internal classes and methods whose implementation may change in
> minor ways between dot releases.  If a saved image runs in a slightly
> different OS release than it was saved from, some of the details
> (probably unimportant, obscure, internal details) of its model may be
> inaccurate.

ahh- well, then the dot-release level of 10.3 may be relevant here 
maybe?

[...]
>
> Once that's done, there's some more work involved in getting the ObjC
> bridge to use this information (instead of relying entirely on
> introspection as it currently does.)  I -think- that it makes more
> sense to work on that than it does to put a lot of effort into trying
> to fix the type-string parser (though the fixes involved probably 
> aren't
> too complicated.)

wowza!
interesting and more complicated than I thought, yet it makes sense to 
a first approximation.

-- 
flip phillips, phd
http://www.skidmore.edu/~flip/