cffi-devel May 2011

cffi-devel@common-lisp.net

6 participants
6 discussions

[cffi-devel] Digitool MCL support for CFFI (was Re: [info-mcl] ? cffi)
by Chun Tian (binghe) 10 Mar '12

10 Mar '12

Hi, CFFI developers Digitool MCL was a old&famous Common Lisp implementation on PPC Mac OS. Recently it was ported into Intel Mac OS X by running in Rosetta (a PPC emulator by Apple). So there're people still using this platform even when Clozure CL is a better choice. Attach is two patches, one is a CFFI MCL support patch made by James Anderson, the other is a trivial patch for MCL support of trivial-features made by me. With these two patch, CFFI can now be loaded into Digitool MCL. This work seems work with James' own project which is based on CFFI. But CFFI-TESTS cannot run at this time, because ASDF:RUN-SHELL-COMMAND doesn't support MCL (I don't know how to fix this right now). IOlib also cannot work in MCL because Gray Streams wasn't supported by MCL yet ... However, I hope CFFI maintainer could merge this patch and let other MCL users help improving exist work. Chun Tian (binghe) 在 2010-9-28，06:41， james anderson 写道： > good morning; > > i have worked out enough of a cffi-mcl to be able to accomplish the immediate goal - to use the cl-zmq zeromq ffi binding.[1] > in case someone wants to carry it further, it's posted along with a mcl-compatible zmq version,[2] which eliminates un-ported dependencies. > > --- > [1] : http://repo.or.cz/w/cl-zmq.git > [2] : http://github.com/lisp/de.setf.zeromq > > On 2010-09-22, at 08:29 , Chun Tian (binghe) wrote: > >> I've read these documents. MCL 4.0's FFI seems based on the function "define-entry-point" which then depends on "ppc-ff-call", both of them are still available in MCL 5.x, and the related MCL source code is "lib/deftrap.lisp", which was last modified in 2005. >> >> However, I think "define-entry-point" is not the preferred way any more: >> >> ; Change log >> ; >> ; put back define-entry-point and things it depends on - though MCL doesn't use it users may >> ; ------ 5.2b2 >> >> I think CFFI people, if want to support MCL, should research "deftrap.lisp" and figure out the preferred way to do the work. But for me, a USOCKET maintainer, I'd like to use this interface directly to implement UDP networking, which was lack from OpenTransport. >> >> --binghe >> >> 在 2010-9-22，13:30， james anderson 写道： >> >>> there are two sources. >>> >>> if you go to ftp.clozure.com, you will find the 5.2 release and a copy of the documentation for 4.0. >>> i know of no revised documentation for 5.2. other than that, there is always the source. >>> i believe 5.2 has a very different calling mechanism then 4.0, as it uses a different os x facility to manage foreign libraries. >>> >>> the biggest '?' is turning off the gc for the dynamic extent of any foreign calls which pass lisp data. i do not know if that is possible in mcl, but it could be faked by moving the data to/from temporary external storage just to get it working. >>> two little question marks are the data type size calculations and the call-back protocol. >>> since the source is there, there's nothing stopping me from adapting the clozure-specific code to work in mcl. >>> i was just hoping to avoid having to wrap my head around those bits. >>> >>> >>> On 2010-09-22, at 04:45 , Chun Tian (binghe) wrote: >>> >>>> Never know how to do FFI in Digitool MCL ... Where can I find some API documents? >>>> >>>> --binghe >>>> >>>> 在 2010-9-22，05:36， james anderson 写道： >>>> >>>>> good morning; >>>>> >>>>> has anyone ported cffi to mcl? >>>>> >>>>> >>>>> _______________________________________________ >>>>> info-mcl mailing list >>>>> info-mcl(a)clozure.com >>>>> http://clozure.com/mailman/listinfo/info-mcl >>>> >>>> _______________________________________________ >>>> info-mcl mailing list >>>> info-mcl(a)clozure.com >>>> http://clozure.com/mailman/listinfo/info-mcl >>> >>> _______________________________________________ >>> info-mcl mailing list >>> info-mcl(a)clozure.com >>> http://clozure.com/mailman/listinfo/info-mcl >> >> _______________________________________________ >> info-mcl mailing list >> info-mcl(a)clozure.com >> http://clozure.com/mailman/listinfo/info-mcl > > _______________________________________________ > info-mcl mailing list > info-mcl(a)clozure.com > http://clozure.com/mailman/listinfo/info-mcl

