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

CFFI 0.19.0 released
by Luís Oliveira 26 Jun '17

26 Jun '17

Hello, We've just released CFFI 0.19.0! * new feature: a new CFFI-SYS backend for Clasp has been added, courtesy of Frank Gröninger. * enhancement: cffi/c2ffi now handles anonymous enums properly, properly parses double float constants and has a new facility, callback-factory, that allows users to customize form generation. (Thanks to Chris Bagley.) * enhancement: various improvements to cffi-toolchain. (Thanks to François-René Rideau.) * bugfix: foreign library alternatives are now searched taking into account the search-pathprovided to load-foreign-library (or equivalently specified via define-foreign-library). (Thanks to Pavel Korolev.) Cheers, -- Luís Oliveira http://kerno.org/~luis/

1 0

New quicklisp release
by Chris Bagley 26 Jun '17

26 Jun '17

Are there any plans on making a new release? Quicklisp is currently shipping 0.18.0 which is from last October.

2 1

invoking renamed foreign function
by Anton Vodonosov 29 May '17

29 May '17

2 7

Delivering single-file applications with cffi-toolchain
by Faré 26 Jan '17

26 Jan '17

Dear CFFI developers, may I attract your attention to pull request #112 ? https://github.com/cffi/cffi/pull/112 It adds among other things the ability to deliver an application with C code statically linked into a SBCL runtime (or CLISP, or ECL, or MKCL, though these are less stable). I understand you might want me to refactor the code, or not. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Those "organizers" who confuse coordination and cooperation will have 100% coordination for 0% cooperation. All costs, no benefits.

2 2

RFC about extending defctype to support c like inline types
by Attila Lendvai 15 Oct '16

15 Oct '16

so, take this C definition: typedef enum { a = 0, b } typeName; it's a typedef where the type is not denoted by a name, but rather it's an inline (anonymous) enum. the symmetric equivalent of this definition is not possible in cffi. it would look something like: (cffi:defctype typeName (cffi:defcenum nil a b)) or maybe (cffi:defctype typeName (cffi:cenum a b)) the issue where it comes up is in cffi/c2ffi, where the filtering rules may filter out entries, and because the above is not possible, the anonymous definition is given a generated name and referenced using that name later in the defctype. it causes headache where filters are applied to the typedef's name, and whether the anon definition is needed depends on the outcome of those filters. i see two ways to solve this: 1) extend cffi:defctype (and anything else?) to support the above mentioned missing feature. 2) make the c2ffi generator smarter which would be a considerable amount of complexity for a half-assed solution (the output will be full of definitions called anon-123). i'd vote for 1), and i'd be willing to implement it, but before i get into that, what do y'all think? some feedback would be welcome! -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Humanity can be saved only if there are enough conscious people in the world, people who are not Christians, not Hindus, not Americans, not Russians, who are simply conscious, and can create a climate of consciousness around the earth.” — Osho (1931–1990), 'From Darkness to Light' (1985)

2 1

CFFI 0.18.0 released
by Luís Oliveira 15 Oct '16

15 Oct '16

Hello, We've just released CFFI 0.18.0! * enhancement: the groveller wrapper in-package directive now catches missing packages earlier and more clearly. (Thanks to Chris Bagley.) * enhancement: added expand-into-foreign-memory optmization hook similar to expand-to-foreign. (Thanks to Chris Bagley.) * enhancement: cffi-toolchain no longer needlessly depends on a very recent ASDF. (Thanks to Stas Boukarev.) * optimization: a new foreign-slot-pointer compiler macro avoids slot info lookups at runtime when then struct type and slot name are constant. (Thanks to Chris Bagley.) * bugfix: cffi-toolchain parses command flags properly on windows. (Thanks to Mirko Vukovic.) * bugfix: various cffi/c2ffi fixes. (Thanks to Attila Lendvai.) * bugfix: defcallback fixed on Android/ECL. (Thanks to Daniel Kochmanksi.) * bugfix: the ABCL backend has been fixed to handle recent JNA changes. (Thanks to Daniel Kochmanksi.) Cheers, -- Luís Oliveira http://kerno.org/~luis/

1 0

Would love some feedback on wip feature
by Chris Bagley 06 Oct '16

06 Oct '16

Hi folks, I'm currently working on adding caching of .so and wrapper files to cffi. This is to handle issues arising from trying to use various libraries on machines without a C compiler. I'm hoping you can take a peek at my branch [0] and see if I'm going in the right direction. The changes are very simple, we allow users to specify a cache directory by using an optional :cache-dir argument in :grovel-file & :wrapper-file forms. CFFI will then look there first for the required files before trying to compile them itself. The tricky bit is that we recommend that people use the #+ & #- reader conditionals in the grovel and wrapper specifications, which means the cached results are only applicable if all the required feature-forms match. To handle this I am currently using my with-cached-reader-conditionals library [1] which, whilst small and standalone, could be replicated inside CFFI if required. The library modifies the readtable so that feature expression still work as before, but the also record the feature-forms used. With the captured feature information we can make a subdirectory inside the :cache-dir directory, whose name is based on the feature information. In my current experiment it does something simple & easy to read, however it would likely make directory names too long for windows users. For example I took osicat and added a cache directory to the following lines: (:grovel-file "basic-unixint" :cache-dir "foo") (:wrapper-file "wrappers" :soname "libosicat" :cache-dir "foo") The "foo" directory has the following contents bsd_nil_darwin_nil_freebsd_nil_linux_t_openbsd_nil unixint.processed-grovel-file darwin_nil_linux_t_mips_nil_openbsd_nil_windows_nil basic-unixint.processed-grovel-file linux_t_windows_nil libosicat.so wrappers.processed-wrapper-file All the system does is copy these files to the same directory the system would have put the compiled results in the standard system. My next addition is going to be a function the user can call that will do the following: - Work out if cffi-grovel has cached files for the grovel and wrapper results - If it didnt have those files it will copy the cachable files to a user specified location (or maybe just the cache directory) The idea of this is that it will allow the users to easily dontate their cache files to the project which hopefully means we can better coverage quickly Thoughts would be very welcome, I hope this finds you all well, Baggers [0] https://github.com/cbaggers/cffi/tree/feature-grovel-caching [1] https://github.com/cbaggers/with-cached-reader-conditionals

