cffi-devel March 2006

cffi-devel@common-lisp.net

12 participants
19 discussions

[cffi-devel] %expand-type-to-foreign-dyn vs *runtime-translator-form*
by Stephen Compall 31 Mar '06

31 Mar '06

I was looking at the new type translator expansion interface and noticed that one would experience different behavior depending on method definitions. I'll use expand-to-foreign-dyn as an example: If a translation method is available [for some defn thereof], as found by compute-applicable-methods, but that method answered *runtime-translator-form*, the final result of the expander would be something like `(multiple-value-bind (,var ,param) (translate-type-to-foreign ,value ,type) (unwind-protect (progn ,@body) (free-type-translated-object ,var ,type ,param))) Otherwise, both implementations of expand-type-to-foreign-dyn would short-circuit the generic function call and return `(let ((,var ,(expand-type-to-foreign value type))) ,@body) Though only if by similar heuristic they found that a one-way expander was available. I've rearranged things here to combine the cases, eliminate the *runtime-translator-form* exportation, and make the code simpler. Currently, both cases are collapsed into the former expansion. However, this breaks some misc-types.expand tests, as it breaks this guarantee listed in that file: Ensure that macroexpansion-time translators are called where this is guaranteed (defcfun, defcvar, foreign-funcall and defcallback) Now, expand-to-foreign is undocumented (:), so I am not sure what its semantics are supposed to be anyway. (In particular, I don't see whether the expand-type-* specializations for foreign-typedef are following the actual-type chain.) If it is precisely like a compiler macro, this can easily be fixed by changing translate-type-to-foreign to expand-type-to-foreign in the current expansion, and things will work nicely. However, I must be able to call free-type-translated-object on the results of the forward-expanded form for this to work. Can I rely on this guarantee, so that I can in return reoffer the aforementioned guarantee? -- Stephen Compall http://scompall.nocandysw.com/blog

2 13

[cffi-devel] sbcl on mingw: Test CFFI-TESTS::DEFCFUN.UNDEFINED failed
by Yaroslav Kavenchuk 30 Mar '06

30 Mar '06

SBCL 0.9.9.37 on mingw, cffi-060225.tar.gz * (asdf:operate 'asdf:load-op :cffi) ... Test CFFI-TESTS::DEFCFUN.UNDEFINED failed Form: (PROGN (EVAL '(CFFI:DEFCFUN "undefined_foreign_function" :VOID)) (COMPILE 'CFFI-TESTS::UNDEFINED-FOREIGN-FUNCTION) T) Expected value: T Actual value: #<UNDEFINED-ALIEN-ERROR undefined_foreign_function {B45E8E9}>. Thanks. -- WBR, Yaroslav Kavenchuk.

3 5

[cffi-devel] A slight documentation disambiguation?
by Samium Gromoff 29 Mar '06

29 Mar '06

Apropos the built-in types section, would it make sense to replace a slightly ambiguous sentence mixing three things: "On most systems, the :float type represents a C float and a Lisp single-float. :double represents a C double and a Lisp double-float." with two separate sentences: "On all systems the :float type represents a C float, :double represents a C double." and "On most systems, the :float type a Lisp single-float, :double represents a Lisp double-float." ? respectfully, Samium Gromoff

2 1

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel March 2006