cffi-devel December 2009

cffi-devel@common-lisp.net

8 participants
6 discussions

[cffi-devel] Foreign structures by value
by Liam Healy 26 Aug '10

26 Aug '10

I have written Foreign Structures By Value (FSBV) to allow calling foreign functions while passing or returning structures by value. It uses CFFI and libffi. It currently provides two macros for users, fsbv:defcstruct and fsbv:foreign-funcall, which are used exactly like their CFFI counterparts. It works for small test cases I've tried, but probably could use some improvement. If the keepers of CFFI are interested, I would be happy for it to be included in CFFI. In the meantime, it can be found here: http://repo.or.cz/w/fsbv.git Thank you. Liam

2 3

[cffi-devel] %load-foreign-library on SBCL
by Elliott Slaughter 27 Jan '10

27 Jan '10

Hi, I have a question about the implementation of %load-foreign-library on SBCL. It seems that the call to load-shared-object remembers the absolute pathname to the library that is loaded unless :dont-save t is used. This causes portability issues for my application, which can't load from the same path when used on different systems. Is there any reason to choose this behavior? Of course, with :dont-save t, the user then has to call use-foreign-library again when starting up from the saved image, but I find this preferable to the crash I receive otherwise. An example patch is included below. Thanks. --- src/cffi-sbcl.lisp~ 2009-04-14 19:33:40.000000000 -0700 +++ src/cffi-sbcl.lisp 2009-04-03 15:28:37.000000000 -0700 @@ -324,7 +324,7 @@ (defun %load-foreign-library (name path) "Load a foreign library." (declare (ignore name)) - (load-shared-object path)) + (load-shared-object path :dont-save t)) ;;; SBCL 1.0.21.15 renamed SB-ALIEN::SHARED-OBJECT-FILE but introduced ;;; SB-ALIEN:UNLOAD-SHARED-OBJECT which we can use instead. -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

3 10

[cffi-devel] (no subject)
by Stelian Ionescu 24 Dec '09

24 Dec '09

I have (cffi:define-foreign-library sdl-glue (:windows "lispbuilder-sdl-glue.dll")) (use-foreign-library sdl-glue) On Linux, this returns fine, although it doesn't load any library. I see code in lispbuilder-sdl that relies on it signaling an error. Is it a regression ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

4 9

Re: [cffi-devel] CFFI problem in Lispworks 5.1 32-bit with :long-long emulation
by Luís Oliveira 23 Dec '09

23 Dec '09

