cffi-devel

cffi-devel@common-lisp.net

1113 discussions

RFC on changes to enum and bitfield semantics
by Attila Lendvai 13 Jan '16

13 Jan '16

on my quest to implement an automatic generator for CFFI bindings (using c2ffi), i've recorded some patches that change the semantics of enums and bitfields. automatically generated bindings (should) live in an empty lisp package, and to avoid surprises it's also desirable to bring the CFFI behavior (regarding e.g. C namespaces) as close to C as possible. the code is available in this PR: https://github.com/cffi/cffi/pull/84 the following are controversial and i'd welcome some input on them from CFFI gurus, especially regarding what should/could get into master eventually: - enums don't demand member names to be CL:KEYWORDP anymore - DEFCENUM and DEFBITFIELD now expand a toplevel DEFCONSTANT for each member. the rationale is to bring it closer to the C enum semantics where they are in the main namespace. - BITFIELD now inherit from ENUM, and adds extra semantics for values that are the power of two. but should 0 be treated as a bitfield bitmask? IOW, should (FOREIGN-BITFIELD-SYMBOLS 'FOO 0) return NIL or '(ZERO-MEMBER-NAME)? the code currently does not treat 0 as a bitmask (which is an incompatible change). - the accessor names are rather inconsistent: FOREIGN-ENUM-VALUE FOREIGN-BITFIELD-VALUE FOREIGN-ENUM-KEYWORD FOREIGN-BITFIELD-SYMBOLS FOREIGN-ENUM-KEYWORD-LIST FOREIGN-BITFIELD-SYMBOL-LIST i'd like to rename the last four of them to (not done yet): FOREIGN-ENUM-KEY FOREIGN-BITFIELD-KEYS FOREIGN-ENUM-KEY-LIST FOREIGN-BITFIELD-KEY-LIST and leave some aliases and deprecation warnings behind. but are the names ok? or any better ideas? - another minor issue is that 'bitfield' is a confusing name, because the C standard calls the 'int:3' kind of types as bitfields. i suggest to rename them to 'bitmask' in CFFI. maybe incompatibly? or only in a new major version? it'd be nice if this could be merged before the next quicklisp release, because there are some projects that depend on them that i'd like to get into ql the sooner the better. thanks, and happy hacking, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The cost of sanity in this society, is a certain level of alienation.” — Terence McKenna (1946–2000)

2 1

Calling a struct-by-value by reference
by Liam Healy 23 Dec '15

23 Dec '15

Hi Attila, Re: https://bugs.launchpad.net/cffi/+bug/1528719 (There is an error in the sample code, the struct is called 'struct-pair, not 'pair.) Here is a simpler exhibition of the problem (sumpair (convert-to-foreign '(40 . 2) '(:struct struct-pair))) The value #.(SB-SYS:INT-SAP #X7FFFEC003560) is not of type LIST. [Condition of type TYPE-ERROR] So, you've said the function is call-by-value, and then you want to pass a pointer to the structure, and it makes sense there's an error. You have to assume a translator, because that's the only way to have a structure by value. I understand the desire to be able to pass a pointer instead, but my approach would be different. I'd change the function argument definition and extend the syntax to say that you're going to pass a pointer, e. g. (defcfun "sumpair" :int (p (:struct struct-pair) :pointer)) which I would have expand to something like (DEFUN SUMPAIR (P) (WITH-FOREIGN-OBJECTS ((CFFI::ARGVALUES :POINTER 1) (CFFI::RESULT ':INT)) (MEM-REF (PROGN (LOOP :FOR CFFI::ARG :IN (LIST P) :FOR COUNT :FROM 0 :DO (SETF (MEM-AREF CFFI::ARGVALUES :POINTER COUNT) CFFI::ARG)) (CFFI::CALL (CFFI::PREPARE-FUNCTION "sumpair" ':INT '((:STRUCT STRUCT-PAIR)) ':DEFAULT-ABI) (FOREIGN-SYMBOL-POINTER "sumpair") CFFI::RESULT CFFI::ARGVALUES) CFFI::RESULT) :INT))) So now you can do (sumpair (convert-to-foreign '(40 . 2) '(:struct struct-pair))) 42 I don't like the idea of hacking up translate-into-foreign-memory because you're doing extra work that way, and as you can see, the expansion can be simpler than the translated case. The only disadvantage of this approach is that you'll have to have two different functions if you will be calling the same function with a CL object and with a foreign pointer. I imagine that this won't happen very often; I'm guessing this is for chaining together foreign calls in CL, where the foreign structure never sees the light of day (=lisp form). (The defcfun won't expand the way I've shown yet, but the pseudo-expansion actually can be compiled and run.) What do you think? Liam

2 1

Type propagation proposal
by Attila Lendvai 23 Dec '15

