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

[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

Re: [cffi-devel] First stab at reviewing cffi-fsbv
by Liam Healy 11 Feb '12

11 Feb '12

Hi Luis, On Sun, Dec 11, 2011 at 8:36 PM, Luís Oliveira <luismbo(a)gmail.com> wrote: > Hello, > > I went through all the code and here are my review notes. (In org-mode > format.) I suggest we tackle them incrementally, not necessarily in > this order. Meanwhile, I'll be tackling the missing bits in the new > convert-into-foreign-memory. Should we be having this discussion in > cffi-devel btw? > Sure. I've copied the list for anyone who's interested. > * cffi-fsbv.asd > What happens on #-unix? > (:cffi-grovel-file "libffi" :pathname #+unix "libffi-unix") > Absolutely nothing. Someone named "CRLF0710" sent me an email claiming to have a libffi-win32 for the old standalone version of FSBV, and I wrote back saying I was interested but I've heard nothing. > * fsbv/package.lisp > 1. Regarding SIZET, I'd say we can define this type using a > keyword :SIZET. > Yes, if you think that's OK. That was me totally sneaking something in that GSLL needed that was awkward to generate there but that CFFI could generate easily. > 2. cffi-fsbv calls and hooks into so many of CFFI internals. Should > we just use the CFFI package? I mean, the code is full of ::s. > I'm fine with that. I don't think there'll be any symbol conflicts. > > * fsbv/libffi-unix.lisp > 1. OSX ships with libffi. Is (cc-flags "-I/opt/local/include/") > necessary? (I guess it doesn't hurt. Just curious. Perhaps it > didn't ship with libffi in the past?) > Ugh, OSX. It apparently does ship with libffi, except when it doesn't. There are so many ways to install system software, I just gave up. I'm all for your approach because it does simplify the code and make it match the other OSes; when the complaints come in to cffi-devel, you can answer them :-) > > 2. Aren't :uint and :ushort equivalent to: > (ctype ushort "unsigned short") > (ctype unsigned "unsigned")? > Um, I don't know? What are you advocating here? Removing something that I put in? :uint and :ushort don't ring a bell for me. > > 3. Do we really need to grovel this stuff? Grovelling requires a C > compiler which is particularly tricky on Windows. It'd be nice to > avoid that requirement if possible. Didn't see anything in here > that seemed to *require* grovelling. Did I miss something? > "Here" means libffi-unix? The constants at the end aren't necessary, but I think the rest is. In particular, FFI_DEFAULT_ABI (abi) and FFI_OK (status) are pretty critical, as is the struct ffi-type. I'm a little confused; I thought the point of cffi-grovel was to provide access to definitions in .h files, and that's what we need for ffi.h and ffi-target.h. How do you propose defining these without groveling? Just hardwiring into lisp and hoping no one ever changes those values? By the way I have FFI_STDCALL commented out and didn't try to mate it with CFFI's definition on Windows, perhaps CRLF0710 or another Windows user can figure that out. > * fsbv/build-in-type.lisp > 1. Could we use DEFCVAR here to declare the various ffi_type_* > globals? (I think it'd be slightly clearer.) > I kind of like the automatic way of doing it; manually means that every time something changes (new type added or old one removed) you have to remember to do it in two places. That's a recipe for breakage. > 2. Why do we have to cache pointers for FOREIGN-TYPE-ALIAS and > FOREIGN-ENUM? (But see my comments on fsbv/cstruct.lisp) > We probably don't. > 3. Why different LIBFFI-TYPE-POINTER for those two types? > FOREIGN-ENUM inherits from FOREIGN-TYPE-ALIAS. > Is it really different, or is it just getting the pointer from the underlying type? > * fsbv/cstruct.lisp > 1. slots-in-order should be moved near FOREIGN-STRUCT-TYPE. > 2. I think we should move libffi-type-pointer out of FOREIGN-TYPE > and centralize storage in an hash-table. > a) this simplifies implementation a little bit: it's weird that > pretty much all libffi-type-pointer methods have :AROUND > qualifiers. > b) makes it easy to avoid memory leaks when redefining/reloading > structure types. (Although this sort of leak is probably not a > huge issue, it's certainly inelegant.) > 3. The code that creates ffi_types for structs could use some > refactoring. :-) I'll give it a go. > Sure. > > * fsbv/functions.lisp > 1. I think this file can benefit from a little bit of refactoring. > 2. I *think* we can move the indirection logic from the translation > methods onto FFCALL-BODY-LIBFFI, but it's not yet clear how that > can happen. > Interesting thought, I'd like to hear your ideas. > > * fsbv/example.lisp > 1. Need to clear the dead code and move it to examples/. > examples.lisp? It's probably all dead code now, just get rid of the whole thing. > > * src/functions.lisp > 1. We can add a neat restart to *foreign-structures-by-value*. > Yes I think you mentioned this idea on the todo list. I expect the restart is "load cffi-libffi"? > > * src/structures.lisp > 1. As I've mentioned before, we should discuss how we can implement > this sort of functionality in a backwards-compatible way. > I'd prefer not defaulting to previous assumptions (that is, no translation of structures), if that's what backwards-compatible means. But I'm interested in how you'd approach this. * src/early-types.lisp > 1. missing expand-into-foreign-memory, and all the hooking up that > implies. Started working on that. > 2. I think the :indirect keyword is delegating the responsibility to > the wrong place. All the type translations (in CFFI or in other > libraries) would have to be updated accordingly! As mentioned in > the fsbv/functions.lisp notes, I think we can handle the > indirection there. (It might require a slightly different way of > hooking up ffcall-body-libffi with foreign-funcall.) > No doubt. I would like to avoid special-casing though, e.g. "here's an enum, got to indirect it". I think that kind of thing belongs in a method associated with the type. > * Nomenclature > I can forsee using libffi to deal with stuff like callbacks, long > long, varargs, etc. Should we rename cffi-fsbv to cffi-libffi? > Sure. Also, you mentioned that some implementations have their own call-by-value mechanism, so it makes more sense to rename it, since they would have "fsbv" but no libffi. > > * Wishlist > *** foreign-funcall-varargs and friends could use libffi > ... to do proper varargs. > *** defcallbacks with structures... > Yup. Liam > > -- > Luís Oliveira > http://r42.eu/~luis/ >