On Wed, Dec 23, 2009 at 4:07 AM, Matt Lamari <matt.lamari(a)gmail.com> wrote: > > Sorry for the late response. > > I don't have the code/opportunity to test all the cases; but wonder if > the enclosed patch - touching all the #+lispworks-64bit, is what's > really needed. . . ? Well, could you tell me whether my previous patch works for you and why you need this one? > I.e. every 64-bit replaced with (or lispworks5.1 lispworks-64bit) > or the like > > > > > Luís Oliveira wrote: >> On Thu, Nov 19, 2009 at 5:33 PM, Matt Lamari <matt.lamari(a)gmail.com> wrote: >> >>> (defcfun test :int64) >>> >> [...] >> >>> The long-long gets through and fails in the lispworks-specific "Ecase" >>> (that has them removed for non-64-bit lispworks). >>> >> >> Long-long emulation is not implemented for DEFCFUN, DEFCALLBACK, etc. >> It turns out that Lispworks does in fact support long-long on 32-bit >> platforms for DEFCFUN at least. Please let me know if the attached >> patch works for you. >> >> > > > --- cffi-lispworks.lisp 2009-06-16 11:20:08.000000000 -0500 > +++ c:\t\cffi-lispworks.lisp 2009-12-22 22:04:10.350220400 -0600 > @@ -62,7 +62,7 @@ > > ;;;# Misfeatures > > -#-lispworks-64bit (pushnew 'no-long-long *features*) > +#-(or lispworks5.1 lispworks-64bit) (pushnew 'no-long-long *features*) > > ;;;# Symbol Case > > @@ -156,9 +156,9 @@ > (:unsigned-int '(:unsigned :int)) > (:long :long) > (:unsigned-long '(:unsigned :long)) > - #+lispworks-64bit > + #+(or lispworks5.1 lispworks-64bit) > (:long-long '(:long :long)) > - #+lispworks-64bit > + #+(or lispworks5.1 lispworks-64bit) > (:unsigned-long-long '(:unsigned :long :long)) > (:float :float) > (:double :double) > @@ -170,10 +170,10 @@ > #+#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and) '(or)) > (defun convert-foreign-typed-aref-type (cffi-type) > (ecase cffi-type > - ((:char :short :int :long #+lispworks-64bit :long-long) > + ((:char :short :int :long #+(or lispworks5.1 lispworks-64bit) :long-long) > `(signed-byte ,(* 8 (%foreign-type-size cffi-type)))) > ((:unsigned-char :unsigned-short :unsigned-int :unsigned-long > - #+lispworks-64bit :unsigned-long-long) > + #+(or lispworks5.1 lispworks-64bit) :unsigned-long-long) > `(unsigned-byte ,(* 8 (%foreign-type-size cffi-type)))) > (:float 'single-float) > (:double 'double-float))) > @@ -186,7 +186,7 @@ > > ;; Lispworks 5.0 on 64-bit platforms doesn't have [u]int64 support in > ;; FOREIGN-TYPED-AREF. That was implemented in 5.1. > -#+(and lispworks-64bit lispworks5.0) > +#+(and (or lispworks5.1 lispworks-64bit) lispworks5.0) > (defun 64-bit-type-p (type) > (member type '(:long :unsigned-long :long-long :unsigned-long-long))) > > @@ -196,7 +196,7 @@ > (define-compiler-macro %mem-ref (&whole form ptr type &optional (off 0)) > (if (constantp type) > (let ((type (eval type))) > - (if (or #+(and lispworks-64bit lispworks5.0) (64-bit-type-p type) > + (if (or #+(and (or lispworks5.1 lispworks-64bit) lispworks5.0) (64-bit-type-p type) > (eql type :pointer)) > (let ((fli-type (convert-foreign-type type)) > (ptr-form (if (eql off 0) ptr `(inc-pointer ,ptr ,off)))) > @@ -230,7 +230,7 @@ > (if (constantp type) > (once-only (val) > (let ((type (eval type))) > - (if (or #+(and lispworks-64bit lispworks5.0) (64-bit-type-p type) > + (if (or #+(and (or lispworks5.1 lispworks-64bit) lispworks5.0) (64-bit-type-p type) > (eql type :pointer)) > (let ((fli-type (convert-foreign-type type)) > (ptr-form (if (eql off 0) ptr `(inc-pointer ,ptr ,off)))) > > -- Luís Oliveira http://r42.eu/~luis/

2 1

[cffi-devel] New patches: 11-Dec-2009
by Luis Oliveira 12 Dec '09

12 Dec '09

Fri Dec 11 11:49:38 EST 2009 Stelian Ionescu <sionescu(a)cddr.org> * Update email address. M ./grovel/grovel.lisp -1 +1 Fri Dec 11 11:49:09 EST 2009 Stelian Ionescu <sionescu(a)cddr.org> * Remove spurious PRINT call. M ./grovel/asdf.lisp -1 +1 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-091211.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] plural forms for WITH-FOREIGN-POINTER and in general
by Tamas K Papp 10 Dec '09

10 Dec '09

Hi, Two suggestions: 1. Could we have a plural form of WITH-FOREIGN-POINTER (similarly to WITH-FOREIGN-OBJECTS, WITH-FOREIGN-STRINGS). 2. In my own code, I usually use something like this: (defmacro with-multiple-bindings (macro) "Define a version of `macro' with multiple arguments, given as a list. Application of `macro' will be nested. The new name is the plural of the old one (generated using format)." (let ((plural (intern (format nil "~aS" macro)))) `(defmacro ,plural (bindings &body body) ,(format nil "Multiple binding version of ~(~a~)." macro) (if bindings `(,',macro ,(car bindings) (,',plural ,(cdr bindings) ,@body)) `(progn ,@body))))) (with-multiple-bindings with-foreign-pointer) Incorporating something similar would replace the repetitions in the CFFI code, and make it easier to define plural forms. Cheers, Tamas

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel December 2009