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

[Cffi-devel] Bugtracker
by Stelian Ionescu 01 Dec '14

01 Dec '14

Once upon a time Launchpad was the best in open-source and Github's issue tracker was unusable, but that's no longer the case. How about we officially switch to Github ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

2 6

[Cffi-devel] pkg-flags (was: Re: Cannot load cffi-libffi)
by Luís Oliveira 29 Nov '14

29 Nov '14

OK, so I see two needs for pkg-flags here then. 1. finding headers that aren't in the standard locations and wouldn't otherwise be found. 2. finding headers for a specific version of a library. I think the current committed behaviour works nicely for use case #1. Use case #2, which you've raised, suggests that ignoring a missing pkg-config is a bad default. What about adding making it an option? Also, if we're going to cater to use case #2, then perhaps we should support a list of alternatives à la define-foreign-library. What do you think? Finally, how about renaming the directive to pkg-config-cflags? (I can sort of imagine we might want a pkg-config-lfags for wrappers at some point in the future.) -- Luís Oliveira http://kerno.org/~luis/

3 3

Re: [Cffi-devel] [Asdf-devel] native-namestring in asdf/cache:normalize-namestring?
by Faré 25 Nov '14

25 Nov '14

Dear Orivej, I believe this is a bug in CFFI, and ASDF cannot do much about it. I'm copying the CFFI-devel mailing-list. I'm not convinced that these pathnames with invalid namestring would have a valid native-namestring (did you try?), and using native-namestring in asdf/cache:normalize-namestring would be quite impractical, since the function CL:FILE-WRITE-DATE that we subsequently use requires a Lisp namestring. The correct thing to do would be for CFFI to assume ASDF3 (which has been out for almost 2 years and has since been adopted by all maintained implementations), and use this definition: (defun exe-filename (defaults) (let ((defaults (uiop:ensure-pathname defaults :namestring :native :want-non-wild t :want-file t))) ;; YMMV (uiop:subpathname defaults (uiop:parse-unix-namestring (pathname-name defaults) :type *exe-extension*))) NB: if ASDF3 is adopted, the #+sbcl and other such kluges in cffi.asd could also be replaced by :if-feature :sbcl, the defmethod for operation-done-p should be dropped, and the defmethod perform could be replaced by: (defsystem "cffi" ... :in-order-to ((test-op (test-op "cffi-tests")))) and cffi-tests could similarly use an inline method :perform (test-op (o c) ...) instead of a defmethod. PS: the reason why SBCL (and many other implementations) have unprintable pathnames is because of the read-write consistency requirements for pathnames, which for the CLHS (see *print-readably* entry) specifies must be WRITE-n in a way that they must be read back as a "similar" object, which section 3.2.4.2.2 specifies as component-wise similarity, so that (make-pathname :name "foo.bar" :type nil) MUST NOT have the same readable representation as (make-pathname :name "foo" :type "bar"). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." — Isaac Asimov On Tue, Nov 25, 2014 at 11:24 AM, Orivej Desh <c(a)orivej.org> wrote: > Currently, between CFFI-GROVEL and ASDF, neither normalizes pathnames > with a dot in :NAME and NIL in :TYPE. > > > (cffi-grovel:grovel-file "grovel.cffi") > > in a system definition may cause an error under SBCL in > ASDF/CACHE:NORMALIZE-NAMESTRING when it calls NAMESTRING on > the value of CFFI-GROVEL::EXE-FILENAME: > > Calling > > (cffi-grovel::exe-filename #p"grovel.cffi.lisp") > > returns > > #<pathname (with no namestring) > :HOST #<sb-impl::unix-host {10002ACE43}> > :DEVICE nil > :DIRECTORY (:relative ".") > :NAME "grovel.cffi" > :TYPE nil > :VERSION :newest> > > to ASDF/ACTION:COMPUTE-ACTION-STAMP which can't deal with it when called > with :JUST-DONE NIL. > > Backtrace: http://report.quicklisp.org/cl-libssh2/2014-09-26/failtail.txt > > One solution is to make CFFI-GROVEL::EXE-FILENAME normalize resulting > pathname: https://github.com/cffi/cffi/pull/52 > > Another is to make ASDF/CACHE:NORMALIZE-NAMESTRING call > NATIVE-NAMESTRING instead of NAMESTRING. > > Who should be responsible for normalizing such a pathname, ASDF > of CFFI-GROVEL? >

2 1

[Cffi-devel] inline decfun
by FAU 25 Nov '14

25 Nov '14

I'm wondering if it as any effect to declaim inline a function defined by defcfun?

2 1

[Cffi-devel] clear foreign memory
by FAU 24 Nov '14

24 Nov '14

Hello, Lets say I want to keep around blocks of foreign memory but I need to clear them before I reuse them what would be the best way to do it? In C we could use memset() is there such an equivalent for CFFI? Thanks, Frank

3 4

[Cffi-devel] Cannot load cffi-libffi
by Liam Healy 23 Nov '14

23 Nov '14

On Debian/Ubuntu and SBCL, I cannot load the latest cffi-libffi To load "cffi-libffi": Load 1 ASDF system: cffi-libffi ; Loading "cffi-libffi" ; pkg-config libffi --cflags ; cc -m64 NIL -I/home/healy/languages/lisp/cffi/ -o /home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix /home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix.c debugger invoked on a CFFI-GROVEL:GROVEL-ERROR in thread #<THREAD "main thread" RUNNING {1002BEE843}>: External process exited with code 1. Command was: "cc" "-m64" "NIL" "-I/home/healy/languages/lisp/cffi/" "-o" "/home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix" "/home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix.c" Output was: cc: error: NIL: No such file or directory Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry PROCESS-OP on #<GROVEL-FILE "cffi-libffi" "libffi" "libffi">. 1: [ACCEPT ] Continue, treating PROCESS-OP on #<GROVEL-FILE "cffi-libffi" "libffi" "libffi"> as having been successful. 2: Retry ASDF operation. 3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 4: [ABORT ] Give up on "cffi-libffi" 5: Exit debugger, returning to top level. (CFFI-GROVEL:GROVEL-ERROR "External process exited with code ~S.~@ Command was: ~S~{ ~S~}~@ Output was:~%~A" 1 "cc" ("-m64" "NIL" "-I/home/healy/languages/lisp/cffi/" "-o" "/home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix" "/home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix.c") "cc: error: NIL: No such file or directory ") 0] I bisected this down to this commit: 4d5479d692f07c641d3218c4728fa43287528366 is the first bad commit commit 4d5479d692f07c641d3218c4728fa43287528366 Author: Sumant Oemrawsingh <soemraws(a)xs4all.nl> Date: Fri Oct 31 19:03:54 2014 +0100 Find cc-flags for libffi using pkg-config on linux. :040000 040000 2dec1750de47713e34eb726a561dec296a927a17 2a4da151f69703e60f54c8881a84a6a0dcc9d471 M libffi Liam

3 8

[Cffi-devel] Issue tracker (still) lives at Launchpad
by Luís Oliveira 22 Nov '14

22 Nov '14

Hello, I'm not sure how, but the issue tracker for CFFI's GitHub repository was somehow enabled. We still use Launchpad for bug tracking -- https://bugs.launchpad.net/cffi -- so I've closed all the issues on github and moved the one that still needs fixing to launchpad. Sorry for the confusion. Cheers, -- Luís Oliveira http://kerno.org/~luis/

1 0

[Cffi-devel] Callbacks & Lambdas
by FAU 12 Nov '14

12 Nov '14

Hello, I'm kinda new to CFFI. Is there a reliable/portable way to have lambdas called as a callback from a foreign C function? I assume there's not though. I could imagine it could be simulated (by a dispatcher callback or something) so I'm wondering if somebody has done something like that before and may share insight into her/his design. Thanks, Frank

3 6

[Cffi-devel] defcstruct &key size
by FAU 02 Nov '14

02 Nov '14

Hello, Apparently SIZE is not evaluated at macro expansion time. I basically want to pass the name of a foreign function as SIZE and have it evaluated. What would be the best way to do that? Currently I'm doing this: (eval-when (:compile-toplevel :load-toplevel :execute) (cffi:define-foreign-library libfoo (:unix "libfoo.so")) (cffi:load-foreign-library 'libfoo) (cffi:defctype size :uint) (cffi:defcfun ("foo_size" foo-size) size)) (macrolet ((m () `(cffi:defcstruct (foo-struct :size ,(eval-when (:compile-toplevel :load-toplevel :execute) (foo-size))) (data :pointer)))) (m))

2 1