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

[Gary Byers]

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
>