[Openmcl-devel] Questions about #? to access variables

[Gary Byers]

On Mon, 14 Jun 2004, Anders Conradi wrote:

> Hi,
>
> I have some questions about the #? reader macro to access foreign
> variables.
>
> I have a file containing the following:
> --------8<--------
> (require :cocoa)
> (defvar ha #?NSToolbarSeparatorItemIdentifier)
> --------8<--------
>
> If I try to compile that file with compile-file I get the following
> error:
>
> ? (compile-file "testar.lisp")
>  > Error in process listener(1): Can't dump #<A Mac Pointer #xA30725D4>
> - unknown type
>  > While executing: CCL::FASL-UNKNOWN
>  > Type :POP to abort.
> Type :? for other options.
>
> Why? What should I do to get it to work?
>

Hmm.   You clearly weren't running a patched version of "ccl:lib;nfcomp.lisp",
which knows how to dump foreign variables ...

>
> Another question. If I type:
> ? (require :cocoa)
> ? #?NSToolbarSeparatorItemIdentifier
>
> I get an unrecognized macptr:
>
> #<A Mac Pointer #xA3085D60>
>
>   Why isn't it recognized as an objc-object? If I do

The recognition's heuristic: before indirecting through a pointer to
see if it points to a known class, the bridge wants some assurance that
it can do that indirection without segfaulting (and that the pointer points
to someplace where an ObjC instance might reasonably be.)

If the pointer was allocated via #_malloc, the bridge will indirect through
it to see if it points to an ObjC class.

Some other types of ObjC objects (notably strings) are statically
allocated inside the data sections of ObjC libraries, and the bridge
tries to build a list of where these sections are in memory and the
pointer classification code looks through this (hopefully short) list
of sections.  I think that 0.14.2 does a bit better at finding the
list of sections than previous versions did, and I find that this
works in 0.14.2-p1 under OSX 10.3.3:

? #?NSToolbarSeparatorItemIdentifier
#<NS-CF-STRING "NSToolbarSeparatorItem" (#xA2DDB02C)>

I don't know why it doesn't work for you
>
> ? (%get-ptr #?NSToolbarSeparatorItemIdentifier)
>
> I get #<OBJC:OBJC-CLASS NS:NS-CF-STRING (#xA0130D40)>

I find that the class has a different address in my environment.
That's not significant in and of itself, but it might suggest that
statically allocated strings are allocated in differently-named
sections under different OS/Cocoa versions (perhaps as a function of the
C compiler/toolchain used to build the library.)

As a reminder: it's often really helpful to let people know what OS
and lisp versions you're running when reporting things like this.  It's
often hard to know beforehand whether that information's relevant, but
it's usually better to assume that it might be and include it than it
is to omit it.

>
> Is this some class that isn't known by the bridge, and in that case why
> not?
>
> // Anders
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>
-------------- next part --------------
Index: lib/nfcomp.lisp
===================================================================
RCS file: /usr/local/tmpcvs/ccl-0.14/ccl/lib/nfcomp.lisp,v
retrieving revision 1.6
diff -u -r1.6 nfcomp.lisp
--- lib/nfcomp.lisp	4 May 2004 08:22:55 -0000	1.6
+++ lib/nfcomp.lisp	13 Jun 2004 22:23:11 -0000
@@ -970,7 +970,8 @@
   (unless (short-fixnum-p fixnum) (fasl-scan-ref fixnum)))
 
 (defparameter *istruct-make-load-form-types*
-  '(lexical-environment shared-library-descriptor shared-library-entry-point external-entry-point
+  '(lexical-environment shared-library-descriptor shared-library-entry-point
+    external-entry-point foreign-variable
     ctype unknown-ctype class-ctype foreign-ctype union-ctype member-ctype 
     array-ctype numeric-ctype hairy-ctype named-ctype constant-ctype args-ctype
     hash-table))