[cffi-devel] Re: Lisp 5, Edgar 2 (and gaining)

[Ken Tilton]

Ken Tilton wrote:

> cffi-devel-request at common-lisp.net wrote:
>
>> Send cffi-devel mailing list submissions to
>>     cffi-devel at common-lisp.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>     http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
>> or, via email, send a message with subject or body 'help' to
>>     cffi-devel-request at common-lisp.net
>>
>> You can reach the person managing the list at
>>     cffi-devel-owner at common-lisp.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cffi-devel digest..."
>>
>>
>> Today's Topics:
>>
>>   1. CLisp exe vs FFI (Ken Tilton)
>>   2. Re: Re: Clisp, cffi and defcfuns in a saved image
>>      ( Edgar Gon?alves )
>>   3. Re: CLisp finalizers ( Lu?s Oliveira )
>>   4. New features ( Lu?s Oliveira )
>>   5. Re: cffi-clisp.lisp multiple-value-bind usage of    variable
>>      "error" conflicts with another package ( Lu?s Oliveira )
>>   6. Re: New features (Stelian Ionescu)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 13 Feb 2007 13:53:41 -0500
>> From: Ken Tilton <kentilton at gmail.com>
>> Subject: [cffi-devel] CLisp exe vs FFI
>> To: cffi-devel at common-lisp.net
>> Message-ID: <45D20935.9010009 at gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> I would consider as merely a first sanity-checking step simply using 
>> native CLisp ffi to make one lousy call to SQL and get /that/ to work 
>> in an exe. ie, reduce the number of variables in play.
>>
>> Then try it with CFFI, but not uffi-compat.
>>
>> Then with uffi-compat, but still writing my own (one?) bindings.
>>
>> Then worry about cl-sql bindings running thru a maze of FFIs.
>>
>> hth,kt
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 13 Feb 2007 20:42:50 +0000
>> From: " Edgar Gon?alves " <edgar.goncalves at gmail.com>
>> Subject: Re: [cffi-devel] Re: Clisp, cffi and defcfuns in a saved
>>     image
>> To: " Lu?s Oliveira " <luismbo at gmail.com>
>> Cc: cffi-devel at common-lisp.net
>> Message-ID:
>>     <6fd384780702131242i1f2b1a5ci2780bb7d9939fcab at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Ok, I've just realized that I've been mislocating the problem at
>> hands. It seems that defcfun works just fine, and the issue I'm
>> getting resides on the foreign pointers. I've made tests to cffi,
>> cffi-uffi-compat, ffi (answering to Ken's "CLisp exe vs FFI"
>> post), and all have worked for a simple function definition/call.
>> So I delved again to clsql initial situation, and I've traced the
>> error to a call to %new-environment-handle, that uses a null
>> pointer as an argument to the ff call to SQLAllocHandle. I also
>> noticed that the null pointer was indeed showing up at the error
>> message, so I tried this simple test:
>>
>> ,-----
>> | (asdf:operate 'asdf:load-op 'cffi)
>> | (asdf:operate 'asdf:load-op 'cffi-uffi-compat)
>> | (defvar my-null-ptr (ffi:unsigned-foreign-address 0))
>> | (format t "- Before loading image, null ptr is: ~A!~%" my-null-ptr)
>> | (ext:saveinitmem "test.exe"
>> |          :init-function #'(lambda ()
>> |                     (format t "- After loading image, my-null-ptr 
>> yelds: ~A.~%"
>> my-null-ptr)
>> |                     (ext:quit))
>> |          :NORC t
>> |          :script t
>> |          :executable t
>> |          :quiet t)
>> `-----
>>
>>
>> The output I get when I run this code is (after the initial load 
>> messages),
>> ,-----
>> | (...)
>> | - Before loading image, null ptr is: #<FOREIGN-ADDRESS #x00000000>!
>> | C:\dev\test>test
>> | test
>> | - After loading image, my-null-ptr yelds: #<INVALID FOREIGN-ADDRESS
>> #x00000000>.
>> `-----
>>
>> What makes a foreign address valid or invalid? Is there some way
>> I can validate a simple null pointer? I could understand if a
>> given non-null pointer in C would be hard to validate after
>> restarting an image, but a null pointer is, and always will be,
>> 0x0, right?
>>
>>  
>>
> Well, clearly Clisp is taking care to keep private little notes about 
> what you are up to, so I would not be too surprised that it finds a 
> difference between zero and zero. ie, it has the thing boxed, so it 
> aint just looking at zeros (as would a C compiler just looking at a 
> long), it sees a pointer /wrapper/ which is cool interactive but not 
> compiled, by which I mean:
>
> I have no idea what I am talking about, but I suspect the problem is 
> simply that the defvar form compiles with a foreign pointer allocated 
> /at compile time/, and then t runtime that pointer is spotted by CLisp 
> as not having been allocated during the run at hand. So...
>
> So do not do that, ie, do not compile a dynamic foreign pointer 
> allocation into your fasl, ie allocate my-ptr at runtime.
>
> hth,kzo
>
>
btw, this is the two-edged sword of dynamic languages, and there is 
nothing like building an exe to drive that lesson home: Lisp has all 
these different "times" that normally do not matter but when they do.... 
well, you are finding out fast. :)

For me development is years of work and then a few days of hand-to-hand 
fighting to build an exe. The bad news for you is that you are tackling 
all this as a noob instead of after a year of intense Lisp during which 
you might have gotten a little conversant with the "times" while writing 
macros.

Hang in there.

kt