[Openmcl-devel] Error calling #/image after loading the Quartz framework

[Michael Minerva]

Okay, thanks a lot Gary.

--Mike

On Jun 28, 2013, at 5:48 PM, Gary Byers <gb at clozure.com> wrote:

> It sounds like a bug in OBJC:LOAD-FRAMEWORK.  I'll look at it.
> 
> If anyone's interested in some of the gory details:
> 
> In order for a "dispatch function" defined via #/ to send an ObjC
> message (e.g., to invoke an ObjC method), it needs to the (foreign)
> types of the message's arguments and result; this is sometimes called
> the "foreign type signature" of a method.
> 
> In the vast majority of cases in Cocoa, all ObjC methods defined on a message
> name have the same type signature; out of a few thousand messages defined in
> the AppKit and Foundation framework's headers, there are only 1 or 2 dozen
> exceptions to this (there are 1 or 2 dozen cases of "type ambiguity").  If
> all methods defined on a message share the same type signature, the dispatch
> function can simply use that type signature to pass any arguments and process
> any result; if type ambiguity exists, then the dispatch function has to try
> to determine which method (and therefore which type signature) is applicable
> to the receiver.
> 
> Sometimes, a method is declared to be defined by a (formal) protocol, or
> more accurately defined by instances of all classes that implement (or
> "conform to") that protocol.  If a protocol-defined method has a different
> type signature than other methods defined on the message, then determining
> whether that type signature should be used or not depends on determining
> whether or not the receiver's class implements the protocol in question.
> 
> As noted above, this "foreign type ambiguity" is fairly rare in the core
> Cocoa frameworks (AppKit and Foundation), but loading new frameworks can
> introduce new cases of it.  One example that comes to mind is the #/size
> message: in the cases where it's defined in Cocoa, #/size always returns
> an #>NSSize structure, but some add-on framework (WebKit, IIRC) defines
> a #/size method that returns an #>NSInteger and the dispatch function for
> #/size has to be changed to deal with this possibility.
> 
> As I understand the bug, the Quartz framework declares a new #/image method
> that returns a #>CGImage structure (or a pointer to one, I don't remember)
> and this method is apparently defined on instances of classes that implement
> some named protocol; OBJC-LOAD-FRAMEWORK causes the dispatch function for
> #/size to be recompiled to deal with this newly-introduced ambiguity, but'
> information about the defining protocol isn't set correctly (leading to the
> runtime error.)
> 
> If my recollection of the above is correct, it should be fairly easy to fix,
> 
> 
> On Fri, 28 Jun 2013, Michael Minerva wrote:
> 
>> Yesterday I noticed some strange errors after loading the Quartz framework and today I tried to isolate it a bit. I created a small test app that basically just initializes and NSImage and an NSImageView then sets the image of the image-view to be the image and then finally prints the #/image of the image-view. This silly little program works fine but after loading the Quartz framework I get this strange error:
>> 
>>> Error: The value NIL is not of the expected type STRUCTURE.
>>> While executing: CCL::CONFORMS-TO-PROTOCOL, in process Listener(4).
>>> Type cmd-. to abort, cmd-\ for a list of available restarts.
>>> Type :? for other options.
>> 
>> I wonder what might be going on here? Is this an issue with the framework or am I doing something very silly?
>> 
>> To try out the little test program:
>> ? Compile the function
>> ? execute (GET-IMAGE-FROM-NEW-IMAGE-VIEW)
>> ? load the framework (and wait a few seconds for it to load)
>> ? then execute (GET-IMAGE-FROM-NEW-IMAGE-VIEW) again
>> 
>> I have tested this on Mountain Lion and Lion using 1.10-dev-r15852M-trunk (currently I do not have access to any Snow Leopard machines).
>> 
>> If anyone could give me a clue about what's going on here I would greatly appreciate it.
>> 
>> Thanks,
>> 
>> --Mike
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2559 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130701/4750d025/attachment.bin>