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

proposed fixes for cffi-libffi on Windows7+MSYS
by Mirko Vukovic 09 Apr '16

09 Apr '16

So, after a long hiatus I updated CFFI, only to see dreaded compilation errors pop-up. Nothing better to keep me awake for an extra hour. The two patches (in the attached file) fix the error that I see and improve the code slightly. One patch removes ^M that CCL sees at the end of output of pkg-config. The need for the second patch arises in the case when the package loading fails, and I try to load it again. In that case *cc-flags* gets loaded with duplicate entries. This patch removes the duplicates. I generated the patches with the command: git format-patch master --stdout > mv-mods.txt If there is a better way to submit patches, let me know how and I will resend. Thanks, Mirko

2 2

How to define the interface to "const char *"
by Mirko Vukovic 07 Apr '16

07 Apr '16

This is on Windows 7, CCL, latest CFFI pull. I am writing an interface to a function that has a const char * as in input: int DDC_GetFileStringPropertyLength (DDCFileHandle file, *const char *property*, unsigned int *length); In my defcfun, can I use *:string*, or do I need to do something special? The reason I ask is that calls to this function cause a memory exception on one of my computers, while it works fine on the second computer. Thanks, Mirko

2 1

Quicklisp CFFI doesn't load on Raspberry PI
by Martin Kielhorn 17 Mar '16

17 Mar '16

Hi, I tried to load cffi that comes with Quicklisp on SBCL 1.3.2 on a Raspberry PI 2. I had to comment out FFI_UNIX64 (cenum abi ((:default-abi "FFI_DEFAULT_ABI")) ((:sysv "FFI_SYSV")) #+nil ((:unix64 "FFI_UNIX64")) ) in the file quicklisp/dists/quicklisp/software/cffi_0.16.1/libffi/libffi-unix.lisp to make it load. Regards, Martin

5 9

expand-into-foreign-memory query
by Chris Bagley 13 Mar '16

13 Mar '16

Hi all, I am working on a project where I believe the overhead of the call to translate-into-foreign-memory is starting to be an issue & as such I'm looking into implementing expand-into-foreign-memory. Before starting on this I thought I would ask if this feature would be welcome in cffi and also if there are any fundamental reasons this would not work. So far I have been reading the source for expand-from-foreign and expand-to-foreign and it seems that expand-into-foreign-memory would be fairly similar. Also from the comments in mem-set it looks like this feature was intended at some point. As ever thankyou for the awesome work on this project and I hope I can give something back to it soon. Cheers, Baggers

2 1

CFFI 0.17.1 released
by Luís Oliveira 12 Mar '16

12 Mar '16

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

1 0

CFFI govels size_t into :sizet [Was: cffi 0.17.0 breaks some stuff]
by Attila Lendvai 03 Mar '16

03 Mar '16

> I'm seeing a bunch of projects that don't seem to work with the latest CFFI > release. For example, I get this for a number of projects: > > Unhandled CFFI::UNDEFINED-FOREIGN-TYPE-ERROR in thread #<SB-THREAD:THREAD > "main thread" RUNNING {1003DD5643}>: Unknown CFFI type :SIZET > > That happens in gsll and some other projects. the situation: cffi-libffi used to grovel size_t under the name :sizet, and it's used by a few projects, e.g. gsll, which got broken. i deleted :sizet in this cleanup: https://github.com/cffi/cffi/commit/4fbe5864552d6f7d8866745f371346174acea942 i've reinstated it temporarily with an OBSOLETE warning just now. reasons for the removal: - for me it seems pretty ad-hoc why this one definition is included and the other C stdlib definitions are not. - if we want to include and support size_t in the CFFI contract, then why in cffi-libffi? keep in mind that it requires groveling, which is quite a heavy dependency that CFFI proper doesn't require at this point. - why in the keyword package? (and it's another discussion why :int and other standard C definitions (not to be confused with stdlib.h) are in the keyword package, but i won't pursuit that argument at this point in time) maybe we want to open a new ASDF system for the C stdlib that would depend on the groveler and accommodate for C stdlib definitions like errno, size_t, etc? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Nationalism of one kind or another was the cause of most of the genocide of the twentieth century. Flags are bits of colored cloth that governments use first to shrink-wrap people's brains and then as ceremonial shrouds to bury the dead.” — Arundhati Roy (1961–), 'Come September' speech

6 21

defcenum with non-integer base-type
by Attila Lendvai 24 Feb '16

24 Feb '16

the situation: some projects out in the wild use DEFCENUM with e.g. :DOUBLE base-type. this is not in adherence with the C standard (only integer types are valid enum types, and it's at least int sized). my refactoring of enums introduced an explicit check for this, and it broke some projects in ql. to alleviate that i've commented out this new check in master. the question: should we roll with this? does anyone see any problems or potentially surprising behavior? e.g. with the semantics of the enum increments and the double base type? or something else? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “There is nothing sacrosanct about the majority; the lynch mob, too, is the majority in its own domain.” — Murray N. Rothbard (1926–1995), 'For a New Liberty' (1973)

3 4

cffi 0.17.0 breaks some stuff
by Zach Beane 24 Feb '16

24 Feb '16

Hi, I'm seeing a bunch of projects that don't seem to work with the latest CFFI release. For example, I get this for a number of projects: Unhandled CFFI::UNDEFINED-FOREIGN-TYPE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1003DD5643}>: Unknown CFFI type :SIZET That happens in gsll and some other projects. cl-gtk2 has this: Unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1003DD5663}>: NIL is not a valid symbol for bitfield type #<CFFI::FOREIGN-BITFIELD GOBJECT.FFI:G-TYPE-FLAGS>. There are other problems in cl-glu. There's a report here: http://report.quicklisp.org/2016-02-22/failure-report.html Not all of the problems in the report are directly cffi-related, but many of them are. Zach

