cffi-devel

cffi-devel@common-lisp.net

1113 discussions

[cffi-devel] CFFI foreign library error pathname patch
by Stelian Ionescu 18 Dec '11

18 Dec '11

Xach requested better error reporting from load-foreign-library, so please review this patch -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

4 8

[cffi-devel] Dynamically call a certain function in a lib
by Frank Goenninger 05 Dec '11

05 Dec '11

Hi, I have: (defun load-and-open-module (pathname) (let ((lib (cffi:load-foreign-library pathname))) (if lib (progn (format t "~%LOAD-AND-OPEN-MODULE: ~s LOADED." lib) (let ((handle (cffi:foreign-funcall `("open" :library ,lib) :pointer))) ;; <<--- Here's the challenge ... (if (not (eql handle (cffi:null-pointer))) (let ((module (make-instance 'pib-module :lib (c-in lib) :handle (c-in handle)))) (format t "~%LOAD-AND-OPEN-MODULE: module = ~s." module) module) nil) nil))))) The marked line should load the "open" function in the just loaded foreign lib. As I intend to load multiple so-called modules where each module has an "open" function I /think/ I need to say which open() function to call (the loaded libs are C DLLs, mostly). How do I name a certain foreign lib in the call to foreign-funcall when the library given is not evaluated ? Thanks for any hints! Cheers Frank

2 1

[cffi-devel] defcallback with &rest
by Frank Goenninger 02 Dec '11

02 Dec '11

Hi all! Question: I have a Lisp function as follows: (defun frgo (fmt &rest args) (format t fmt args)) Now I want to define a C call back for that function: (defcallback frgoc :void ((fmt :string) (args ??????? How do I define the callback such that I can have a C function with varargs being defined? Thx! Cheers Frank

2 2

[cffi-devel] cffi-grovel on windows 7
by Karl Heinrichmeyer 30 Nov '11

30 Nov '11

Hello, When I tried to load the osicat library via quicklisp yesterday i got an error because the cffi-groveler couldn't find the c compiler and because the path in the include parameter was ill formed (the drive letter was missing). I fixed the first one by setting the CC environment variable and worked around the second one by changing some few lines in the sources of the groveler. After that I got errors due to some libraries. I would like to check if this is an silicate problem or if the groveler is the cause. So here is my question: What "stable" applications that use the groveler exist? Applications that are known to run under Windows are preferred. Thanks for your help, best regards, Karl

3 3

[cffi-devel] New CFFI with cffi-fsbv
by Liam Healy 27 Nov '11

27 Nov '11

I think the new CFFI with cffi-fsbv is ready to be tested, even by those not needing to call or return foreign structures by value. You can checkout the cffi-fsbv branch after cloning. There are two things to keep in mind: one is to call structures by reference either with :pointer or (:pointer (:struct foo)), as using the structure name alone will result in a style warning. The second is that expand-to-foreign-dyn now has a keyword argument, so methods should have &key. I asked Zach to test compling/loading all of the current quicklisp dist with this branch. There were a few failures: 1) inotify failed because iolib is out of sync with this branch of CFFI (changes independent of fsbv). 2) lispmagick failed because this branch of CFFI didn't have an ASDF version number, so I gave it version number 1.0.0 :-). There remains a failure with TRANSLATE-INTO-FOREIGN-MEMORY on #<CFFI::FOREIGN-STRING-TYPE :UTF-8> which I don't understand. 3) fnv and blapack loads fine for me (apart from a path issue<https://github.com/blindglobe/cl-blapack/issues/1>); Zach gets warning/errors on defining keyword types :complex-double and :complex-float. 4) devil needs to have &key in the arglist for expand-to-foreign-dyn as explained. 5) blackthorn fails to load for Zach but I tried a few systems (blackthorn, blackthorn-stress-test, thopter) and they all load fine. His errors are all like this: Derived type of #:G331 is (VALUES SB-SYS:SYSTEM-AREA-POINTER &OPTIONAL), conflicting with its asserted type (UNSIGNED-BYTE 32). I have not pulled master into this branch, so it's a few commits behind. Post here on how things look for you, good or bad. Liam

1 0

[cffi-devel] Interface problem in LispWorks but not in SBCL
by Sascha Van Cauwelaert 26 Nov '11

26 Nov '11

Hello everybody, I am using SWIG to generate CFFI code to be used into LispWorks 6. The interface is between C++ and Common Lisp. Then, I try to call that function from LispWorks : std::string test() { freopen ("/tmp/mystdout.txt","w",stdout); freopen ("/tmp/mystderr.txt","w",stderr); std::cout << "Redirected stdout." << std::endl; std::cerr << "Redirected stderr." << std::endl; GRelation testgr(3); std::cout << "test ! " << std::endl; std::cerr << "test cerr! " << std::endl; std::cout << testgr.arity() << std::endl; std::cerr << testgr.arity() << std::endl; std::cout << "test after! " << std::endl; std::cerr << "test cerr after! " << std::endl; std::stringstream os; os << testgr << std::endl ; return os.str(); } As you can see, I just create one object and print lots of stuff, including an object attribute. Everything I print before trying to print the attribute prints ok in the redirected outputs. The attribute is not printed and nothing else afterwards. I also get the following error when I add testgr to the stringstream os : lispworks-personal-6-0-1-macos-universal(52881,0xb0314000) malloc: *** error for object 0x17be20f8: pointer being freed was not allocated This is what happen in LispWorks. If I compile directly in C++, no problem. If I use SBCL (other Common Lisp implementation) instead of LispWorks, everything works correctly ! The problem is that I have to use LispWorks ... Does anybody has had a similar problem ? I guess I am not the only one who tried to call some C++ from LispWorks. Any clue is very welcome. I think maybe the problem can be linked to the garbage collection from LispWorks but I don't know much about this. I thank you in advance for your help, I am really stuck here. Regards, Sascha

3 6

[cffi-devel] Refactoring SWIG-generated ACL stubs into CFFI/UFFI
by Victor 26 Nov '11

26 Nov '11

Hi! The CFFI generator in SWIG produces incomplete stubs compared to the Allegro CL one. The case in question are the stubs for Mapserver's MapScript wrapper: http://mapserver.org/mapscript/index.html The Lisp wrapper code generated for ACL is pretty much an ordinary Common Lisp. Except for a bunch of ACL-specific functions (from EXCL and FF packages). The functions from EXCL package are easy to replace with freely-available replacements. But the functions from FF package are a little bit different than the functions from CFFI. They look like more similar to the UFFI but still are not the same. Did anybody face a similar problem already? What is the best way to refactor the ACL wrappers to be portable across implementations? Does anybody have improved CFFI generator for SWIG? Thanks, Victor -- реклама ----------------------------------------------------------- Никогда не покупали в интернете? Лучшее место для покупок онлайн - http://aukro.ua

2 1

[cffi-devel] Accessing integer arrays Lisp->C
by Stephan Frank 24 Nov '11

24 Nov '11

Hi everybody, I have a problem that I was not able to resolve with the manual. I have the following C function (which is a trimmed down version of a C++ wrapper): extern "C" { void tryit(const int *ints, unsigned count) { for(unsigned i=0; i<count; i++) { cerr << "index " << i << ": " << ints[i] << "\n"; } } } /* extern "C" */ Now I want to call it with an array that is allocated and initialized on the Lisp side: (defcfun ("tryit" try-it) :void (vars :pointer) (count :unsigned-int)) (defun test () (let* ((l (list 1 2 3)) (len (length l)) (i 0)) (with-foreign-object (idx :int len) (map nil (lambda (x) (setf (mem-ref idx :int i) x) (incf i)) l) (try-it idx len)))) I'm quite convinced that this should now print 1,2,3 to cerr for the corresponding indices. However, I get the following: index 0: 197121 index 1: 0 index 2: 6581024 Any insight on what I'm doing wrong is greatly appreciated. Best regards, Stephan

3 2

[cffi-devel] cffi-grovel *cpu-word-size-flags*: wrong on Windows/amd64
by Anton Kovalenko 10 Nov '11

10 Nov '11

Hello CFFI developers, There is a following fragment in cffi/grovel/grovel.lisp: (defparameter *cpu-word-size-flags* (ecase (cffi:foreign-type-size :long) (4 (list "-m32")) (8 (list "-m64")))) It would be better to use :intptr instead of :long, because on 64-bit MS Windows, long is not long enough. AFAIK, there are no official "multilib" mingw64 builds, so -m32/-m64 are unlikely to be too useful nowadays. However, passing wrong word size to gcc prevents it from building correct binaries anyway: if that word size is unsupported, gcc will refuse to compile anything. I ran into this problem with my Windows/amd64 port of SBCL. -- Regards, Anton Kovalenko <http://github.com/akovalenko/sbcl-win32-threads> +7(916)345-34-02 | Elektrostal' MO, Russia

2 2

[cffi-devel] CFFI-FSBV: libffi-type-pointer for foreign structures created when needed
by Liam Healy 16 Sep '11

16 Sep '11

For those interested, some details and progress report on the merging of FSBV into CFFI. On Saturday, I was about to commit the latest changes to the fsbv branch of CFFI, and I decided at the last minute to swap the load order of cstruct and cif in cffi-fsbv.asd. Previously, I had cif.lisp loading first, and then cstruct.lisp, but it made more sense to me to put it after, because it has to do with functions, and everything else, including cstruct.lisp, did not. Much to my surprise, I got an error, and I quickly realized why: cif defines a structure that libffi needs, and when it is defined prior to cstruct, it made an ordinary foreign structure, without the *cstruct-hooks* I had made that define a foreign structure with the libffi-type pointers. When it's defined after, it got an error because some of the slots have types, like "unsigned" that are undefined in the FSBV sense (i.e., there's no libffi-type for it). The immediate bug fix would be to just define the types. Eventually I'll do that. But the real issue is that in that design, every type has to have libffi-type information, even if there's no intent to use that structure in a call by value. In the standalone FSBV, that wasn't an issue, because there were two macros, cffi:defcstruct and fsbv:defcstruct, and presumably no one used the latter unless they were going to pass or receive the foreign structure by value. Now all structures once defined would have the libffi plumbing defined, whether they needed it or not. So I changed my approach, and in the process simplified the code a lot. Instead of making the necessary libffi-type in the defcstruct expansion, it will be made on demand only, when a foreign struct is used by, e.g. defcfun. This happens recursively, so if one structure uses another, both will be made. Once they structure is made, it is attached to the plist of the symbol for the type, so it need not be recomputed. I'm now dealing with built-in types and coming up against a problem I've struggled with before (in GSLL and Antik): how to map C types (:short, :int, etc.) into established byte sizes (:uint8, :uint16). The problem is that libffi defines the types by their size, and it's up to the user to figure out how to map the common C types to those sizes; this is a topic in C that has always confused me. I notice that CFFI has a mapping in the code at the end of src/types.lisp, but it's not easily accessible to other code, so I think if I break that out as some kind of table it will be useful to generate the appropriate pointers for libffi. Unless someone has a better way. Liam

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel