cffi-devel September 2011

cffi-devel@common-lisp.net

7 participants
5 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] CFFI-FSBV: libffi-type-pointer for foreign structures created when needed
by Liam Healy 15 Sep '11

15 Sep '11

For those interested, some details and progress report on the merging of FSBV into CFFI. On Saturday, I was about to commit the latest changes to the fsbv branch of CFFI, and I decided at the last minute to swap the load order of cstruct and cif in cffi-fsbv.asd. Previously, I had cif.lisp loading first, and then cstruct.lisp, but it made more sense to me to put it after, because it has to do with functions, and everything else, including cstruct.lisp, did not. Much to my surprise, I got an error, and I quickly realized why: cif defines a structure that libffi needs, and when it is defined prior to cstruct, it made an ordinary foreign structure, without the *cstruct-hooks* I had made that define a foreign structure with the libffi-type pointers. When it's defined after, it got an error because some of the slots have types, like "unsigned" that are undefined in the FSBV sense (i.e., there's no libffi-type for it). The immediate bug fix would be to just define the types. Eventually I'll do that. But the real issue is that in that design, every type has to have libffi-type information, even if there's no intent to use that structure in a call by value. In the standalone FSBV, that wasn't an issue, because there were two macros, cffi:defcstruct and fsbv:defcstruct, and presumably no one used the latter unless they were going to pass or receive the foreign structure by value. Now all structures once defined would have the libffi plumbing defined, whether they needed it or not. So I changed my approach, and in the process simplified the code a lot. Instead of making the necessary libffi-type in the defcstruct expansion, it will be made on demand only, when a foreign struct is used by, e.g. defcfun. This happens recursively, so if one structure uses another, both will be made. Once they structure is made, it is attached to the plist of the symbol for the type, so it need not be recomputed. I'm now dealing with built-in types and coming up against a problem I've struggled with before (in GSLL and Antik): how to map C types (:short, :int, etc.) into established byte sizes (:uint8, :uint16). The problem is that libffi defines the types by their size, and it's up to the user to figure out how to map the common C types to those sizes; this is a topic in C that has always confused me. I notice that CFFI has a mapping in the code at the end of src/types.lisp, but it's not easily accessible to other code, so I think if I break that out as some kind of table it will be useful to generate the appropriate pointers for libffi. Unless someone has a better way. Liam

2 1

Re: [cffi-devel] Converting foreign structures with CFFI generic functions
by Luís Oliveira 10 Sep '11

10 Sep '11

On Fri, Sep 9, 2011 at 3:47 PM, Liam Healy <lnp(a)healy.washington.dc.us> wrote: > If you could that would be great, I think you could do that much > quicker than I could. If you make your new class in the fsbv branch, > I will pull from there and continue the development of structure > definition and conversion in src/structures.lisp. I've created a pull request at github for more code-centered discussion, mostly out of curiosity to see how that works. <https://github.com/cffi/cffi/pull/2> -- Luís Oliveira http://r42.eu/~luis/

1 0

[cffi-devel] Converting foreign structures with CFFI generic functions
by Liam Healy 09 Sep '11

09 Sep '11

I'm looking for some clarification of the design and intent of some CFFI definitions. As has been mentioned in another thread, I am working on incorporating my system Foreign Structures By Value, FSBV, into CFFI. As a first step toward that integration, I have been looking at conversion of objects from CL to foreign and vice versa, with the idea of unifying the approach to include foreign structures. My goal is to be as consistent with the existing CFFI design as I can be. My understanding is that CFFI's conversion design is expressed in the generic functions translate-to-foreign, translate-from-foreign, and free-translated-object, to which applications may add methods, and the functions convert-to-foreign and convert-from-foreign to permit the user to make a conversion manually. At present there are no definitions to convert foreign structures, and I'd like to add that. I think my approach should be to add methods to translate-*-foreign and free-translated-object, or have defcstruct add the methods when it is expanded. My thought now is that I should define methods for translate-*-foreign and free-translated-object dispatching on the foreign-struct-type class. The body will call the same method with the structure name, and applications can define methods eql-specialized on the name. Does this sound like it will work correctly with CFFI as it exists now, so that I can then introduce the libffi interface for the calls to foreign functions? Thanks, Liam

8 36

[cffi-devel] Passing address of pointer
by Frank Goenninger 07 Sep '11

07 Sep '11

Hi all, I have a C struct as follows: (defcstruct MyPrivateData (notification io_object_t) (deviceInterface :pointer) ;; void pointer (deviceName CFStringRef) (locationID UInt32)) of which the deviceInterface slot is the one I'm interested in. I need to pass the address of the deviceInterface pointer to a function that sets the pointer to valid device interface struct. So... In the sample code from Apple the C function is called like this: typedef struct MyPrivateData { io_object_t notification; IOUSBDeviceInterface **deviceInterface; CFStringRef deviceName; UInt32 locationID; } MyPrivateData; IOCFPlugInInterface **plugInInterface = NULL; SInt32 score; HRESULT res; res = (*plugInInterface)->QueryInterface( plugInInterface, CFUUIDGetUUIDBytes( kIOUSBDeviceInterfaceID ), (LPVOID*) &privateDataRef->deviceInterface ); How would I translate this call into a valid CFFI equivalent ? I have so far: (let ((query-interface-ptr (foreign-slot-value plugInInterface 'IOCFPlugInInterface 'ccag.osx.iokit::QueryInterface))) (format *debug-io* "~%DEVICE-ADDED: query-interface-ptr = ~s." query-interface-ptr) (setq res (foreign-funcall-pointer query-interface-ptr () :pointer plugInInterface CFUUIDBytes (cf-uuid-get-uuid-bytes kIOUSBDeviceInterfaceID) :pointer (foreign-slot-pointer privateDataRef 'MyPrivateData 'deviceInterface))) (format *debug-io* "~%DEVICE-ADDED: deviceInterface = ~s." (foreign-slot-value privateDataRef 'MyPrivateData 'deviceInterface)) ... This code "crashes" with signal 100 as reported by AllegroCL in the call to foreign-funcall-pointer ... Any hints or advice really appreciated! TIA! Best wishes Frank

4 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel September 2011