2 3

[cffi-devel] foreign-free not freeing memory not allocated by CFFI
by Luke Crook 23 May '11

23 May '11

I received a report of an error when a function is called from lispbuilder-sdl-mixer on the Mac in both SBCL and CCL. http://pastebin.com/NmLX1Hgg I think the problem is that CFFI does not allow memory to be freed if that memory has not also been allocated using CFFI. In my code below, a new 'sdl-version' struct is returned by (sdl-mixer-cffi::linked-version). The error seems to occur when I try to free the struct at the end of the function using foreign-free. (defun linked-version () "Returns the version number of the SDL_mixer dynamic library in use as #\(`MAJOR` `MINOR` `PATCH`\)." (let ((sdl-version (sdl-mixer-cffi::linked-version)) (version nil)) (cffi:with-foreign-slots ((sdl-cffi::major sdl-cffi::minor sdl-cffi::patch) sdl-version sdl-cffi::sdl-version) (setf version (vector sdl-cffi::major sdl-cffi::minor sdl-cffi::patch))) (cffi:foreign-free sdl-version) version)) Can I get around this somehow? -Luke

3 3

[cffi-devel] HDF5 bindings
by Daniel Herring 20 May '11

20 May '11

Hi all, I've made good progress on binding the HDF5 file format library. HDF5 is an efficient, self-describing, extensible, binary file format that is popular in scientific computing, underlies NetCDF, is used by petabytes of data, is supported by tools like Matlab, ... http://www.hdfgroup.org/HDF5/whatishdf5.html My bindings are not quite ready for general consumption by the average CL user, but they should be quite usable by a CFFI programmer. The sources are here: https://gitorious.org/dh-misc/hdf5 Please read the README.txt first. As always, help would be appreciated, and the usual disclaimers of "this software may munge your data" apply. Later, Daniel

2 1

Re: [cffi-devel] Reports of CFFI's orphanage greatly exhagerated (sic)
by Luís Oliveira 16 May '11

16 May '11

In other news, I don't know how to to spell "exaggerated"... -- Luís Oliveira http://r42.eu/~luis/

1 0

[cffi-devel] Reports of CFFI's orphanage greatly exhagerated
by Luís Oliveira 16 May '11

16 May '11

Hello, A couple of people sent me emails about <http://netzhansa.blogspot.com/2011/05/orphaned-projects-on-common-lispnet.h…> which lists CFFI as an orphaned project. Turns out James Bielman's domain has expired, and now I get to regularly delete mailman moderation notices. Yay. -- Luís Oliveira http://r42.eu/~luis/

1 0

[cffi-devel] A question about memory management and garbage collection
by Nitralime 10 May '11

10 May '11

Hi folks! I have the follwoing situation: A foreign function call returns a pointer to a "table" object. This is an opaque object that can only be manipulated by the APIs provided by the foreign library. To avoid memory leaks the "table" objects should by destroyed by a call to "destroy_table" function if they are not used anymore. I have wrapped the "table" object and its corresponding API functions in a CLOS object with appropriate methods. Instances of this CLOS object will be returned by function calls on the Lisp side. The CLOS instance contains a reference to a C "table" object (allocated on C-heap by foreign library). If a caller in a Lisp program ignores the returned "table" object, it should be garbage collected as expected. My questions are now: 1) Will it be really garbage collected? 2) If the answer is in affirmative, is it garbage collected correctly (no potential memory leaks)? Please note that the C API offers as mentioned above its own dedicated function for that purpose. What would be a correct solution to avoid memory leaks in this situation? Using a finalizer seems to be a possible way to go. But I'm not sure how this can be done by just using the finalizer parameters "object" and "function" where "function" can't reliablely access "object" (cf. documentation of finalizer in "trivial-garbage" package)!! Any help and feedback is very much appreciated! Regards Nik

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel May 2011