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

[cffi-devel] New patches: 27-Mar-2006
by loliveira＠common-lisp.net 28 Mar '06

28 Mar '06

Mon Mar 27 19:49:44 EST 2006 Stephen Compall <scompall(a)nocandysw.com> * manual-don't use PRINT-OBJECT for CONDITIONs M ./doc/cffi-manual.texinfo -8 +5 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060327.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] cffi macro suggestion
by hbabcockos1＠mac.com 26 Mar '06

26 Mar '06

Hello, I've been working on an interface for the graphics package plplot (http://plplot.sourceforge.net/) Its API has lots of functions that expect arrays, matrixes and associated variables that specify the size of the array/matrix. To facilitate wrapping these functions I wrote a macro that I thought might (after some modification/cleaning) be useful for others. The macro can be found at: http:// paste.lisp.org/display/18274. It was written to expand a function declaration like: (pl-defcfun ("c_plmesh" plmesh) :void (x *plflt nx) (y *plflt ny) (z **plflt (nx ny)) (nx plint) (ny plint) (opt plint)) into: (progn statements removed) (DEFCFUN ("c_plmesh" C-PLMESH) :VOID (X *PLFLT) (Y *PLFLT) (Z **PLFLT) (NX PLINT) (NY PLINT) (OPT PLINT)) (EXPORT 'C-PLMESH (PACKAGE-NAME *PACKAGE*))) (DEFUN PLMESH (X Y Z OPT) (LET ((C-X (MAKE-PTR X :DOUBLE #'(LAMBDA (X) (COERCE X 'DOUBLE- FLOAT)))) (C-Y (MAKE-PTR Y :DOUBLE #'(LAMBDA (X) (COERCE X 'DOUBLE- FLOAT)))) (NX (ARRAY-DIMENSION Z 0)) (NY (ARRAY-DIMENSION Z 1)) (C-Z (MAKE-MATRIX Z))) (UNWIND-PROTECT (C-PLMESH C-X C-Y C-Z (FUNCALL #'(LAMBDA (X) (ROUND X)) NX) (FUNCALL #'(LAMBDA (X) (ROUND X)) NY) (FUNCALL #'(LAMBDA (X) (ROUND X)) OPT)) (PROGN (FOREIGN-FREE C-X) (FOREIGN-FREE C-Y) (FREE-MATRIX C-Z (LIST NX NY)))))) (EXPORT 'PLMESH (PACKAGE-NAME *PACKAGE*)))) Where make-ptr, make-matrix and free-matrix are functions that make 1D arrays, make 2D arrays & free 2D arrays respectively. best, -Hazen

2 2

[cffi-devel] cffi not working on x86-64 with cmucl (working with sbcl)
by Dawgmatix 24 Mar '06

24 Mar '06

Lisp: CMUCL version 19c OS: ubuntu dapper 64 bit CFFI: from darcs as of today I tried loading cl-opengl as well as load libGL.so manually. It does not work. On the same system with sbcl 0.9.10 both loading libraries and cl-opengl DO work. I am unable to dig further because the error only tells me that the library could not be loaded. Regards, Deep

2 1

[cffi-devel] Can't expand foreign-funcall
by Liam M. Healy 22 Mar '06

22 Mar '06

A darcs pull today of CFFI leaves foreign-funcall unexpandable in SBCL. ; caught ERROR: ; (during macroexpansion of (FOREIGN-FUNCALL ... ...)) ; A function with declared result type NIL returned: ; CFFI::TRANSLATE-OBJECTS Apparently this error message results from a function redefinition http://www.lispworks.com/documentation/HyperSpec/Body/03_bbc.htm "A call within a file to a named function that is defined in the same file refers to that function, unless that function has been declared notinline. The consequences are unspecified if functions are redefined individually at run time or multiply defined in the same file." See discussion http://meme.b9.com/cview.html?utime=3351855600&channel=lisp&start=335185560… Liam

2 2

[cffi-devel] trapping C exit
by hbabcockos1＠mac.com 21 Mar '06

21 Mar '06

Hi, Is there a way to trap a call to exit made in a C library and prevent it from stopping the currently running Lisp process? I'm struggling with an annoying C library function that was written to call exit() if it didn't get the arguments that it expected (or sometimes to call exit() even if it did get the expected arguments). I.e, how would I wrap this CFFI function so that calling it won't stop my lisp process? (defcfun ("exit" exit) :void (code :int)) Thanks, -Hazen

2 1

Fwd: [cffi-devel] Array call crashes SBCL on one computer
by Liam M. Healy 19 Mar '06

19 Mar '06

Stephen> On Sun, 2006-03-19 at 12:53 -0500, Liam M. Healy wrote: >> - The desktop is ..., Darcs pull 2006-03-07 23:11, SBCL 0.9.8.42 >> - The laptop is ..., Darcs pull 2006-03-17 23:59, SBCL 0.9.9 Stephen> This may or may not be an issue. >> (with-foreign-objects ((retn :double)) >> (foreign-funcall "gsl_sf_bessel_Jn_array" >> :int 0 >> :int 2 >> :double 0.25d0 >> :pointer retn >> :int) >> (mem-aref retn :double 0)) Stephen> I know nothing about GSL besides what I just read about the function you Stephen> call above, but don't you need to allocate space for 3 doubles, not just Stephen> one, for the retn (result_array) argument? Yes, that's it. For some reason, one is OK with the lack of allocation, the other is not. Thanks. Liam

2 1

[cffi-devel] Array call crashes SBCL on one computer
by Liam M. Healy 19 Mar '06

19 Mar '06

I have two computers, both Linux/x386. - The desktop is Debian unstable, Darcs pull 2006-03-07 23:11, SBCL 0.9.8.42 - The laptop is Ubuntu 05.10, Darcs pull 2006-03-17 23:59, SBCL 0.9.9 On both I have GSL (libgsl0) installed, which includes two libraries /usr/lib/libgslcblas.so.0 /usr/lib/libgsl.so.0 which I have made links to the corresponding .so names. On each I do: (require :asdf) (require :cffi) (in-package :cffi) (cffi:load-foreign-library "/usr/lib/libgslcblas.so") (cffi:load-foreign-library "/usr/lib/libgsl.so") (with-foreign-objects ((retn :double)) (foreign-funcall "gsl_sf_bessel_Jn_array" :int 0 :int 2 :double 0.25d0 :pointer retn :int) (mem-aref retn :double 0)) On the desktop, everything works normally and I get 0.9844359292958527d0 On the laptop, I get an SBCL crash with the following message: Argh! corrupted error depth, halting fatal error encountered in SBCL pid 29184(tid 3085391552): %PRIMITIVE HALT called; the party is over. The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. Some other results on the laptop: - All functions I've tried that return a pointer to an array of doubles have this problem. - Sometimes the problem behavior varies. For example, If the third argument is 0.5d0, SBCL simply locks up instead of crashing. Sometimes I get an infinite output of error messages that repeat the line "mprotect: Cannot allocate memory" over and over. Any debugging advice? Thanks. Liam

2 1

[cffi-devel] New patches: 16-Mar-2006
by loliveira＠common-lisp.net 17 Mar '06

17 Mar '06

Thu Mar 16 06:55:05 EST 2006 Stephen Compall <scompall(a)nocandysw.com> * small manual fixes - Add convert-to-foreign, convert-from-foreign, and free-converted-object to the master menu. - (load-foreign-library): Add note about specifying directories in paths. - (defcfun): Typo in syntax. M ./TODO -2 M ./doc/cffi-manual.texinfo -6 +14 Thu Mar 16 06:45:54 EST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Lispworks: use regression-test instead of rt. M ./tests/callbacks.lisp -2 +2 Thu Mar 16 06:40:28 EST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * SCL update + new cffi-sys primitive - New cffi-sys primitive: canonicalize-symbol-name-case. Use this instead of read-from-string. Also new tests for this. - cffi-scl.lisp: correct the evaluation order of %MEM-REF and %MEM-SET. Have 'foreign-symbol-pointer return 'nil if the symbol is not found. - uffi-compat.lisp: better support for SCL. - defcfun.lisp (defcfun.undefined): package at time of eval may differ from the compile time package. Patch courtesy of Douglas Crosher. M ./src/cffi-allegro.lisp +9 M ./src/cffi-clisp.lisp +7 M ./src/cffi-cmucl.lisp +7 M ./src/cffi-corman.lisp +7 M ./src/cffi-ecl.lisp +7 M ./src/cffi-gcl.lisp +7 M ./src/cffi-lispworks.lisp +7 M ./src/cffi-openmcl.lisp +7 M ./src/cffi-sbcl.lisp +7 M ./src/cffi-scl.lisp -14 +24 M ./src/foreign-vars.lisp -5 +3 M ./src/functions.lisp -1 +1 M ./tests/foreign-globals.lisp +84 M ./tests/libtest.c +19 M ./uffi-compat/uffi-compat.lisp -12 +16 Thu Mar 16 06:28:18 EST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * when (and ecl (not dffi)) cffi:load-foreign-library doesn't work - mention this in the manual. - make l-f-l signal an error on non-dffi ecl platforms. M ./doc/cffi-manual.texinfo +11 M ./src/cffi-ecl.lisp -1 +3 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060316.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] Re: unnamed callback (closures?)
by Jan Rychter 16 Mar '06

16 Mar '06

[resending directly as it seems messages posted through Gmane don't make it to the list :-/ ] >>>>> "Luís" == Luís Oliveira <luismbo(a)gmail.com>: Luís> "Hoehle, Joerg-Cyril" <Joerg-Cyril.Hoehle(a)t-systems.com> writes: >> 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? Luís> To my knowledge, yes. AFAICT, only SBCL/x86 and CLISP support Luís> that. Luís> Regarding the behaviour of CFFI:DEFCALLBACK as a non-toplevel Luís> form, not only will it set it globally, the callback itself won't Luís> be generated at runtime on most Lisp, IIRC. I've just ran into the same problem. I really really need closures as callbacks. I've tried the naive approach: (defmacro object-event-callback-add (obj type function) `(foreign-funcall "evas_object_event_callback_add" :pointer ,obj callback-type ,(foreign-enum-value 'callback-type type) :pointer (get-callback (defcallback ,(gensym "CB") :void ((data :pointer) (cb-e evas) (cb-obj object) (cb-event :pointer)) (funcall ,function cb-e cb-obj cb-event))) :pointer (null-pointer))) ... but that's a half-baked solution with too many limitations and only works in a simple example that you run once. What are the problems with unnamed callbacks? My guess was that they will never get garbage-collected, but how about storing all of these in a table somewhere and explicitly freeing them after they are no longer needed? In my case I do have a way of finding out when a callback is no longer needed, and I suspect this is the case for many other applications. I mostly develop on SBCL/x86 and ECL, so even if a solution worked on these platforms only, I'd be really happy. --J.

5 12

[cffi-devel] [patch] small manual updates
by Stephen Compall 16 Mar '06

16 Mar '06

Been trying to work on code for the past week or so, so not many manual changes since the last one. Anyway, here are a few fixes: Wed Mar 15 13:18:49 CST 2006 Stephen Compall <scompall(a)nocandysw.com> * small manual fixes - Add convert-to-foreign, convert-from-foreign, and free-converted-object to the master menu. - (load-foreign-library): Add note about specifying directories in paths. - (defcfun): Typo in syntax. -- Stephen Compall http://scompall.nocandysw.com/blog

2 2