cffi-devel-request@common-lisp.net wrote:
Send cffi-devel mailing list submissions to cffi-devel@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@common-lisp.net
You can reach the person managing the list at cffi-devel-owner@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:
- CLisp exe vs FFI (Ken Tilton)
- Re: Re: Clisp, cffi and defcfuns in a saved image ( Edgar Gon?alves )
- Re: CLisp finalizers ( Lu?s Oliveira )
- New features ( Lu?s Oliveira )
- Re: cffi-clisp.lisp multiple-value-bind usage of variable "error" conflicts with another package ( Lu?s Oliveira )
- Re: New features (Stelian Ionescu)
Message: 1 Date: Tue, 13 Feb 2007 13:53:41 -0500 From: Ken Tilton kentilton@gmail.com Subject: [cffi-devel] CLisp exe vs FFI To: cffi-devel@common-lisp.net Message-ID: 45D20935.9010009@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@gmail.com Subject: Re: [cffi-devel] Re: Clisp, cffi and defcfuns in a saved image To: " Lu?s Oliveira " luismbo@gmail.com Cc: cffi-devel@common-lisp.net Message-ID: 6fd384780702131242i1f2b1a5ci2780bb7d9939fcab@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