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

[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] Support for cleanup actions on arguments performed when callback returns
by Kalyanov Dmitry 26 Jul '09

26 Jul '09

I am trying to create a binding for gobject library with CFFI. CFFI works extremely well, however I have a use case that is not covered by CFFI. Basically, I want to define foreign types that should "clean up" after themselves when they are used as types for callback arguments. I have following use cases for this: 1) I want to have a structure created when callback is entered and have its contents copied to foreign structure when callback returns. 2) I want to have wrappers that contain a pointer to foreign structure. However, I want to ensure that operations on wrapper signal errors when callback returns (because pointer points to a stack-allocated structure). This is needed to ensure that no operations are done on invalid pointer. The attached patch provides suggested change: foreign types may specify that additional actions should be performed when the callback returns. This is achieved by adding new generic function CLEANUP-TRANSLATED-OBJECT-FOR- CALLBACK. Additional generic function HAS-CALLBACK-CLEANUP is called at macroexpansion time as an optimization to remove unnecessary calls to CLEANUP- TRANSLATED-OBJECT-FOR-CALLBACK. Attached is a test case that demonstrates the usage and checks for correctness of behavior. If there are obstacles for adding this patch, I would be happy to work on them.

1 0

[cffi-devel] New patches: 25-Jul-2009
by Luis Oliveira 26 Jul '09

26 Jul '09

Sat Jul 25 19:13:30 EDT 2009 Luis Oliveira <loliveira(a)common-lisp.net> * ECL: support more vector types in CFFI-SYS:WITH-POINTER-TO-VECTOR-DATA Patch courtesy of Andy Hefner. M ./src/cffi-ecl.lisp -2 +19 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-090725.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] More element types for with-pointer-to-vector-data on ECL
by Andy Hefner 25 Jul '09

25 Jul '09

Here's a darcs patch to add support for every reasonable specialized array type in ECL: ([un]signed-byte [8,16,32,64]), single-float, double-float, bit, base-char, character.

2 2

[cffi-devel] [PATCH] 64-bit support for Allegro, and allocate stack objects in the static area
by John Fremlin 17 Jul '09

17 Jul '09

Happy new year! On 64-bit Allegro, run (cffi:defcfun strerror :string (errnum :int)) (strerror 1) and you will probably get Received signal number 4 (Illegal instruction) [Condition of type EXCL:SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL] at least if the returned pointer is more than 32-bits. The problem is that without this patch, cffi-allegro.lisp does not support 64-bit pointers. Does the patch address the problem properly? It seems to work for us. The use of :unsigned-nat instead of :unsigned-long is recommended by Franz because on Windows 64-bit :unsigned-long is still 32-bits. --- a/addons/cffi_0.10.3/src/cffi-allegro.lisp +++ b/addons/cffi_0.10.3/src/cffi-allegro.lisp @@ -135,7 +135,7 @@ SIZE-VAR is supplied, it will be bound to SIZE during BODY." ;; stack allocation pattern `(let ((,size-var ,size)) (declare (ignorable ,size-var)) - (ff:with-stack-fobject (,var '(:array :char ,size)) + (ff:with-stack-fobject (,var '(:array :char ,size) :allocation :foreign-static-gc) (let ((,var (ff:fslot-address ,var))) ;; (excl::stack-allocated-p var) => T ,@body)))) @@ -263,12 +263,12 @@ SIZE-VAR is supplied, it will be bound to SIZE during BODY." :unsigned-long) 'integer) (:float 'single-float) (:double 'double-float) - (:foreign-address :foreign-address) + (:foreign-address 'integer) (:void 'null)))) (defun foreign-allegro-type (type) (if (eq type :foreign-address) - nil + :unsigned-nat type)) (defun allegro-type-pair (type)

4 17

[cffi-devel] cffi-tests: What is package RTEST?
by Jean-Claude Beaudoin 13 Jul '09

13 Jul '09

I am trying to run cffi-tests.asd on ECL (9.6.2 with fixes, Fedora 11 Linux, i386) and it ends up in the debugger stating: There is no package with the name RTEST. In fact it complains about this line found in strings.lisp on line 86: (pushnew 'string.encoding.utf-16.basic rtest::*expected-failures*) Should I understand that RTEST is meant to be a nickname of the package loaded by (require 'rt)? BTW, that package has name SB-RT on ECL (and SBCL also I think) and has nicknames RT and REGRESSION-TEST only. Cheers, Jean-Claude Beaudoin

2 1

[cffi-devel] New patches: 10-Jul-2009
by Luis Oliveira 11 Jul '09

11 Jul '09

Fri Jul 10 14:08:32 EDT 2009 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-openmcl: prepend _ to external names on #+darwin, not just #+darwinppc M ./src/cffi-openmcl.lisp -2 +2 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-090710.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] Foreign-library enhancements
by Stelian Ionescu 10 Jul '09

10 Jul '09

The attached patch adds a :type attribute to foreign libraries(:system or :wrapper), per-library search paths(needed for cffi-grovel wrappers) and a function list-foreign-libraries. It also adds the readers foreign-library-type, foreign-library-search-path and foreign-library-loaded-p. Any objections against merging this ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

4 6

Re: [cffi-devel] librt soname
by Luis Oliveira 06 Jul '09

06 Jul '09

Andy Hefner <ahefner(a)gmail.com> writes: > (define-foreign-library librt > (:linux (:or "librt.so" "/usr/lib/librt.so"))) > (use-foreign-library librt) > > Despite my uncertain understanding of the rules for shared library > naming (and for that matter, where librt is expected to reside), I > think the following definition is preferable: > > (define-foreign-library librt > (:linux (:or "librt.so.1" "/lib/librt.so.1"))) > (use-foreign-library librt) It used to be librt.so.1, but it was changed to librt.so, not sure why. Is there any system where "librt.so.1" doesn't work but "/lib/librt.so.1" would? Wouldn't (:or "librt.so" "librt.so.1") work best? By the way, I've been thinking off and on about how to handle this library reloading business automatically. Would two new CFFI functions -- PREPARE-LIBRARIES-FOR-DELIVERY and RELOAD-LIBRARIES -- be enough for most delivery purposes? The former would close all the open libraries and store them somewhere so that the former can reopen them later when loading the core. Not all Lisps seem to offer equivalents to sb-ext:*save-hooks* and sb-ext:*init-hooks*, but in those that do we could could even push those two functions in there. I suppose there's the question of what to do with libraries distributed with the executable since that dlopen() won't find those on its own and we need to bind cffi:*foreign-library-directories* to something appropriate (E.g. osicat's wrapper.so.) Something like (pushnew '(merge-pathnames #p"libs/" (get-core-pathname)) *foreign-library-directories*) would work since, similarly to ASDF:*CENTRAL-REGISTRY*, the elements of *FOREIGN-LIBRARY-DIRECTORIES* are quasi-evaluated[1]. How are you dealing with that right now? Cheers, [1] Ugh, or they would be if a call to MINI-EVAL weren't missing in FIND-FILE in libraries.lisp. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

5 4