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

[cffi-devel] Error with translate-to-foreign
by Greg Pfeil 25 Feb '06

25 Feb '06

This is using the latest darcs cffi on SBCL 0.9.5 ... I have a list of lists of strings and have created the translations below (the arrays end up null-terminated): (defctype string-list :pointer) (defctype string-lists :pointer) (defmethod translate-to-foreign (value (type (eql 'string-list))) (let ((foreign (foreign-alloc :string :initial-contents value :count (1+ (length value))))) (setf (mem-aref foreign :pointer (length value)) (null-pointer)) foreign)) (defmethod translate-to-foreign (value (type (eql 'string-lists))) (let ((foreign (foreign-alloc 'string-list :initial-contents value :count (1+ (length value))))) (setf (mem-aref foreign :pointer (length value)) (null-pointer)) foreign)) I get an error on the call to t-t-f for string-list, because the value is a pointer and not a sequence. If I change the foreign-alloc type to :pointer instead of string-list, it compalains that ("foo" "bar") is not a pointer (which makes sense). So, using 'string-list seems to try to double-convert (which I don't expect), :pointer seems to not convert at all (which I do expect). So, any idea what I'm doing wrong? Here's the error: 0: (LENGTH #.(SB-SYS:INT-SAP #X082CCA70)) 1: ((SB-PCL::FAST-METHOD CFFI:TRANSLATE-TO-FOREIGN (T (EQL (QUOTE PRODUCT-DISC OVERY::STRING-LIST)))) #<unavailable argument> #<unavailable argument> #.(SB-SYS :INT-SAP #X082CCA70) #<unavailable argument>) 2: ((SB-PCL::FAST-METHOD CFFI::TRANSLATE-TYPE-TO-FOREIGN (T CFFI::FOREIGN-TYPE DEF)) #<unavailable argument> #<unavailable argument> #.(SB-SYS:INT-SAP #X082CCA 70) #<CFFI::FOREIGN-TYPEDEF PRODUCT-DISCOVERY::STRING-LIST>) 3: (CFFI::MEM-SET #.(SB-SYS:INT-SAP #X082CCA70) #.(SB-SYS:INT-SAP #X082CD488) PRODUCT-DISCOVERY::STRING-LIST 0) 4: (CFFI:FOREIGN-ALLOC PRODUCT-DISCOVERY::STRING-LIST :INITIAL-ELEMENT NIL :IN ITIAL-CONTENTS (("ASIN" "B0002E3MRW")) :COUNT 2) 5: ((SB-PCL::FAST-METHOD CFFI:TRANSLATE-TO-FOREIGN (T (EQL (QUOTE PRODUCT-DISC OVERY::STRING-LISTS)))) #<unavailable argument> #<unavailable argument> (("ASIN" "B0002E3MRW")) #<unavailable argument>) 6: ((SB-PCL::FAST-METHOD CFFI::TRANSLATE-TYPE-TO-FOREIGN (T CFFI::FOREIGN-TYPE DEF)) #<unavailable argument> #<unavailable argument> (("ASIN" "B0002E3MRW")) #< CFFI::FOREIGN-TYPEDEF PRODUCT-DISCOVERY::STRING-LISTS>)

2 2

[cffi-devel] stdcall example (was: CFFI 0.9.0 Release)
by Hoehle, Joerg-Cyril 23 Feb '06

23 Feb '06

Jack, >The lack of >stdcall has caused both CLISP and LispWorks to crash for >me when I use the Win32 EnumChildWindows API function, >which takes a callback that must be declared as stdcall [1] >I can provide a self-contained testcase that demonstrates >the problem, if that would be helpful. I'd like to add this to the CLISP testsuite. I don't know the MS-Windows APIs and never looked for a testcase. Indeed, it needs to involve callbacks to show the difference AFAIK. Regards, Jörg Höhle.

1 0

[cffi-devel] 1 out of 143 total tests failed: CFFI-TESTS::FUNCALL.LONG-LONG.
by Yaroslav Kavenchuk 23 Feb '06

23 Feb '06

SBCL 0.9.9.37 on wingw, cffi-060219.tar.gz * (asdf:operate 'asdf:load-op :cffi-tests) ... ; C:\CL\lib\cffi\tests\defcfun.fasl written ; compilation finished in 0:00:08 debugger invoked on a SB-ALIEN:UNDEFINED-ALIEN-ERROR: Undefined alien: "llabs" ... * (asdf:operate 'asdf:test-op :cffi-tests) ... CFFI-TESTS::FUNCALL.LONG Test CFFI-TESTS::FUNCALL.LONG-LONG failed Form: (CFFI:FOREIGN-FUNCALL "llabs" :LONG-LONG -9223372036854775807 :LONG-LONG) Expected value: 9223372036854775807 Actual value: #<UNDEFINED-ALIEN-ERROR llabs {B20AC11}>. ... ; ; compilation unit finished ; caught 1 fatal ERROR condition Thanks! -- WBR, Yaroslav Kavenchuk.

2 1

[cffi-devel] New SCL port
by Luís Oliveira 23 Feb '06

23 Feb '06

Hello, Douglas Crosher has contributed a CFFI-SYS backend for the Scieneer Common Lisp. Attached is a diff. Also, you can grab a darcs patch here: http://common-lisp.net/~loliveira/patches/scl.patch As I mention in the log message, I couldn't find any other Lisp that supports long double, so adding the respective feature to cffi-features doesn't seem worth the trouble. AFAICT, Lispworks is the only one that mentions long double in the documentation but it doesn't seem to be implemented in win32, linux or darwin... -- Luís Oliveira luismbo (@) gmail (.) com Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

1 0

[cffi-devel] Unexpected return
by N. Raghavendra 23 Feb '06

23 Feb '06

I hope this is not OT. I am trying to learn to use CFFI. Following the CFFI manual, I wrote the following functions, which call some basic C time functions. According to gmtime(3), the function `gmtoff' below should always return 0. However, I consistently get TIMEZONE-FFI> (gmtoff) 672421260 I would appreciate any hints as to where I am erring. In case it is relevant, the environment is CMUCL 19c on FreeBSD 6.0-STABLE. TIA, Raghavendra. --- code follows --- (defpackage #:timezone-ffi (:use #:common-lisp #:cffi)) (in-package #:timezone-ffi) (defcstruct tm (sec :int) (min :int) (hour :int) (mday :int) (mon :int) (year :int) (wday :int) (yday :int) (isdst :boolean) (zone :string) (gmtoff :long)) (defctype time :int) (defcfun ("time" %time) time (tp :pointer)) (defcfun (gmtime %gmtime) :pointer (tp :pointer)) ;; Should return 0 always. (defun gmtoff () (with-foreign-object (tp 'time) (setf (mem-ref tp 'time) (%time (null-pointer))) (foreign-slot-value (%gmtime tp) 'tm 'gmtoff))) -- N. Raghavendra <raghu(a)mri.ernet.in> | See message headers for contact Harish-Chandra Research Institute | and OpenPGP details.

2 2

Re: [cffi-devel] CFFI 0.9.0 Release
by Hoehle, Joerg-Cyril 23 Feb '06

23 Feb '06

James Bielman wrote: >I've released the current darcs version of CFFI as 0.9.0. The darcs >tree has been tagged and checkpointed You should do that more often, because it creates shorter patch files. Previously, a tiny 10 line patch had 40KB worth of context. That is gone since you tagged cffi recently. Context is now much smaller. >I consider this the "beta" release leading up to a real 1.0 version. Of course, you're free to tag any version with any number you like. Here are points I'd like to see addressed: 1. IMHO CFFI should not go 1.0 prior to acknowledging that there's a relationship between functions and libraries (i.e. UFFI's :module keyword). Arseny has a case on MS-Windows where there are two versions of sprintf in different MS .dlls. One does not pass some tests, the other does. So far, CFFI does not allow the user to control which functions gets loaded from there. I consider this a *huge* misfeature. 2. I suggest you add the block operations API with my suggestions (from monthes ago). It's trivial to implement naively, and it would do users good to be able to use it (even CFFI code can benefit from it, there currently are a few block loops here and there). Later CVS versions may then add optimized versions for special cases. 3. (trivial): provide a uffi.asd file in a subdirectory, so people can load that and play with programs using ASDF and UFFI. A system named uffi-compat is IMHO useless, because these programs have ASDF look for a system named #:uffi. Regards, Jorg

3 3

[cffi-devel] New TopUSAJobs Best Job offer jT
by MakeUSA-Job 23 Feb '06

23 Feb '06

1 0

[cffi-devel] New CareerBuilder.com Job opportunity OV
by Career-Builder 23 Feb '06

23 Feb '06

1 0

[cffi-devel] A somewhat trollish idea
by Attila Lendvai 21 Feb '06

21 Feb '06

Hi! Recently i've made a project to use graphviz from lisp code through cffi (cl-graphviz at http://common-lisp.net) In the process i used the cffi generator of SWIG. It was not perfect so i've taken a look at the source which is in c++. Then i gave up early... :) And the idea: the CFFI/SWIG integration could be done in a different philosophy, where SWIG were used only as a c++ parser and the CFFI generator would be lisp code walking the C side parsed representation (using CFFI). The idea is trollish, because i did not invest enough time to see the big picture, but the generated file had serious trouble with statements like #define FOO (1<<2)|(1<<3). The generator (written in C++) was trying to interpret it with not so much luck. It would be simpler in lisp, and then you could also generate the project specific lisp-side API right on. The problem in general is not simple, because the value in a #define is a plain string, and it's sci-fi to start a C++ parser on that sniplet and walk the AST. In normal circumstances (c++ compiler) that define would go away in the preprocessor stage, but in an FFI you want to use the named values from lisp. Enough trolling for now, and thanks for all the work on CFFI, it's great! - attila (alias 101 on irc &no 'its not lisp code :)

2 1

[cffi-devel] New patches: 19-Feb-2006
by loliveira＠common-lisp.net 20 Feb '06

20 Feb '06

Sun Feb 19 22:48:13 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Make CLISP not throw an error on undefined functions - Catch the error in %foreign-funcall and throw a warning instead. - Regression test: DEFCFUN.UNDEFINED. (CMUCL fails) M ./src/cffi-clisp.lisp -5 +11 M ./tests/defcfun.lisp +11 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060219.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0