2 1

release policy and quicklisp
by Attila Lendvai 19 Feb '16

19 Feb '16

the situation: hu.dwim.sdl depends on the new cffi/c2ffi stuff, and it's needed for projectured. to make playing with projectured simple, in its readme and its build.sh we rely on ql. ql takes its snapshot of CFFI from the CFFI release tgz, so hu.dwim.sdl cannot be added to the next ql release. my goals: have a shorter "release" cycle when it comes to ql snapshots. my proposal: set up a branch called 'quicklisp' in the CFFI repo and change ql to capture that instead of the release tgz. this is what VCS'es are designed for after all. sidenote: i think in the long run it would be better to use a moving tag for this, but for now the ql infrastructure doesn't support that for git repos. unfortunately git doesn't handle well when history is overwritten with a push -f on the remote side, but tags don't have that problem (git fetch --tags readily overwrites local tags with the remote ones). a small glitch in this almost ideal release management scheme is that git overwrites tags as opposed to keeping a stack of them and thus doesn't presere their history. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “You are what you do, not what you say you’ll do.” — Carl Jung (1875–1961)

4 4

New CFFI fails to load cl-cairo2-xlib
by Liam Healy 02 Feb '16

02 Feb '16

Latest head 9b312d0d7e38 (ql:quickload :cl-cairo2-xlib) Many messages like ; caught ERROR: ; don't know how to dump #<CFFI::AGGREGATE-STRUCT-SLOT {1016815063}> (default MAKE-LOAD-FORM method called). ; ==> ; #<CFFI::AGGREGATE-STRUCT-SLOT {1016815693}> eventually abort to ; ; compilation unit aborted ; caught 2 fatal ERROR conditions ; caught 54 ERROR conditions (:CL-CAIRO2-XLIB) When rolled back to 26f11a2bfe6c, everything is fine. On SBCL, amd64 Debian. Liam

3 5