cffi-devel February 2016

cffi-devel@common-lisp.net

6 participants
5 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel February 2016