cffi-devel February 2007

cffi-devel@common-lisp.net

17 participants
19 discussions

[cffi-devel] Documentation Feature Request
by Heiko Schröter 27 Feb '07

27 Feb '07

Hello list, sorry if this has been asked before. I've been trying to interface sbcl to the gsl library especially passing vectors and/or matrices. The docs state that there is no :array type. Is it somehow possible to interface to the gsl library to do e.g. spline or matrix ops ? If it is possible it would be nice to have one or two examples in the docs. Thanks and Regards Heiko Schroeter

3 2

[cffi-devel] Get 1000's of Highly Targeted visitors to your web site or affiliate web site overnight
by Instant＠common-lisp.net 27 Feb '07

27 Feb '07

1 0

[cffi-devel] How would you like 2 Million Sites linking to your ad ?
by BlogBlaster＠common-lisp.net 24 Feb '07

24 Feb '07

1 0

[cffi-devel] Foreign string encodings
by Luís Oliveira 24 Feb '07

24 Feb '07

Hello, Just letting this list know that the cffi-newtypes branch at <http://common-lisp.net/~loliveira/darcs/cffi-newtypes/> includes, in addition to the new type system, a forward port of James' cffi-encodings branch. In addition to CLISP and SBCL support already provided by the cffi-encodings patches, cffi-newtypes includes support for OpenMCL, Lispworks and Allegro. The original discussion can be found here: Subject: a thought on string encodings <http://thread.gmane.org/gmane.lisp.cffi.devel/292> -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

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

22 Feb '07

[hmm, it seems my previous message didn't go to the list by mistake] On 22/02/07, Luís Oliveira <luismbo(a)gmail.com> wrote: > There's no rush. We should get this right. I put my changes here: > <http://common-lisp.net/~loliveira/darcs/cffi-newtypes/>. It includes > some updated documentation. Here are some random thoughts after a few days of using this. - There's no direct way of doing inheritance with enum, bitfield, union or struct types. One can use composition, of course, so it's not too terrible. - No inheritance for define-parse-method either. One way to minimize the effects of this would be to make the :simple-parser option smarter that would, for instance, look at the class' initargs and automatically add those to the parser's lambda list as keyword arguments. - I'm not sure I like the name :simple-parser. Maybe :default-parser. - The common case of defining new types with translations but no arguments got slightly more verbose. Not sure if it's worth worrying about this. - I suppose we should export foreign-string-type, foreign-boolean-type, foreign-pointer-type, etc, so the users can extend these. - That reminds that :actual-type might be misleading coming from the previous system. Specifying :actual-type :string won't inherit any of foreign-string-type's translators, for instance. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

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

21 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 14 Feb '07

14 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

[cffi-devel] CLisp exe vs FFI
by Ken Tilton 13 Feb '07

13 Feb '07

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

1 0

[cffi-devel] C++ Exceptions.
by Collin Lynch 12 Feb '07

12 Feb '07

First, thanks for making this system, and apologies if this isn;t the list for these questions but there appears to be no cffi-users list. In any case, is there any way to catch the underlying c++ exceptions within a cffi-wrapper? I have developed a C++ library that defines its own exceptions and I would like to trap them and generate an appropriate Lisp Condition. At present deliberately triggering an error (say by passingincorrect parameters to a constructor) gives me back a null pointer. Thanks, Collin Lynch.

4 5

Re: [cffi-devel] calls with variable number of arguments which are determined at run-time
by James Bielman 09 Feb '07

09 Feb '07

Lars Rune Nøstdal <larsnostdal(a)gmail.com> writes: > Anyone have some suggestions as to how I can call foreign-functions > with variable number (the count, types and values determined at > run-time!) of arguments? > > I've nagged the CLL'ers about this and Pillsy came up with a hack > that works: > > I was wondering if there where better ways to do this? Hi Lars, Off the top of my head, I think any reasonable approach is going to need to involve calling the compiler. Only the compiler knows how to actually build the stack frames and such for the call. For example, there are arcane rules on some architectures about whether floating point values are passed on the stack or in registers depending on the number of arguments and their positions. One possibility for making it a little less gruesome performance-wise is to build a cache of precompiled functions for a set of function types. For each distinct set of argument types you can COMPILE a lambda that builds the appropriate FOREIGN-FUNCALL, and store it in an EQUAL hashtable with the list of arguments (:INT :FLOAT). What's the use case for this? Surely not sprintf; there's about a million better ways to format text without resorting to such things... ;-) Down with varargs! James

4 3

[cffi-devel] calls with variable number of arguments which are determined at run-time
by Lars Rune Nøstdal 08 Feb '07

08 Feb '07

Hey, Anyone have some suggestions as to how I can call foreign-functions with variable number (the count, types and values determined at run-time!) of arguments? I've nagged the CLL'ers about this and Pillsy came up with a hack that works: http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/cec20dff595… I was wondering if there where better ways to do this? -- Lars Rune Nøstdal http://nostdal.org/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel February 2007