- cffi-devel - mailman3.common-lisp.net

[cffi-devel] New patches: 21-Feb-2007
by loliveira＠common-lisp.net 22 Feb '07

22 Feb '07

Wed Feb 21 19:52:13 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * New file: uffi-compat/uffi.asd A ./uffi-compat/uffi.asd Wed Feb 21 19:49:17 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * Update TODO list Removed some stuff that's already been implemented, etc... M ./TODO -15 +4 Wed Feb 21 19:08:28 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * Simplify load-foreign-library-error. M ./src/libraries.lisp -5 +4 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-070221.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] Summary of junk emails blocked
by Admin Junk Summary 21 Feb '07

21 Feb '07

Junk Box Summary for: cffi-devel(a)common-lisp.net The 1 emails listed below have been placed in your personal Junk Box since your last Junk Box Summary and will be deleted after 7 days. To retrieve any of these messages, visit your Junk Box at: <http://apollo.qtlc.it> Login using your standard username/password combination. Junk Box Summary --------------------------------------------------------------------- oiweybajg(a)netflash.com.br 500.- start bonus, play 1 hour for free and keep all wins --------------------------------------------------------------------- Junk blocking by MailFrontier, Inc.

1 0

Re: [cffi-devel] Messing with foreign types some more
by Luís Oliveira 18 Feb '07

18 Feb '07

On 18/02/07, Robert Goldman <rpgoldman(a)real-time.com> wrote: > I was just looking at this and wondering if it would bust my port of > mcclim's freetype from SBCL-specific aliens to CFFI. It won't, because AFAICT you don't use type translation at all in that code. The gtkcairo bindings should have no problems either. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

[cffi-devel] Messing with foreign types some more
by Luís Oliveira 17 Feb '07

17 Feb '07

