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

[Gary Byers]

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
>>> 
>>> 
>
>