[Openmcl-devel] Trying to use AddressBook

Ralph Richard Cook ralphc at bellsouth.net
Sun Oct 30 01:57:34 UTC 2005


That change got it. Thanks.

On Oct 29, 2005, at 1:10 PM, Gary Byers wrote:

> It's a bug.
>
> The short version is that hash-tables with a (non-standard) :TEST
> function of #'STRING= don't work. (I'm not sure about other non- 
> standard
> test functions.)
>
> There are about a dozen places in "ccl:library;parse-ffi.lisp" that  
> create such hash tables: about 4 places in the function PARSE-FFI,
> and the remainder in PARSE-STANDARD-FFI-FILES.  Changing these to
> use EQUAL (instead of STRING=) seems to work around the problems
> with non-standard hash-table test functions.
>
> (The first time that you run (PARSE-STANDARD-FFI-FILES :ADDRESSBOOK),
> you'll get warnings to the effect that the .cdb files don't exist.
> They don't: they're being created.  Running it a second time isn't
> a bad idea; if the headers contained things like:
>
> #define FOO 1
> ...
> #define BAR (FOO+1)
>
>
> there's a greater chance that #$BAR will work after a second pass,
> because #$FOO will be defined.  I don't think that there's any
> advantage to running PARSE-STANDARD-FFI-FILES more than twice.)
>
>
> On Sat, 29 Oct 2005, Ralph Richard Cook wrote:
>
>
>> I'm having some trouble. I (believe I) successfully made the  
>> AddressBook FFI; I have a file about 4 megs big that looks like it  
>> has AddressBook constants, includes etc. in it.
>>
>> From within OpenMCL I try
>>
>> CL-USER> (in-package :ccl)
>> #<Package "CCL">
>> CCL> (parse-standard-ffi-files :addressbook)
>>
>> and get
>>
>> value #<Unbound> is not of the expected type (OR STRING SYMBOL  
>> CHARACTER).
>>   [Condition of type TYPE-ERROR]
>>
>> Restarts:
>>  0: [ABORT] Abort handling SLIME request.
>>  1: [ABORT-BREAK] Reset this process
>>  2: [ABORT] Kill this process
>>
>> Backtrace:
>>  0: (STRING 'NIL)
>>  1: (CCL::STRING-START-END "ABPropertyType" #<Unbound> 0)
>>  2: (STRING= "ABPropertyType" #<Unbound>)
>>  3: (CCL::%HASH-PROBE #<HASH-TABLE :TEST STRING= size 0/60  
>> #x8653426> 'NIL #<HASH-TABLE-VECTOR  #x8653496>)
>>  4: (GETHASH "ABPropertyType" 'NIL "ABPropertyType")
>>  5: (CCL::FIND-OR-CREATE-FFI-TYPEDEF ':TYPE)
>>  6: (CCL::PROCESS-FFI-TYPEDEF '(:TYPE ("/System/Library/ 
>> Frameworks/ AddressBook.framework/Headers/ABTypedefs.h" 34)  
>> "ABPropertyType" (:ENUM-REF "_ABPropertyType")))
>>  7: (CCL::PARSE-FFI #P"/usr/local/openmcl/ccl/darwin-headers/  
>> addressbook/C/System/Library/Frameworks/AddressBook.framework/ 
>> Headers/ AddressBook.ffi")
>>  8: (CCL::PARSE-STANDARD-FFI-FILES ':ADDRESSBOOK)
>>  9: (CCL::CALL-CHECK-REGS 'CCL::PARSE-STANDARD-FFI-FILES)
>> --more--
>>
>> After looking at parse-ffi.lisp I try
>>
>> CCL> (describe '*ffi-typedefs*)
>> Symbol: *FFI-TYPEDEFS*
>> Special Variable
>> INTERNAL in package: #<Package "CCL">
>> Print name: "*FFI-TYPEDEFS*"
>> Value: #<Unbound>
>> Function: #<Unbound>
>> Plist: NIL
>> ; No value
>>
>>
>> Any ideas?
>>
>> Thanks
>>
>> On Oct 23, 2005, at 8:47 PM, Gary Byers wrote:
>>
>>
>>> AddressBook is likely something like WebKit (a set of Cocoa classes
>>> that are large enough and domain-specific enough to be  
>>> distributed as
>>> their own framework.)
>>> The good news is that there's a (very simple) example of using  
>>> WebKit
>>> in the OpenMCL 1.0 distribution, and the steps involved in using  
>>> AddressBook shold be similar.  The bad news is that there's some
>>> one-time setup involved and a little bit of startup work to be
>>> done in any code that uses AddressBook (or WebKit, or ...) under
>>> the Cocoa Bridge.
>>> The one-time setup involves generating interfaces (.cdb files)
>>> describing the classes and methods in the AddressBook headers,
>>> so that it'd be possible to say something like:
>>>
>> ....
>>
>>> If this makes sense so far, great, and if you want to pursue this
>>> on your own please let the list know if you're successful or if
>>> you encounter further problems.
>>>
>>
>>
>




More information about the Openmcl-devel mailing list