[Openmcl-devel] Missing header(s) for OpenGL FFI?

Phil pbpublist at comcast.net
Fri Aug 11 23:23:53 PDT 2006


I attempted to switch back to the new interfaces and now have a new  
problem compiling a new method (Error in process listener(1): Error  
reporting error.  While executing: CCL::FUNCALL-WITH-ERROR-REENTRY- 
DETECTION) so I'm thinking that the problem might be a version  
mismatch between the image (1.0) I'm using and interfaces  
downloaded.  If this seems the likely source of my problems, which  
versions of the test images and interfaces should I be downloading  
for PPC-32 for Tiger?


On Jul 23, 2006, at 4:03 AM, Gary Byers wrote:

> I'll try to take a look at it; I'm skeptical that anything's actually
> defined differently and there may be some other bug at play here.
> On Sat, 22 Jul 2006, Phil wrote:
>> Apologies for muddying the water with the NSString... I was mainly
>> asking about NSAttributedString which does appear to be an issue
>> since the Tiger Interfaces:
>> ; New interfaces (060620 Darwin interfaces)
>>                            'NS-ATTRIBUTED-STRING
>>                            :INIT-WITH-STRING
>>                            "testing")
>>                           'SIZE))))
>> "testing")
>> 'SIZE)
>> [Condition of type SIMPLE-ERROR]
>>                                                'NS-ATTRIBUTED-STRING
>>                                                :INIT-WITH-STRING
>>                                                "testing")
>>                                              'SIZE)))))
>> ; Old interfaces (Tiger Cocoa interfaces)
>>                             'NS-ATTRIBUTED-STRING
>>                             :INIT-WITH-STRING
>>                             "testing")
>>                            'SIZE))))
>> NIL
>>                                               'NS-ATTRIBUTED-STRING
>>                                               :INIT-WITH-STRING
>>                                               "testing")
>>                                              'SIZE)))))
>> On Jul 16, 2006, at 8:49 PM, Gary Byers wrote:
>>> AFAIK, NString has never had or inherited a "size" method.
>>> NSAttributedString defines such a method, as do a few other classes.
>>> All of the size methods that're defined in the standard Cocoa  
>>> headers
>>> have the same type signature; this means that - with only those
>>> headers
>>> in effect - a SEND of a "size" message to any object will use that
>>> common type signature (and arrange to "return" an NSSize.)  This
>>> has to do with what SEND macroexpands into; sending a message to
>>> an object that doesn't implement it generally results in a runtime
>>> error.
>>> ? (ccl::lookup-objc-message-info "size") #S(OBJC-MESSAGE-INFO ...)
>>> with 3 methods (NSImage, INImageRep,
>>> NSAttributedString).  If you look at the methods, you'll see that
>>> they each return an NSSize.
>>> If you introduce additional interfaces, it's possible that a new
>>> "size" method with a different type signature will be declared in
>>> those interfaces.  (This doesn't happen too often; when it does
>>> happen, it tends to involve message with generic names like "size".)
>>> When it happens, a warning is printed (since we'd been assuming that
>>> "size" was unambiguous but now have information to the contrary.)
>>> Note that this (the introduction of a method with a different type
>>> signature) can only happen if the class on which that method is
>>> defined is disjoint from all other classes which define the method.
>>> If it doesn't have any additional information about the type of
>>> the "receiver" object, SEND has to treat the message send as a
>>> sort of TYPECASE.  If the class NSToaster defines "size" to
>>> return an :int and NSAttributedString, NSImage, and NSImage all
>>> define it to return an :<NSS>ize, then SEND may have to arrange
>>> to test at runtime to determine which of these classes the instance
>>> is a receiver of.  An NSString might fail all of these tests; even
>>> if it didn't, the message send should generate a runtime "message  
>>> not
>>> understood" NSException.
>>> I don't believe that there's any substantial difference in content
>>> between what I packaged as the "Tiger Cocoa interfaces" and the
>>> cocoa stuff in the "060620 Darwin interfaces", and I don't believe
>>> that NSString has ever defined a "size" method (unless a string has
>>> some attributes - like font and point size - it'd be a little hard
>>> to tell how big it'd be when drawn ...)
>>> On Sun, 16 Jul 2006, Phil wrote:
>>>> Thanks for clarifying that point.  I dropped in the new interfaces
>>>> (replacing the previous tiger interface update) and it resulted in
>>>> one bit of breakage: sending an NSString or NSAttributedString a
>>>> size message no longer works (nonSTRET SEND).  I did a little
>>>> digging and found that in the previous interfaces this bit of code:
>>>>                                               'NS-STRING
>>>>                                               :INIT-WITH-STRING
>>>>                                               "testing")
>>>>                                             'SIZE)))))
>>>> which previously resulted in:
>>>> (:returns-structure t)
>>>> now returns:
>>>> (:ambiguous t)
>>>> On Jul 14, 2006, at 4:08 PM, Gary Byers wrote:
>>>>> Sorry if I wasn't clear; the "060620" interfaces are all Tiger- 
>>>>> based
>>>>> (except for the CHUD stuff, which has been enough of a moving  
>>>>> target
>>>>> that I wanted to pick an arbitrary release and stick with it as  
>>>>> long
>>>>> as possible.)
>>>>> On Fri, 14 Jul 2006, Phil wrote:
>>>>>> Gary,
>>>>>> Any chance of getting an updated version of the Tiger interfaces
>>>>>> or it safe to mix and match? (i.e. should I just drop the darwin
>>>>>> GL interfaces from darwin on top of the tiger version)
>>>>>> Thanks,
>>>>>> Phil
>>>>>> On Jul 14, 2006, at 4:22 AM, Gary Byers wrote:
>>>>>>> I think that it was probably an oversight.
>>>>>>> I can't easily check at the moment (the machine that I used is
>>>>>>> acting
>>>>>>> up ...), but I think that the interfaces that were generated on
>>>>>>> 6/20
>>>>>>> (in <ftp://clozure.com/pub/testing/openmcl-darwin-
>>>>>>> interfaces-060620.tar.gz>)
>>>>>>> contain glext.h (by virtue of the fact that AGL/agl.h #includes
>>>>>>> it.)
>>>>>>> On Fri, 14 Jul 2006, Phil wrote:
>>>>>>>> The GL extension constants and functions (i.e. glext.h) don't
>>>>>>>> appear
>>>>>>>> to be included and I was wondering if this was by design or
>>>>>>>> just an
>>>>>>>> oversight?
>>>>>>>> Thanks,
>>>>>>>> Phil
>>>>>>>> _______________________________________________
>>>>>>>> Openmcl-devel mailing list
>>>>>>>> Openmcl-devel at clozure.com
>>>>>>>> http://clozure.com/mailman/listinfo/openmcl-devel
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list