[Openmcl-devel] objc-bridge differences v1.2 - v1.3 ?

[Gary Byers]

The macro @CLASS (which is an old way to refer to an ObjC class by name)
expands to:

(the (@metaclass ...) ...)

@metaclass isn't a known type specifier.  (I suppose that it could be
made into one.)

? (defun foo (x)
   (the (@metaclass foo) x))
FOO

Pretty uneventful, but:

? (defun foo (x)
   (the (@metaclass foo) x))
0> Calling (SIGNAL PARSE-UNKNOWN-TYPE :SPECIFIER (@METACLASS FOO)) 
<0 SIGNAL returned NIL

When the type system tries to parse a type specifier that it doesn't
recognize, it uses SIGNAL to signal a condition of type PARSE-UNKNOWN-TYPE
to announce that.  (The compiler's processing of THE could have used
a handler for that condition to warn us that the type specifier is
unknown.  That would certainly have been justified.)

Apparently, a handler (somewhere ...) is treating this condition as
an error.  (I don't know what or where or why it behaves differenty
on x8663 than on PPC, but I'm willing to believe that whatever it
is justified.)

I believe that the use of (the (@metaclass ...) ...) was intended
to convey some information to the SEND macro.

It's not entirely right - I'd sort of rather discourage the use
of @metaclass as a type specifier - but if it's going to be used
as one it's probably make sense if it was defined.  Defining
the type

(deftype ccl::@metaclass (x)
   (declare (ignore x))
   'objc:objc-metaclass))

before ... well, before whatever it is that uses (@class ...) (whether
that's your code or easygui or whatever it is) is compiled should
keep this error from happening.



On Thu, 19 Mar 2009, Arthur W Cater wrote:

> Hi,
>
> I've developed some code on my ppc powerbook using cclv1.2 that I'm testing on darwinx8664 before uploading it.
> I have a problem trying to #/performClose: a window, where the window is an instance of Cocoa-Window
> which I have defined as a subclass of ns:ns-window, and ccl:+null-ptr+ is used as 'sender'.
> Perform-Close is one of my new functions.
>
> This works on 32-bit ppc with CCL1.2 r11813M, not with CCL1.3 r11820M on x8664, where I get
>
>
> ? (easygui::perform-close easygui::*w)
>> Error: #<PARSE-UNKNOWN-TYPE unknown type (@METACLASS CocoaWindow)>
>> While executing: #<Anonymous Function #x3000413D05DF>, in process Listener(11).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
> 1 > :b
> (23160A50) : 0 (FUNCALL #'#<Anonymous Function #x3000413D05DF> #<COCOA-WINDOW [NIL] #x300041EC4E3D> #S(CCL::OBJC-SELECTOR :NAME "performClose:" :%SEL #<A Foreign Pointer #x7FFF815A9DB0>) #<A Null Foreign Pointer>) 429
> (23160A78) : 1 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> #<COCOA-WINDOW [NIL] #x300041E7FEFD> #<A Null Foreign Pointer>) 501
> (23160AB8) : 2 (FUNCALL #'#<#<STANDARD-METHOD EASYGUI:PERFORM-CLOSE (EASYGUI:WINDOW)>> #<EASYGUI::VIEW-HIERARCHY-DEMO-WINDOW #x300041E808DD>) 397
> (23160AD8) : 3 (CALL-CHECK-REGS EASYGUI:PERFORM-CLOSE #<EASYGUI::VIEW-HIERARCHY-DEMO-WINDOW #x300041E808DD>) 229
> (23160B10) : 4 (TOPLEVEL-EVAL (EASYGUI:PERFORM-CLOSE EASYGUI::*W) NIL) 733
> (23160BB0) : 5 (READ-LOOP :INPUT-STREAM #<SYNONYM-STREAM to *TERMINAL-IO* #x300041A34C2D> :OUTPUT-STREAM #<SYNONYM-STREAM to *TERMINAL-IO* #x300041A34ACD> :BREAK-LEVEL 0 :PROMPT-FUNCTION #<Compiled-function (:INTERNAL CCL::READ-LOOP) (Non-Global)  #x3000404E6BFF>) 2069
> <snip>
> 1 > :raw 1
> (23160A78) : 1 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> #<COCOA-WINDOW [NIL] #x300041DA80FD> #<A Null Foreign Pointer>) 501
>  0 CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "performClose:" :%SEL #<A Foreign Pointer #x7FFF815A9DB0>) (:INHERITED)
>  1 FUNCTION: #<Anonymous Function #x3000413D05DF> (:INHERITED)
>  2 CCL::RECEIVER: #<COCOA-WINDOW [NIL] #x300041DA80FD> ("required")
>  3 CCL::ARGS: (#<A Null Foreign Pointer>) ("rest")
>  4 : #<Anonymous Function #x3000413D05DF>
>
> I then installed CCLv1.3 r11824 on my 32-bit ppc, and it doesn't work there either.
> The backtrace is virtually the same except it has an extra line at the beginning:
>  (F0300B80) : 0 (CHECK-NS-EXCEPTION #<A Foreign Pointer [stack-allocated] (:* #) #x3E3A690>) 336
>
>
> Two kinds of explanation come to my mind:
> 1 - perhaps something that has happened in other bits of my code has corrupted memory;
>     after all I don't see any reason for any parsing to be taking place
> 2 - perhaps something is different in the objc bridge other than it no longer converting lisp strings
>    to nsstrings: that's the only thing I notice in the v1.3 release notes.
>
> Any insight would be much appreciated.
>
> Arthur
>
>