November 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] New patches: 25-Nov-2009
by Luis Oliveira 26 Nov '09

26 Nov '09

Tue Nov 24 18:20:02 EST 2009 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-manual: the :STRING type does not support ub8 arrays anymore M ./doc/cffi-manual.texinfo -8 +2 Tue Nov 24 18:17:41 EST 2009 Luis Oliveira <loliveira(a)common-lisp.net> * libtest: support 64-bit on OSX Leopard M ./tests/GNUmakefile -6 +8 Tue Nov 24 18:14:42 EST 2009 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-tests: show Lispworks the full path to libm.dylib M ./tests/bindings.lisp +2 Tue Nov 24 18:13:21 EST 2009 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-lispworks: turns out Lispworks does support llong on 32-bit platforms M ./src/cffi-lispworks.lisp -2 +2 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-091125.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] CFFI problem in Lispworks 5.1 32-bit with :long-long emulation
by Matt Lamari 24 Nov '09

24 Nov '09

The problem manifests itself while trying to compile the latest CL-SQLite; but can be replicated with: (defcfun test :int64) Error: :LONG-LONG fell through ECASE expression. Wanted one of (:CHAR :UNSIGNED-CHAR :SHORT :UNSIGNED-SHORT :INT :UNSIGNED-INT :LONG :UNSIGNED-LONG :FLOAT :DOUBLE :POINTER :VOID). 1 (abort) Return to level 0. 2 Return to top loop level 0. The long-long gets through and fails in the lispworks-specific "Ecase" (that has them removed for non-64-bit lispworks). It looks as though something higher up is meant to filter/emulate this. There seems to be emulation code in types.lisp The :long-long comes from the method (defmethod canonicalize ((tp emulated-llong)) :long-long) But somehow this :long-long proliferates down all the way to the lispworks-specific code. By the way, and I don't know if this is relevant; but (fli:size-of '(:long :long :int)) returns 8 in this Lispworks - I mention it only as someone on #lisp asked me to try it. How should I proceed? Thanks, Matt

2 1

[cffi-devel] GC write-protected mappings vs. the OS kernel
by Samium Gromoff 11 Nov '09

11 Nov '09

Good day, While debugging mysterious ioctl() failures in lh-usb on SBCL, I have discovered that using CFFI:WITH-POINTER-TO-VECTOR-DATA doesn't guarantee that the vector is in a writable region. Normally, with userspace code, this isn't a problem, because, as pointed on #lisp, the SEGV is handled by the lisp runtime and the user code is resumed. However this, understandably, interacts badly with kernel's expectations, which simply refuses to write to a write-protected region. That is where my discovery ended, and a discussion on #lisp ensued, including, among others, Alastair Bridgewater, James Knight and Paul Khuong. The rough consensus seemed to be (correct me if I got this wrong) that SBCL needs to provide an abstraction for the missing operation, as the chances of kernel adopting a mechanism allowing to perform syscall continuation[1] through invocation of user-provided fault handlers are pretty slim. While thinking about this I have stumbled upon: http://common-lisp.net/project/cffi/darcs/cffi/doc/shareable-vectors.txt which says: The implementation must guarantee the memory pointed to by PTR-VAR will not be moved during the dynamic contour of this operator, either by creating the vector in a static area or temporarily disabling the garbage collector. IMO, this could be extended with specification of required protections. regards, Samium Gromoff -- 1. We can't just restart the syscall, as we might be unwilling to reexecute the side-effects which happened in-kernel up to the fault point. Of course this leads us to PCLSRing.. _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

3 5

Re: [cffi-devel] memutil.lisp breaks compile
by Sebastian Tennant 08 Nov '09

08 Nov '09

Quoth Henrik Hjelte <henrik(a)evahjelte.com>: > http://www.mail-archive.com/cffi-devel@common-lisp.net/msg01656.html This link appears to be broken (404 Not Found). Was it intended to point to this conversation: http://thread.gmane.org/gmane.lisp.cffi.devel/1720 by chance? > If there is a problem compiling it is usually because a version of cffi > pretends to be uffi, and the cffi developers refuses to fix this. Opinion is divided. To name but a few: Jeff Cunningham and Hans Hübner think it should be renamed. Luís Olivera and Daniel Herring think it's best left as it is. Luís is concerned about breaking things that depend on (or at least benefit from) his kludge (no offence intended). Daniel Herring makes the point that hijacking names to provide upgarde/compatibility layers is a time-honoured tradition. In my humble opinion, hijacking names works for comprehensive drop-in replacements based on consensus amongst parties. CFFI is clearly not a comprehensive drop-in replacement for UFFI and there's clearly no consensus on the issue. I'm therefore in favour of changing the name. Can't packages that 'use' UFFI (but really use CFFI) be easily updated like so: sed -i~ 's/\<uffi\>$::\?$/cffi\1/g' *.lisp > If this is the case, you might want to remind them to fix this on their > mailing list. Cross-posted to cffi-devel. Regarding the original subject, elephant now compiles, but not when using clbuild's recompile command. $ ./clbuild clean elephant $ ./clbuild recompile elephant [...] WARNING: COMPILE-FILE warned while performing #<COMPILE-OP (:VERBOSE NIL) {10036E8E81}> on #<CL-SOURCE-FILE "memutil" {100399B3A1}>. unhandled ASDF:COMPILE-FAILED in thread #<SB-THREAD:THREAD "initial thread" RUNNING {100361EDE1}>: erred while invoking #<COMPILE-OP (:VERBOSE NIL) {10036E8E81}> on #<CL-SOURCE-FILE "memutil" {100399B3A1}> However, if I issue the command again the same warning is issued but about a different file (serializer2.lisp) so it's nothing to do with memutil.lisp per se. Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap

2 1

[cffi-devel] trivial-features
by Luke J Crook 03 Nov '09

03 Nov '09

The latest version of trivial-features no longer works in Edi's Lisp Starter- Pack, which now returns the following error during the unpacking process; Error with invalid byte: 10 in #(110 32 116 104 101 10 107 101). Was the package built differently to the previous working release? - Luke

2 1