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

[Gary Byers]

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)
>
> (CCL::SLET ((TEST-SIZE
>   (CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>                            'NS-ATTRIBUTED-STRING
>                            :INIT-WITH-STRING
>                            "testing")
>                           'SIZE))))
>
> NonSTRET SEND in (CCL::SEND (CCL::MAKE-OBJC-INSTANCE
> 'NS-ATTRIBUTED-STRING
> :INIT-WITH-STRING
> "testing")
> 'SIZE)
> [Condition of type SIMPLE-ERROR]
>
> (CCL::OBJC-MESSAGE-INFO-FLAGS
>   (CCL::GET-OBJC-MESSAGE-INFO
>     (CCL::PARSE-MESSAGE
>       (CDDR '(CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>                                                'NS-ATTRIBUTED-STRING
>                                                :INIT-WITH-STRING
>                                                "testing")
>                                              'SIZE)))))
>
> (:AMBIGUOUS T)
>
> ; Old interfaces (Tiger Cocoa interfaces)
>
> (CCL::SLET ((TEST-SIZE
>   (CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>                             'NS-ATTRIBUTED-STRING
>                             :INIT-WITH-STRING
>                             "testing")
>                            'SIZE))))
>
> NIL
>
> (CCL::OBJC-MESSAGE-INFO-FLAGS
>   (CCL::GET-OBJC-MESSAGE-INFO
>     (CCL::PARSE-MESSAGE
>       (CDDR '(CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>                                               'NS-ATTRIBUTED-STRING
>                                               :INIT-WITH-STRING
>                                               "testing")
>                                              'SIZE)))))
>
> (:RETURNS-STRUCTURE T)
>
> 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:
>>> (CCL::OBJC-MESSAGE-INFO-FLAGS
>>>  (CCL::GET-OBJC-MESSAGE-INFO
>>>    (CCL::PARSE-MESSAGE
>>>      (CDDR '(CCL::SEND (CCL::MAKE-OBJC-INSTANCE
>>>                                               '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
>
>