23 Dec '15

i wrote up some ideas here: https://github.com/cffi/cffi/wiki/Type-propagation-proposal you're invited to comment/edit it. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The first thing you have to do if you want to raise nice kids, is you have to talk to them like they are people instead of talking to them like they're property.” — Frank Zappa (1940–1993), 'The Howard Stern Show' (1987)

4 7

RFC on plans to implement a c2ffi->cffi generator
by Attila Lendvai 21 Dec '15

21 Dec '15

dear list, c2ffi is a tool written in C that uses the llvm/clang libs to generate a json file from C headers. it's like gcc-xml, only much better. the json file has explicit offsets and sizes, etc... see an example here: https://github.com/rpav/ZMQ4L/blob/master/src/autospec/zmq.x86_64-pc-linux-… once this json has been generated for your platform, it can be checked into the repo and no external tool is needed afterwards. cl-autowrap uses such json files to generate an alternative FFI API, but i'd like to use vanilla CFFI, so i'm planning to write some code towards this direction, but i'd like to hear some input on this before i start working on anything... i imagine it to be similar to how groveling works in iolib, namely: generate the intermediate files from the json files using some ASDF integration, and then compile the lisp files as any other lisp files. my first question is why isn't this ASDF integration, or something like this, ported into cffi for the gorveler? is there any other reason besides nobody has done it yet? https://github.com/sionescu/iolib/blob/master/src/grovel/asdf.lisp does anyone see some showstoppers? e.g. can i lay out defcstruct fields with explicit offsets? NOTICE-FOREIGN-STRUCT-DEFINITION suggests so. should this code go into a cffi-c2ffi.asd or into a standalone project? any ideas for a name? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- Blaming the prince of the fools should not blind anyone to the vast confederacy of fools that made him their prince.

3 16

Using pkg-config (hdf5)
by Liam Healy 09 Dec '15

09 Dec '15

Debian has relocated hdf5 includes and libraries in serial/, which means that hdf5-cffi does not compile. See this issue: https://github.com/HDFGroup/hdf5-cffi/issues/61. I am trying to come up with a CFFI solution. It seems like pkg-config-cflags should do the job for me, as pkg-config is installed and does the right thing: pkg-config --libs hdf5 -L/usr/lib/x86_64-linux-gnu/hdf5/serial -lhdf5 pkg-config --cflags hdf5 -I/usr/include/hdf5/serial However, I put a line (pkg-config-cflags "hdf5" :optional t) in hfd5-cffi/hdf5/grovel.lisp and got nothing useful; it is clear it is running pkg-config but the result never makes it into the cc arg list. (ql:quickload :hdf5-cffi) To load "hdf5-cffi": Load 1 ASDF system: hdf5-cffi ; Loading "hdf5-cffi" [package hdf5]; pkg-config hdf5 --cflags -I/usr/include/hdf5/serial ; cc -m64 -o /home/healy/.cache/common-lisp/sbcl-1.2.15-linux-x64/home/healy/languages/lisp/hdf5-cffi/hdf5/grovel__grovel-tmpGHU3ALSV -I/home/healy/languages/lisp/cffi/ /home/healy/.cache/common-lisp/sbcl-1.2.15-linux-x64/home/healy/languages/lisp/hdf5-cffi/hdf5/grovel__grovel.c ; /home/healy/.cache/common-lisp/sbcl-1.2.15-linux-x64/home/healy/languages/lisp/hdf5-cffi/hdf5/grovel__grovel /home/healy/.cache/common-lisp/sbcl-1.2.15-linux-x64/home/healy/languages/lisp/hdf5-cffi/hdf5/grovel__grovel.grovel-tmp.lisp ; cc -m64 -o /home/healy/.cache/common-lisp/sbcl-1.2.15-linux-x64/home/healy/languages/lisp/hdf5-cffi/hdf5/h5-grovel__grovel-tmpAAURSO1 -I/home/healy/languages/lisp/cffi/ /home/healy/.cache/common-lisp/sbcl-1.2.15-linux-x64/home/healy/languages/lisp/hdf5-cffi/hdf5/h5-grovel__grovel.c /home/healy/.cache/common-lisp/sbcl-1.2.15-linux-x64/home/healy/languages/lisp/hdf5-cffi/hdf5/h5-grovel__grovel.c:6:18: fatal error: hdf5.h: No such file or directory #include <hdf5.h> ^ compilation terminated. Is this a problem of CFFI or dies the pkg-config-cflags form need to be somewhere else? Liam

2 2

what is the length of a long (motivated by GSL2.1 and GSLL)
by Mirko Vukovic 23 Nov '15

23 Nov '15

