[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)
(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
>>
>>
More information about the Openmcl-devel
mailing list