[Openmcl-devel] Interface to Mac OS X InstantMessage framework?

[Gary Byers]

It's basically a hash-table bug; OpenMCL is supposed to allow fairly
arbitrary non-standard :TEST function arguments to MAKE-HASH-TABLE,
but a change introduced shortly before 1.0 was released broke that
support.   The FFI parser is one of the few things I'm aware of that
actually tries to use non-standard :TEST functions, and it doesn't
have a very compelling reason to do so.

There are a couple of workarounds:

  - there's a patched dppccl-image in:

<ftp://clozure.com/pub/dppccl-image-1.0-p060223.tar.gz>

that fixes the hash-table code to work when non-standard :test functions
are in effect.

  - there are about 10 calls to MAKE-HASH-TABLE in "ccl:library;parse-ffi.lisp",

Change all instances of:

   (MAKE-HASH-TABLE :TEST 'STRING= :HASH-FUNCTION 'SXHASH)

to

   (MAKE-HASH-TABLE :TEST 'EQUAL)

That's actually the good news; the bad news is that it can be a little
tricky to teach the Cocoa bridge how to incorporate a new set of ObjC
declarations and libraries into a running session.  The "webkit"
example tries to do this and it seems to work, but to the extent that
it does work it does so by accident (this has to do with the order
in which the ObjC runtime system enumerates classes: if there were 1000
known ObjC classes before an add-on library was loaded and 1100 known
classes after it was loaded, the "new" 100 aren't necessarily the
last 100 classes that'd be enumerated, though this happens to be true
in WebKit's case.)

If you look at the WebKit example in the 1.0 sources, you'll notice
that near the end of a functionn called CCL::CHECK-FOR-WEBKIT it calls
a function called CCL::MAP-OBJC-CLASSES.  Just before doing so, it
really -should- call a function named CCL::RESET-OBJC-CLASS-COUNT;
this will force MAP-OBJC-CLASSES to look at all ObjC classes that
the runtime enumerates and not assume that only the last N to be 
enumerated are new.  (Alternately, you could make MAP-OBJC-CLASSES
start its DO* loop at 0, rather than at the value of CLASS-COUNT.)

If you use the webkit example as a template (and modify it as
suggested above), you'll probably be able to make some progress.
There are a couple of other less severe problems that I know
of (NSConstantStrings that're embedded in the new library's memory
segments aren't recognized, and nothing tells the shared library
mechanism about the framework bundle that was loaded.)  If you get
to the point where these issues are pressing, let me know.

(And yes, itd be good if this was all a little easier.)


On Sun, 6 Aug 2006, Joseph Oswald wrote:

> I'm using OpenMCL 1.0 under OS X 10.4.7.
>
> I'm not yet able to comprehend cl-xmpp enough to get it working, and
> my second choice is to try to use Apple's own instant messaging
> support to send AIM/Jabber messages from Lisp.
>
> I've tried using FFIGEN (the one in
> ffigen-bin-darwinppc-gcc-4.0.0-2005-05-17-11-45-56.tar) to generate
> IMService.ffi, which seems to work, but when I try
>
>
> (require "PARSE-FFI")
> (ccl::parse-standard-ffi-files :instantmessage)
>
> Get an error message around Line 120 of IMService.ffi
>
> (type ("/usr/include/ppc/_types.h" 31)
> "__int8_t"
> (signed-char ()))
>
> to the effect of
>
> #P"/Applications/OpenMCL/ccl_1.0/darwin-headers/instantmessage/C/System/Library/Frameworks/InstantMessage.framework/Headers/IMService.ffi"
> ...
>> Error in process listener(1): value #<Unbound> is not of the expected type (COMMON-LISP:OR COMMON-LISP:STRING COMMON-LISP:SYMBOL COMMON-LISP:CHARACTER).
>> While executing: COMMON-LISP:STRING
>> Type :POP to abort.
> Type :? for other options.
> 1 > :b
> (F0135AF0) : 0 "COMMON-LISP:STRING" 200
> (F0135B00) : 1 "CCL::STRING-START-END" 48
> (F0135B10) : 2 COMMON-LISP:NIL NIL
> (F0135B20) : 3 "COMMON-LISP:STRING=" 260
> (F0135B30) : 4 "CCL::%HASH-PROBE" 2212
> (F0135B40) : 5 "COMMON-LISP:GETHASH" 452
> (F0135B50) : 6 "CCL::FIND-OR-CREATE-FFI-TYPEDEF" 44
> (F0135B60) : 7 "CCL::PROCESS-FFI-TYPEDEF" 80
> (F0135B70) : 8 "CCL::PARSE-FFI" 976
> (F0135B90) : 9 "CCL::PARSE-STANDARD-FFI-FILES" 812
> ...
>
> 1 > (:f 5)
> (F0135B40) : 5 "COMMON-LISP:GETHASH" 452
>  0 CCL::KEY: "__int8_t" ("required")
>  1 CCL::DEFAULT: COMMON-LISP:NIL ("required")
>  2 : "__int8_t" ("saved SAVE0")
>  3 : (:TYPE ("/usr/include/ppc/_types.h" 31) "__int8_t" (:SIGNED-CHAR
> COMMON-LISP:NIL)) ("saved SAVE1")
>  4 : #<FFI-MACRO NIL #x84947B6> ("saved SAVE2")
>  5 : COMMON-LISP:NIL ("saved SAVE3")
>  6 : #<HASH-TABLE :TEST COMMON-LISP:EQUAL size 12/60 #x849D2D6> ("saved SAVE4")
>  7 : COMMON-LISP:MAKE-HASH-TABLE ("saved SAVE5")
>  8 CCL::INTERRUPT-LEVEL: 0
>  9 : #<Compiled-function CCL::GENERAL-HASH-FIND #x80167E6>
>
> 1 > (:f 4)
> (F0135B30) : 4 "CCL::%HASH-PROBE" 2212
>  0 CCL::HASH: #<HASH-TABLE :TEST COMMON-LISP:STRING= size 0/60
> #x849DE96> ("required")
>  1 CCL::UPDATE-HASH-FLAGS: COMMON-LISP:NIL ("required")
>  2 : #<HASH-TABLE-VECTOR  #x849DF06> ("saved SAVE0")
>  3 : #<HASH-TABLE :TEST COMMON-LISP:STRING= size 0/60 #x849DE96>
> ("saved SAVE1")
>  4 : COMMON-LISP:NIL ("saved SAVE2")
>  5 : COMMON-LISP:NIL ("saved SAVE3")
>  6 : #<HASH-TABLE :TEST COMMON-LISP:EQUAL size 12/60 #x849D2D6> ("saved SAVE4")
>  7 : COMMON-LISP:MAKE-HASH-TABLE ("saved SAVE5")
>  8 : #<FILE-CHARACTER-INPUT-STREAM
> ("/Applications/OpenMCL/ccl_1.0/darwin-headers/instantmessage/C/System/Library/Frameworks/InstantMessage.framework/Headers/IMService.ffi"/11)
> #x849CEBE> ("saved SAVE6")
>  9 : CCL:STRUCTURE-TYPEP ("saved SAVE7")
>  10 CCL::HASH-CODE: 277107718
>  11 : 43
>  12 : 71
>  13 CCL::COMPAREF: COMMON-LISP:STRING=
>
> 1 > (:f 3)
> (F0135B20) : 3 "COMMON-LISP:STRING=" 260
>  0 : "__int8_t" ("required")
>  1 : #<Unbound> ("required")
>  2 : COMMON-LISP:NIL ("keyword")
>  3 : COMMON-LISP:NIL ("key-supplied-p")
>  4 : COMMON-LISP:NIL ("keyword")
>  5 : COMMON-LISP:NIL ("key-supplied-p")
>  6 : COMMON-LISP:NIL ("keyword")
>  7 : COMMON-LISP:NIL ("key-supplied-p")
>  8 : COMMON-LISP:NIL ("keyword")
>  9 : COMMON-LISP:NIL ("key-supplied-p")
>  10 : 43 ("saved SAVE0")
>  11 : 96 ("saved SAVE1")
>  12 : COMMON-LISP:NIL ("saved SAVE2")
>  13 : #<Unbound> ("saved SAVE3")
>  14 : "__int8_t" ("saved SAVE4")
>  15 : 71 ("saved SAVE5")
>
> 1 >
>
> Questions
>
> 1) Is it actually necessary to have FFI definitions to use the
> InstantMessage framework from OpenMCL?
> 2) Is this a bug in parse-ffi?
> 3) To workaround it, can I just comment out enough of the .ffi file to
> get parse-ffi to work?
> 4) Has anyone else been able to use the InstantMessage framework, and
> have some example code?
>
> Thanks for any help.
> --Joe Oswald
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>