1 1

[cffi-devel] Unit tests failures on different lisps
by Anton Vodonosov 06 Jan '12

06 Jan '12

Hello. I am running tests of some most often downloaded CL libraries, including CFFI. So far CFFI was only tested on Linux. It has Linux, has different number (of expected and unexpected) failures on different Lisps. The results may be found here: http://common-lisp.net/project/cl-test-grid/pivot_ql-lib_lisp.html Clicking the ok/fail status refer to the test logs with the failures details. Best regards, - Anton

4 7

[cffi-devel] Linking CL to fortran-77 via cffi
by Mirko Vukovic 04 Jan '12

04 Jan '12

Hello, Several projects (lla, blapack among them) link common lisp (cl) to fortran 77 (f77)code. Unfortunately, being totally unfamiliar with cffi, I was having trouble using those packages to learn how to link cl to other f77 code. To learn more about calling f77 code from CL, I assembled a bunch of simple examples (using cygwin+clisp+gfortran).to show how to pass values of various types to f77. I have put up the examples on https://github.com/mirkov/cffi-f77. I tried to add enough documentation to make the package easily understandable. I hope this proves useful to others. I would appreciate comments regarding errors and improvements. And, as always, thanks for cffi :-) Mirko

4 5

[cffi-devel] CFFI foreign library error pathname patch
by Stelian Ionescu 18 Dec '11

18 Dec '11

Xach requested better error reporting from load-foreign-library, so please review this patch -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

4 8

[cffi-devel] Dynamically call a certain function in a lib
by Frank Goenninger 04 Dec '11

04 Dec '11

Hi, I have: (defun load-and-open-module (pathname) (let ((lib (cffi:load-foreign-library pathname))) (if lib (progn (format t "~%LOAD-AND-OPEN-MODULE: ~s LOADED." lib) (let ((handle (cffi:foreign-funcall `("open" :library ,lib) :pointer))) ;; <<--- Here's the challenge ... (if (not (eql handle (cffi:null-pointer))) (let ((module (make-instance 'pib-module :lib (c-in lib) :handle (c-in handle)))) (format t "~%LOAD-AND-OPEN-MODULE: module = ~s." module) module) nil) nil))))) The marked line should load the "open" function in the just loaded foreign lib. As I intend to load multiple so-called modules where each module has an "open" function I /think/ I need to say which open() function to call (the loaded libs are C DLLs, mostly). How do I name a certain foreign lib in the call to foreign-funcall when the library given is not evaluated ? Thanks for any hints! Cheers Frank

2 1

[cffi-devel] defcallback with &rest
by Frank Goenninger 02 Dec '11

02 Dec '11

Hi all! Question: I have a Lisp function as follows: (defun frgo (fmt &rest args) (format t fmt args)) Now I want to define a C call back for that function: (defcallback frgoc :void ((fmt :string) (args ??????? How do I define the callback such that I can have a C function with varargs being defined? Thx! Cheers Frank

2 2