5 9

Groveller feature proposal: include-local
by Chris Bagley 27 Sep '16

27 Sep '16

Aim: Add include-local to the groveller. Behaviour: - uses #include "name.h" rather than #include <name.h> - expects the header file to be local to the wrapper/groveler specification file. This file is copied to the cache dir (with the generated c file) so it can be used in the build. Reason: This allows us to wrap single header libraries simply by making a wrapper spec containing > (include-local "some_header_lib.h") I'd love to hear some thoughts on this. I'm happy to get this done if it's approved. Regards Chris

3 5

need help debugging wierd dlopen failure
by Jim Newton 21 Sep '16

21 Sep '16

If someone could give me some clues about how to debug this it would be great. I'm trying to figure out why "it" fails to load a particular dylib under macOS. "it" meaning that I'm not sure who is actually failing, but I suspect it is actually a failure detected and reported by dlopen(3) itself, rather than something wrong in cffi. The problem seems to be that loading libgdk-x11-2.0.0.dylib triggers a complaint about a library I have loaded from a different place, but the error message indicates a location I have not loaded my LD_LIBRARY_PATH. Could it possibly be that libgdk-x11-2.0.0.dylib has a hard coded path in it pointing to /usr/local/lib ? If someone could give me some clues about how to debug this it would be great. I've set up my LD_LIBRARY_PATH so that it seems to be loading the correct libcairo.2.dylib from /usr/local/Cellar/cairo/1.12.16_1/lib/libcairo.2.dylib. The reason I think this is because both vmmap (unix command line) and cffi::list-foreign-libraries (lisp) give compatible results. sh> vmmap -w 16787 | grep dylib | sed -e 's/^.*SM=... //' | grep cairo /usr/local/Cellar/cairo/1.14.6_1/lib/libcairo.2.dylib sh> and CL-USER> (cffi::list-foreign-libraries) (... #<CFFI:FOREIGN-LIBRARY :LIBCAIRO #P"/usr/local/Cellar/cairo/1.12.16_1/lib/libcairo.dylib" (truename=#P"/usr/local/Cellar/cairo/1.12.16_1/lib/libcairo.2.dylib")>) CL-USER> However, when I attempt to load libgdk-x11-2.0.0.dylib it complains that it cannot find a particular symbol in /usr/local/lib/libcairo.dylib. Why is it complaining about /usr/local/lib/libcairo.dylib? Unable to load any of the alternatives: ("libgdk-x11-2.0.0.dylib" "libgdk-x11-2.0.dylib") Attempting to load GDK::GDK from lib "libgdk-x11-2.0.dylib" (%LOAD-FOREIGN-LIBRARY GDK /usr/local/Cellar/gtk+/2.24.24/lib/libgdk-x11-2.0.0.dylib) Unable to load foreign library (GDK::GDK). Error opening shared object "/usr/local/Cellar/gtk+/2.24.24/lib/libgdk-x11-2.0.0.dylib": dlopen(/usr/local/Cellar/gtk+/2.24.24/lib/libgdk-x11-2.0.0.dylib, 10): Symbol not found: _cairo_xlib_surface_create Referenced from: /usr/local/Cellar/gtk+/2.24.24/lib/libgdk-x11-2.0.0.dylib Expected in: /usr/local/lib/libcairo.dylib in /usr/local/Cellar/gtk+/2.24.24/lib/libgdk-x11-2.0.0.dylib. Attempting to load GDK::GDK from lib "libgdk-x11-2.0.0.dylib" (%LOAD-FOREIGN-LIBRARY GDK /usr/local/Cellar/gtk+/2.24.24/lib/libgdk-x11-2.0.0.dylib) Unable to load foreign library (GDK::GDK). Error opening shared object "/usr/local/Cellar/gtk+/2.24.24/lib/libgdk-x11-2.0.0.dylib": dlopen(/usr/local/Cellar/gtk+/2.24.24/lib/libgdk-x11-2.0.0.dylib, 10): Symbol not found: _cairo_xlib_surface_create Referenced from: /usr/local/Cellar/gtk+/2.24.24/lib/libgdk-x11-2.0.0.dylib Expected in: /usr/local/lib/libcairo.dylib in /usr/local/Cellar/gtk+/2.24.24/lib/libgdk-x11-2.0.0.dylib. [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR]

3 4

Re: How to load a dylib from a particular place
by Luís Oliveira 19 Sep '16

19 Sep '16

On Thu, Sep 15, 2016 at 4:31 PM, Jim Newton <jimka.issy(a)gmail.com> wrote: > I can try your suggestion, but according to the documentation this won't > work. The documentation says the list is only used if dload(3) fails the > first time. I know that dload(3) succeeds the first time by loading the > wrong version. Oh, I see. Missed that bit of information, sorry. Can you delete the bad version or tweak the define-foreign-library definition to point to the right one? Cheers, -- Luís Oliveira http://kerno.org/~luis/

2 2