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

Phil pbpublist at comcast.net
Fri Jul 21 22:17:12 PDT 2006

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)


[Condition of type SIMPLE-ERROR]



; Old interfaces (Tiger Cocoa interfaces)





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

More information about the Openmcl-devel mailing list