August 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] groveller doesn't grovel for functions?
by Andy Chambers 10 Sep '09

10 Sep '09

Hi, Am I correct in thinking that the groveller doesn't grovel for functions and automatically create the correct defcfun forms for a given library? -- ---- Andy Chambers Formedix Ltd

4 5

[cffi-devel] is cffi darcs repo broken?
by Sam Steingold 31 Aug '09

31 Aug '09

$ darcs get http://common-lisp.net/project/cffi/darcs/cffi/ cffi Invalid repository: http://common-lisp.net/project/cffi/darcs/cffi darcs failed: failed to fetch: http://common-lisp.net/project/cffi/darcs/cffi/_darcs/inventory ExitFailure 1 darcs 1.0.9 (release) -- Sam Steingold <http://sds.podval.org>

3 2

[cffi-devel] utf-16 encoded strings in ClozureCL on a Win32 Host
by John Miller 31 Aug '09

31 Aug '09

A little background: I am trying to get RDNZL working on Clozure CL 1.4 running on my Win32 box using CFFI. It gets an "exception occurred while executing foreign code" that causes the listener to drop into the kernel debugger. All I can tell is that the error occurs in %invoke-static-member and I believe the error is because the function expects a utf-16 (wchar) string, but for some reason the encoding is not working as expected in CFFI. I went and did a little experimentation and found the following: CFFI> *default-foreign-encoding* :UTF-8 CFFI> (foreign-funcall "_wcsdup" (:string :encoding :utf-16) "foo" :string) "f" ;; That looks like the manual CFFI> (let ((*default-foreign-encoding* :utf-16)) (foreign-funcall "_wcsdup" (:string :encoding :utf-16) "foo" :string)) "" ;; Oops, foo in Sumerian cuneiform, maybe? Note that strdup won't work with utf-16 on windows. You use _wcsdup instead, apparently. CL-USER> (with-encoded-cstrs :utf-16 ((x "foo")) (#__wcsdup x)) #<A Foreign Pointer #x117C730> CL-USER> (ccl::%get-native-utf-16-cstring *) "foo" ;; Almost got it! CL-USER> (ccl::with-native-utf-16-cstr (x "foo") (#__wcsdup x)) #<A Foreign Pointer #x1171590> CL-USER> (ccl::%get-native-utf-16-cstring *) "foo" ;; Bulls-eye! Any idea on why this is happening? Many thanks, John Miller

2 1

[cffi-devel] New patches: 23-Aug-2009
by Luis Oliveira 23 Aug '09

23 Aug '09

Sun Aug 23 08:11:08 EDT 2009 Stelian Ionescu <sionescu(a)cddr.org> * Deprecate groveler clause FLAG in favour of CC-FLAGS. M ./doc/cffi-manual.texinfo -2 +2 M ./grovel/grovel.lisp +5 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-090823.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] Grovel default search path for include files
by Liam Healy 22 Aug '09

22 Aug '09

System-installed header files sometimes are in different places depending on the OS and method of installation. In particular, the file ffi.h that FSBV (http://repo.or.cz/w/fsbv.git) uses from libffi seems to be in different places on OS X depending on how it was installed (Apple native, Mac ports, etc.). Not being a user of OS X, it is difficult for me to know all the possible locations where this file might end up. Is it possible to specify that the groveler should "search system-standard locations" for the header files specified in include forms, analogous to load-foreign-library knowing where to look for system libraries, and have it find the file based on its knowledge of the places it might be for the current OS? Thank you. Liam

2 2

[cffi-devel] uffi.asd vs uffi-compat.asd
by Jeff Cunningham 22 Aug '09

22 Aug '09

I just tried to install elephant and ran into an annoying problem which could only be resolved by renaming the cffi/uffi-compat/uffi.asd to uffi-compat.asd. The problem seems to be one of identity theft, since elephant uses uffi, and it was picking up the cffi compatibility code (which does not appear to be sufficiently compatible for elephant), instead of what it expected. I also know that there has been prior discussion about this - I didn't read all of it, but found some on this list by Googling - I wasn't around the list at the time. Is there a way that this can be resolved? It seems that both libraries should be able to coexist on a system, as there are applications which expect them to be there. It also seems that UFFI has a prior claim to its own name for a system file. As it stands, everytime I do a clbuild upgrade I am going to have to make sure I fix the link. Regards, --Jeff

7 15

[cffi-devel] New patches: 21-Aug-2009
by Luis Oliveira 21 Aug '09

21 Aug '09

Fri Aug 21 17:00:52 EDT 2009 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-allegro: define long long types on 64-bit platforms Patch courtesy of John Fremlin. M ./src/cffi-allegro.lisp -1 +3 Fri Aug 21 16:54:47 EDT 2009 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-tests: fix pointer-to-integer casts in libtest.c M ./tests/libtest.c -20 +20 Fri Aug 21 16:51:44 EDT 2009 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-tests: don't use stdcall #ifndef WIN32 M ./tests/libtest.c -1 +8 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-090821.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] uffi.asd vs uffi-compat.asd
by Cunningham, Jeffrey K. 21 Aug '09

21 Aug '09

On Fri, Aug 21, 2009 at 4:01 PM, Jeff Cunningham > I would gladly rename it. It would work just as well for its original > purpose, since as long as you create a uffi.asd symlink, > (asdf:find-system :uffi) will pick it up. However, I suspect there > might be other code in clbuild that does in fact use cffi-uffi-compat > and I wouldn't want to break it. Can anyone confirm if there is such a > dependency? Apparently, it used to be named uffi-compat.asd. Why couldn't it be named that? That would fix everything. And so far as I know, the breadth vs depth argument doesn't hold, because in most installations you want _all_ the your asd files to end up symlinked in your systems directory (and I know there are other ways to do it, but that's the way most of us do it - why make life hard on us?). No matter what technique you use, it will be first one wins the prize which isn't necessarily going to be what you want (or last one if you use -f with the symlink command). I think that's why the custom of naming them "uffi-cffi-compat.asd" evolved in the first place, wasn't it? So it was completely clear in a linear collection of asd files? --Jeff

1 0