This message has two audiences: One the general CFFI group, and second the GSL maintainer. This is using latest CCL and SBCL on 64-bit Windows 7, and MSYS2 running 64-bit MinGW and its GSL2.0 and 2.1. Running GSL 2.0 and 2.1 under GSLL resulted in exception violations. I could eliminate them by specifying the length of an integer as 8 instead of 4 bytes. My question has to do with the origin of this specification, since it is derived from CFFI and GSLL, not hard-coded. Specifically, in GSLL, the following code in init/types.lisp: (case (cffi:foreign-type-size :long) *(8 (push :int64 *features*))* *(4 (push :int32 *features*))*) evaluates to 4, pushing :int32 into *features*. Here is some additional output of cffi:foreign-type-size on my machine: GSL> (cffi:foreign-type-size :double) 8 GSL> (cffi:foreign-type-size :long) 4 GSL> (cffi:foreign-type-size :long-long) 8 GSL> (cffi:foreign-type-size :int) 4 This feature eventually makes its way to other code in GSLL. In the Linear Algebra module, the function make-permutation (in data/permutation.lisp) has this line: (make-instance 'permutation :element-type '(unsigned-byte *#+int64 64* *#+int32 32*) :dimensions (if (typep n 'permutation) (grid:dimensions n) (list n))))) In my environment element type resulted in unsigned-byte 32. When I hard-coded my features to :int64 (and unsigned-byte 64), all the exception errors disappeared. I hope this gives enough background to fix this error (either in my setup, gsll, or cffi). Thanks, Mirko

2 1

Re: tweak for cffi-grovel::trim-whitespaces?
by Luís Oliveira 11 Nov '15

11 Nov '15

On Wed, Nov 11, 2015 at 4:39 PM, Mirko Vukovic <mirko.vukovic(a)gmail.com> wrote: > Hi Louis, > > (I reply to you and not to the forum since you replied to me only - you are > welcome to forward my reply to the forum) Oops, my mistake. > I downloaded from github and got qualified success: > - At first loading I had to specify the path to ffi.h using cffi::*cc-flags* > for the compilation to proceed That's unexpected. Does that mean it failed to execute pkg-config? If the compilation log doesn't yield any tips, perhaps you could tweak the pkg-config-cflags definition (in cffi/grovel/grove.lisp) to add some debugging output and see what's going on there? > I downloaded from github and got qualified success: > - At first loading I had to specify the path to ffi.h using cffi::*cc-flags* > for the compilation to proceed > - On subsequent loadings, I did not need to do that > > I used ql:quickload to load :cffi-libffi > > Tested on CCL 1-11 and SBCL 1.3.0 > > Both Antik and GSLL compile nicely (except for some other minor issues, but > those are for the antik/gsll forum). > > Thanks, > > Mirko Thanks, -- Luís Oliveira http://kerno.org/~luis/

2 4

tweak for cffi-grovel::trim-whitespaces?
by Mirko Vukovic 11 Nov '15

11 Nov '15

Hello, This is on - 64-bit Windows - Msys+mingw64 GCC compilation suite - ccl and/or sbcl (latest Windows version) - cffi 0.16.1. I had problems loading cffi-libffi: - CCL did fine - SBCL barfed during the grovel phase: > Paths returned by pkg-config had a control-M appended to the end I fixed that by adding \#Return to the list of characters trimmed by cffi-grovel::trim-whitespaces. With that addition both SBCL and CCL loaded cffi-libffi. Mirko

2 1

CFFI + asdf bundles
by Faré 12 Oct '15

12 Oct '15

Here is a patch that will make CFFI play better with ASDF bundles. This allows delivery with a single .so and/or .a file for all the wrappers in a system, which can be automatically linked into ECL (and in the future, in SBCL or other implementations, for application delivery). Also, report for a bug, not fixed in the attached patch: compiling, linking, etc., should be atomic, by using temporary pathnames; otherwise, there is a race condition when multiple processes try to execute a script that depends on a CFFI library. Recent-enough ASDF 3.1.2 provides with-temporary-file to help, and 3.1.5 uses it internally for its own targets, but some implementations still lag behind with ASDF 3.0.x, and ASDF can't backwards-compatibly use with-temporary-file for you, so you must use it yourself. This patch also drops support for ASDF 2 or earlier, because backwards compatibility is hard, and not necessary: today, all implementations provide ASDF 3. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The least deviation from truth will be multiplied later. — Aristotle

2 8

CFFI 0.16.0 released
by Luís Oliveira 23 Aug '15

23 Aug '15

Hello, We've just released CFFI 0.16.0! https://github.com/cffi/cffi/wiki/NEWS#version-0160 Cheers, -- Luís Oliveira http://kerno.org/~luis/

1 1

← Newer
1
...
4
5
6
7
8
9
10
...
112
Older →

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