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
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
Subject: [cffi-devel] CLisp exe vs FFI
To: cffi-devel@common-lisp.net
Message-ID: <[EMAIL PROTECTED]>
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 " <[EMAIL PROTECTED]>
Subject: Re: [cffi-devel] Re: Clisp, cffi and defcfuns in a saved
image
To: " Lu?s Oliveira " <[EMAIL PROTECTED]>
Cc: cffi-devel@common-lisp.net
Message-ID:
<[EMAIL PROTECTED]>
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?
