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

[Edgar Gonçalves]

On 2/14/07, Ken Tilton <kentilton at gmail.com> wrote:
> 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...

I've filed a bug report on clisp, and the answer I got was (yep, you
guessed it):
> >
> > So do not do that, ie, do not compile a dynamic foreign pointer
> > allocation into your fasl, ie allocate my-ptr at runtime.
> >

I won't do that in my code, obviously, but now I know what I must be
looking at when using 3rd party libraries.
Just like the "use-foreign-library" call that must exists before
defcfuns, at each time an image is loaded, with sbcl and clisp - but
not with other implementations, as it seems!


> 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.

I will, thanks!

-- 
Edgar Gonçalves