cffi-devel October 2016

cffi-devel@common-lisp.net

6 participants
3 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel October 2016