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

[cffi-devel] unnamed callback (closures?)
by Hoehle, Joerg-Cyril 31 Jan '06

31 Jan '06

Hi, While people certainly appreciate that CFFI provides callbacks (their current state in UFFI or Kenny Tilton's hello-c fork is unknown to me), I wonder why they apply to named functions only. In CLISP, every closure can be turned into a callback, and this is valuable since it allows to retrieve context information out of the closure. Is cffi's limitation caused by some implementations? Of course, typical C callbacks provide a void *data pointer, but I'd feel silly if I had to hide some Lisp object within such a pointer. Actually, I don't even know how to map an arbitrary Lisp object this way (it would need some awful int -> obj registration code)! The pattern I'm looking for is (defun my-application (let (x y) ...code... (register-callback 'close-window #'(lambda (data event) (return-from my-application))) (register-callback 'increase-x #'(lambda (data event) (incf x (event->value event)))) (main-loop))) Given the name limitation, I wonder whether the following work-around may be acceptable (using defcallback not at top-level). If yes, I believe the cffi manual should mention it explicitly. Otherwise, it might as well work only in N out of M implementations running cffi, and users would start to write unportable code without knowing. (defun my-callback (closure) (flet foo (defcallback ... ; problem: name is nevertheless global ;; possibly as a macro & backquotes ...))) Or (defun my-application (let (x y) (flet ((quit (data event) (return-from my-application)) (inc (data event) (incf x (event->value event)))) (defcallback close ... :body (quit date event)) (register-callback 'close-window (callback close))))) Possibly this needs a macro&backquote generator, because DEFCALLBACK registers the given name globally in a property list. Thus it disallows running multiple instances of the above. GENSYM might help, but wouldn't this be a kludge? This is quite similar to the (often undocumented) ability to use typical top-level forms in lexical contexts (e.g. the FAQ: is DEFCLASS within a function call etc. possible or not, and what happens). Many libraries don't define the semantics of their macros precisely enough. Regards, Jorg Hohle

4 3

[cffi-devel] bits from a new tutorial
by Stephen Compall 11 Jan '06

11 Jan '06

I am writing a CFFI tutorial, to be integrated into the manual when it is done if the maintainers will have it. You can get the first half or so in Texinfo format if you so desire at http://csserver.evansville.edu/~sc87/cffi/tutorial.texi . You can integrate it into cffi-manual.texi for building (if you want to see TeX, HTML, etc output) with a @include tutorial.texi For best results, put it where that comment about the manual needing a tutorial is. If you want curl.h and easy.h to follow along, they are in the same directory. Stuff left to be written about: * Dealing with memory allocation. The importance of the "Breaking the abstraction" section should become clearer here. * define-foreign-type for bits to be LOGIORed, then using that to type the input to curl_global_init. * Writing type translators. This will be used to restrict the :curl-easy-handle type. * Callbacks. This of course will be a :writefunction. * I think that error CURLcodes should "translate" to conditions. However, that is mostly macrology rather than new CFFI material, so I am not sure it should be included. * Some other stuff I can't remember right now. It depends on what I can reasonably introduce in the context of the example I've chosen. I may also consider disjoining the TYPEs in the :curl-option definition. After all, I'm breaking the abstraction, so I might as well make a better one. Some notes may be confusing at the moment. If you see one, please tell me anyway, in case it is not one I am thinking of. There is a stray TODO, and I don't yet know how I'm going to type curl_off_t portably. I will probably just remove :off-t for this tutorial. Comments are of course welcome here, and especially on Freenode #lisp, where I am S11001001. -- Stephen Compall http://scompall.nocandysw.com/blog

4 8

[cffi-devel] a thought on string encodings
by Hoehle, Joerg-Cyril 02 Jan '06

02 Jan '06

Hi, I hope encoding stuff will be the next great addition to CFFI. Here's some vague idea I once had. I got the impression that there are (at least) two types of functions: - one where the conversion depends on whatever dynamic calling context - another where the conversion is fixed, i.e. depends on the function only, not on the caller (but possibly on the library). Given CFFI's post transformers, I suspect that there's an opportunity to model both kinds of functions, i.e. - some where defcfun expands to defaults of custom:*foreign-encoding* (in CLISP speak) - some where the wrappers within defcfun impose a given encoding, e.g. ASCII, ISO-8859-1, UTF-8 or UTF16. Examples that come to mind are the GDI YouNameIt*W() functions on MS-Windows, where the strings are all UTF-16. One could use that alternatively with getenv(), which might ask for UTF-8 (or just use the default from the Lisp system). Sometimes it seems, the encoding depends on the library to which the function belongs. Just my $0.02, and I'm eager to see what kind of design you'll come up with. Regards, Jörg Höhle.

2 1

[cffi-devel] Re: CFFI Callbacks on SBCL
by Luís Oliveira 01 Jan '06

01 Jan '06

I'm Cc-ing cffi-devel and sbcl-devel, since I'm sure more people will be interested in this and hopefully others will help in figuring this out. On 2005-dec-31, at 13:59, Thomas F. Burdick wrote: > I noticed in the #lisp logs that you're having problems preserving > callbacks across image saves. SBCL already goes to quite a bit of > effort to make sure this works. From C's point of view, the callbacks > will never move. But because your library is in lisp, and persists > across image saves, from its point of view, callback objects can move > at arbitrary times. Instead of storing SAPs, you should store the > alien-value object that alien-lambda returns. If you actually need > the SAP, get it only when you need it, using alien-sap. We're not even testing if the callback moves or not. Our libtest is not saving the callbacks' address. Here's the a testcase, using sb-alien (sort of): luis@nhop:/tmp$ cat sbcl-callback.lisp (use-package :sb-alien) (define-alien-routine "qsort" void (base system-area-pointer) (nmemb int) (size int) (compar system-area-pointer)) (defparameter *callback* (sb-alien::alien-lambda int ((a system-area-pointer) (b system-area-pointer)) (let ((x (sb-sys:signed-sap-ref-32 a 0)) (y (sb-sys:signed-sap-ref-32 b 0))) (cond ((> x y) 1) ((< x y) -1) (t 0))))) (defun test () (let ((array (alien-sap (make-alien (unsigned 32) 10)))) (dotimes (i 10) (setf (sb-sys:signed-sap-ref-32 array (* i 4)) (nth i '(7 2 8 9 6 1 10 3 5 4)))) (qsort array 10 4 (alien-sap *callback*)) (dotimes (i 10) (format t "~A " (sb-sys:signed-sap-ref-32 array (* i 4)))) (free-alien (sap-alien array (* (unsigned 32)))))) luis@nhop:/tmp$ sbcl --sysinit /dev/null --userinit /dev/null This is SBCL 0.9.8.3, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (load "sbcl-callback.lisp") T * (test) 1 2 3 4 5 6 7 8 9 10 NIL * (sb-ext:save-lisp-and-die "test.core") [undoing binding stack and other enclosing state... done] [saving current Lisp image into /tmp/test.core: writing 1584 bytes from the read-only space at 0x01000000 writing 1368 bytes from the static space at 0x05000000 writing 22609920 bytes from the dynamic space at 0x09000000 done] luis@nhop:/tmp$ sbcl --core test.core This is SBCL 0.9.8.3, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (test) debugger invoked on a SB-KERNEL::MEMORY-FAULT-ERROR: memory fault Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-KERNEL::MEMORY-FAULT-ERROR) 0] Any pointers? Well, I'm off to party. Happy new year! -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

2 1

[cffi-devel] New patches: 31-Dec-2005
by loliveira＠common-lisp.net 31 Dec '05

31 Dec '05

Sat Dec 31 00:39:59 CET 2005 James Bielman <jamesjb(a)jamesjb.com> * support Allegro CL and CLISP modern modes M ./Makefile +3 M ./TODO -3 M ./src/foreign-vars.lisp -2 +4 M ./src/functions.lisp -1 +1 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-051231.tar.gz

1 0

[cffi-devel] New patches: 30-Dec-2005
by loliveira＠common-lisp.net 31 Dec '05

31 Dec '05

Fri Dec 30 22:52:18 CET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Fix more typos in cffi-manual. M ./doc/cffi-manual.texinfo -10 +10 Fri Dec 30 13:18:46 CET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Fix foreign-free example in the documentation. M ./doc/cffi-manual.texinfo -1 +1 Fri Dec 30 09:18:18 CET 2005 James Bielman <jamesjb(a)jamesjb.com> * add scripts/ directory and release script A ./scripts/ A ./scripts/release.sh Fri Dec 30 08:43:03 CET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Fix the struct.names test and update some CLISP comments. M ./src/cffi-clisp.lisp -6 +3 M ./tests/struct.lisp -1 +2 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-051230.tar.gz

2 1

[cffi-devel] cffi-manual: foreign-free example
by Yaroslav Kavenchuk 30 Dec '05

30 Dec '05

clisp from CVS head, cffi-051229.tar.gz CFFI[11]> (foreign-alloc 32) *** - Unknown CFFI type: 32. Thanks! -- WBR, Yaroslav Kavenchuk.

2 5

[cffi-devel] CFFI/CLISP - 2 out of 101 total tests failed
by Yaroslav Kavenchuk 30 Dec '05

30 Dec '05

clisp from CVS head, cffi-051229.tar.gz [4]> (asdf:operate 'asdf:test-op :cffi-tests) Doing 101 pending tests of 101 tests total. ... Test CFFI-TESTS::FUNCALL.VARARGS.DOUBLE failed Form: (CFFI:WITH-FOREIGN-POINTER-AS-STRING (CFFI-TESTS::S 100) (SETF (CFFI:MEM-REF CFFI-TESTS::S :CHAR) 0) (CFFI:FOREIGN-FUNCALL "sprintf" :POINTER CFFI-TESTS::S :STRING "%.2f" :DOUBLE (COERCE PI 'DOUBLE-FLOAT) :VOID)) Expected value: "3.14" Actual value: #<error during printing> ... Test CFFI-TESTS::STRUCT.NAMES failed Form: (CFFI:FOREIGN-SLOT-NAMES 'CFFI-TESTS::XPTO) Expected value: (CFFI-TESTS::TV-SECS CFFI-TESTS::TV-USECS) Actual value: (CFFI-TESTS::TV-USECS CFFI-TESTS::TV-SECS). ... 2 out of 101 total tests failed: CFFI-TESTS::FUNCALL.VARARGS.DOUBLE, CFFI-TESTS::STRUCT.NAMES. Thanks! -- WBR, Yaroslav Kavenchuk.

2 1

[cffi-devel] CFFI is now ASDF-INSTALLable
by James Bielman 30 Dec '05

30 Dec '05

Hi all, I uploaded a signed tarball of today's CFFI Darcs snapshot and added the appropriate magic to CLiki to make it ASDF-INSTALLable. I will try to keep this in sync with the Darcs tree until we start making proper releases. James

1 0

[cffi-devel] CFFI/CLISP issues with saved images
by Luís Oliveira 30 Dec '05

30 Dec '05

Hello, I was just testing CFFI/CLISP by loading the testsuite, dumping an image, loading it and running the tests. CLISP crashes. There are two problems: - The foreign library (in this case libtest.so) is not being reloaded. Joerg, any suggestions regarding what we should be doing in %foreign-funcall (or %load-foreign-library?) in order to fix this? Manually reloading the library after loading the image solves the crash. I recall CLISP's ffi:def-call-out taking care of this but - The callbacks become NULL pointers, thus all callback.* tests fail. Any suggestions for fixing that? Randomly placing load-time-value forms in %defcallback didn't seem to work. :-) Happy new year! -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

1 0