Hello, I just had another go at simplifying the type system. Here's an overview of what changed: 1 - (DEFCTYPE new-type base-type) becomes just a simple way of defining an alias. The user cannot define translations for new-type and there will be no translation overhead unless base-type already has translations. This removes the need for the :TRANSLATE-P optimization option. 2 - The new macro (DEFINE-FOREIGN-TYPE new-type supers slots &rest options) becomes the canonical way of defining complex types with translations. This is a thin wrapper around DEFCLASS. 2a - The new macro (DEFINE-PARSE-METHOD type-name lambda-list &body body) will be used to parse the type specifications (e.g. '(:string :encoding :utf-8)) and should return an instance of a subclass of FOREIGN-TYPE. 2b - Translator/expander methods should now specialize on type instead of using EQL specializers. So now the type specifications can easily take options through the above parse-method, save them in some slot (defined through DEFINE-FOREIGN-TYPE) and -- here's the big advantage -- the translators can have a look at those options and take appropriate action. 2c - For the simple case where the user wants to define a translation but doesn't need to parse options, DEFINE-FOREIGN-TYPE takes a (:SIMPLE-PARSER name) option that will automatically generate: (define-parse-method name () (make-instance 'some-type)) 3 - The translator generic functions no longer have that ad-hoc method combination. If the user wants to chain the translations of her type's superclasses then she should invoke CALL-NEXT-METHOD explicitly. I believe this method combination of ours was crippling inheritance. Compare the new :string+ptr type definition with the previous one for an example of what I mean. A side-effect of these changes is that we no longer need two separate mechanisms for dealing with real types (instances of FOREIGN-TYPE) and user types (plain symbols). That translates into ~100 less lines of code. Here's the patch: <http://common-lisp.net/~loliveira/patches/more-foreign-types.diff> This is heavily backwards incompatible wrt the type system interface so I'll wait and see if there any objections before I commit it. Comments and suggestions are welcome, as usual. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

[cffi-devel] CLisp finalizers
by Marco Gidde 15 Feb '07

15 Feb '07

Hi, as mentioned on this list CLisp has some problems with the finalization code provided by CFFI. I guess this is due to accessing the weak hash table within the finalizer. The following code works around this problem by closing the "main finalizer" over the list of the "sub finalizers". (in-package :cffi-sys) (defvar *finalizers* (make-hash-table :test 'eq :weak :key) "Weak hashtable that holds registered finalizers.") (defun finalize (object function) "Pushes a new FUNCTION to the OBJECT's list of finalizers. FUNCTION should take no arguments. Returns OBJECT. For portability reasons, FUNCTION should not attempt to look at OBJECT by closing over it because, in some lisps, OBJECT will already have been garbage collected and is therefore not accessible when FUNCTION is invoked." (multiple-value-bind (finalizers present-p) (gethash object *finalizers* (cons 'finalizers nil)) (unless present-p (setf (gethash object *finalizers*) finalizers) (ext:finalize object (lambda (obj) (declare (ignore obj)) (mapc #'funcall (cdr finalizers))))) (push function (cdr finalizers))) object) (defun cancel-finalization (object) "Cancels all of OBJECT's finalizers, if any." (multiple-value-bind (finalizers present-p) (gethash object *finalizers*) (when present-p (setf (cdr finalizers) nil))) (remhash object *finalizers*)) While this code isn't as short and elegant as the original code, at least it works ;-) Regards, Marco

3 6

[cffi-devel] New patches: 14-Feb-2007
by loliveira＠common-lisp.net 15 Feb '07

15 Feb '07

Wed Feb 14 14:54:57 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * Fix load-foreign-library bug load-foreign-library wasn't accepting non-symbol library designators correctly. Bug reported by Stelian Ionescu. M ./src/libraries.lisp -1 +1 Wed Feb 14 09:42:15 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * Update documentation with stdcall/namespace/close-foreign-library changes M ./doc/cffi-manual.texinfo -18 +194 Wed Feb 14 08:22:12 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * Fix conflict M ./src/cffi-clisp.lisp -1 +3 Wed Feb 14 07:57:26 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * Generate more meaningful errors for invalid enums Reported by Lars Nostdal. M ./TODO +1 M ./src/enum.lisp -2 +2 Wed Feb 14 07:53:18 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * Remove finalizers. Users can use trivial-garbage instead. M ./doc/cffi-manual.texinfo -107 M ./src/cffi-allegro.lisp -27 +1 M ./src/cffi-clisp.lisp -26 +1 M ./src/cffi-cmucl.lisp -19 +1 M ./src/cffi-corman.lisp -40 +1 M ./src/cffi-ecl.lisp -14 +1 M ./src/cffi-lispworks.lisp -32 +1 M ./src/cffi-openmcl.lisp -31 +1 M ./src/cffi-sbcl.lisp -21 +1 M ./src/cffi-scl.lisp -22 +1 M ./src/features.lisp -1 M ./src/package.lisp -4 Wed Feb 14 07:40:58 EST 2007 Luis Oliveira <loliveira(a)common-lisp.net> * stdcall, namespaces, close-foreign-library Three new features: - stdcall (defcfun, foreign-funcall(-pointer), defcallback) - namespaces, associate foreigns vars and functions to a specific library. (CLISP and Lispworks only) - close-foreign-library actually works now. Backwards incompatible changes: - define-foreign-library's syntax changed slightly, can't load more than one foreign library per define-foreign-library form anymore. - defcvar's syntax changed. - foreign-funcall can't funcall pointers anymore. Use foreign-funcall-pointer for that. M ./src/cffi-allegro.lisp -18 +33 M! ./src/cffi-clisp.lisp -50 +68 M ./src/cffi-cmucl.lisp -26 +31 M ./src/cffi-corman.lisp -10 +14 M ./src/cffi-ecl.lisp -10 +21 M ./src/cffi-gcl.lisp -2 +2 M ./src/cffi-lispworks.lisp -21 +32 M ./src/cffi-openmcl.lisp -10 +18 M ./src/cffi-sbcl.lisp -12 +20 M ./src/cffi-scl.lisp -9 +17 M ./src/early-types.lisp -2 +2 M ./src/features.lisp -9 +38 M ./src/foreign-vars.lisp -45 +49 M ./src/functions.lisp -55 +150 M ./src/libraries.lisp -98 +111 M ./src/package.lisp -2 +4 M ./src/types.lisp -2 +3 M ./tests/Makefile -1 +4 M ./tests/bindings.lisp -5 +17 M ./tests/callbacks.lisp -23 +42 M ./tests/compile.bat +3 M ./tests/defcfun.lisp -4 +30 M ./tests/foreign-globals.lisp -2 +49 M ./tests/funcall.lisp -3 +23 M ./tests/libtest.c -3 +57 A ./tests/libtest2.c M ./tests/misc-types.lisp -2 +2 M ./tests/misc.lisp -3 +38 M ./tests/struct.lisp -1 +1 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-070214.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] Lisp 5, Edgar 2 (and gaining)
by Ken Tilton 14 Feb '07

14 Feb '07

cffi-devel-request(a)common-lisp.net wrote: >Send cffi-devel mailing list submissions to > cffi-devel(a)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(a)common-lisp.net > >You can reach the person managing the list at > cffi-devel-owner(a)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(a)gmail.com> >Subject: [cffi-devel] CLisp exe vs FFI >To: cffi-devel(a)common-lisp.net >Message-ID: <45D20935.9010009(a)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(a)gmail.com> >Subject: Re: [cffi-devel] Re: Clisp, cffi and defcfuns in a saved > image >To: " Lu?s Oliveira " <luismbo(a)gmail.com> >Cc: cffi-devel(a)common-lisp.net >Message-ID: > <6fd384780702131242i1f2b1a5ci2780bb7d9939fcab(a)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

2 2

[cffi-devel] New features
by Luís Oliveira 14 Feb '07

14 Feb '07

Hello, I've pushed a bunch of changes. Now there's support for stdcall, namespaces (only CLISP and Lispworks support them though) and close-foreign-library. It includes the syntactic changes I talked about a while ago. Those of you who were interested in stdcall and namespaces please test. :-) -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

2 2

[cffi-devel] cffi-clisp.lisp multiple-value-bind usage of variable "error" conflicts with another package
by Fred Stone 14 Feb '07

14 Feb '07

I am attempting to use cffi on a Clisp 2.41 build running under Cygwin. I can get cffi to load using asdf, but when I loaded a package that uses cffi, I got an error message "ERROR is a constant: may not be used as a variable". In cffi-clisp.lisp, around line 234; (multiple-value-bind (ff error) ... is causing the problem. I patched this to: (multiple-value-bind (ff fferror) and also corrected the subsequent two references to error on lines 249 and 250 and managed to get past this particular problem. In trying to localize the source of the name conflict, it appears that one of the optional modules that I have included in Clisp is the source of the conflit. These would include GDI, PCRE, RAWSOCK, LDAP, FASTCGI or ZLIB. The BASE build without the optional modules didn't have the name conflict, while the FULL build does. I have not determined which of the modules above was defining the constant "error".

2 1

[cffi-devel] Re: Clisp, cffi and defcfuns in a saved image
by Edgar Gonçalves 13 Feb '07

13 Feb '07

Greetings! I'm not really sure if this is a CFFI or a CLISP issue, so I'm posting to both ml's. I'm trying to make Windows executables images, using Clisp 2.41 (built with readline, iconv and sigsegv). My images have cl projects loaded, like clsql or celltk. These projects relly on cffi to load functions from certain dll's (like odbc32.dll). E.g., I load clsql and save an image. There are two problems here: 1) Unlike AllegroCL or Lispworks, Clisp (and SBCL too, btw) requires me to precede all defcfuns related to a library with: #+clisp (cffi::use-foreign-library Tcl) (defcfun ("Tcl_FindExecutable" tcl-find-executable) :void (argv0 :string)) If I don't do this, I can't apply this function at run-time (I'm not even talking about saved images, yet). 2) When I load the saved image (using the code from above), I get an error when applying defcfun'ed functions, telling me the library wasn't found: ** - Continuable Error FFI::FOREIGN-CALL-OUT: no dynamic object named "SQLAllocHandle" in library :DEFAULT But then, if I tell clisp where the libraries are, with (cffi:define-foreign-library odbc (t (:default "odbc32"))) (cffi:use-foreign-library odbc) , I get this: *** - FFI::FOREIGN-CALL-OUT: #<INVALID FOREIGN-POINTER #x00000000> comes from a previous Lisp session and is invalid The only workaround I can think of is to make an init-function on my image that loads all these defcfuns (at run-time), but this is not very sane, if you are to use many external CL libraries! Thanks for the help, -- Edgar Gonçalves

2 7