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

[cffi-devel] CFFI from git bug with :int64 struct fields?
by Alistair Gee 07 Nov '12

07 Nov '12

When using latest CFFI via clbuild2 (git:// common-lisp.net/projects/cffi/cffi.git) I encountered a problem with :int64 fields. CFFI seems to treat this field as (signed-byte 32). This is with SBCL x86-64 on Ubuntu 10.10: This is SBCL 1.0.55.1-6548750, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (require :cffi) NIL * (cffi:defcstruct foo (a :int64)) FOO * (cffi:with-foreign-object (foo 'foo) (setf (cffi:foreign-slot-value foo 'foo 'a) 123456789012345)) ; in: CFFI:WITH-FOREIGN-OBJECT (FOO 'FOO) ; (SETF (CFFI:FOREIGN-SLOT-VALUE FOO 'FOO 'A) 123456789012345) ; --> LET* MULTIPLE-VALUE-BIND LET PROGN CFFI::FOREIGN-SLOT-SET SETF LET* ; --> MULTIPLE-VALUE-BIND LET PROGN CFFI::MEM-SET CFFI-SYS:%MEM-SET LET SETF ; ==> ; (SB-KERNEL:%SET-SIGNED-SAP-REF-32 FOO 0 #:VALUE14) ; ; caught WARNING: ; Derived type of #:VALUE14 is ; (VALUES (INTEGER 123456789012345 123456789012345) &OPTIONAL), ; conflicting with its asserted type ; (SIGNED-BYTE 32). ; See also: ; The SBCL Manual, Node "Handling of Types" ; ; compilation unit finished ; caught 1 WARNING condition debugger invoked on a SIMPLE-TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {10029B97C3}>: Value of #:VALUE14 in (SB-KERNEL:%SET-SIGNED-SAP-REF-32 FOO 0 #:VALUE14) is 123456789012345, not a (SIGNED-BYTE 32). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-C::%COMPILE-TIME-TYPE-ERROR (123456789012345) (SIGNED-BYTE 32) #<unavailable argument> ((SB-KERNEL:%SET-SIGNED-SAP-REF-32 FOO 0 #:VALUE14) . #:VALUE14)) 0] 0

3 4

[cffi-devel] Git repositories for CFFI
by Liam Healy 01 Apr '12

01 Apr '12

Hi, The CFFI web page http://common-lisp.net/project/cffi/ points to the git repository http://common-lisp.net/gitweb?p=projects/cffi/cffi.git, but that is no longer the official git repository for CFFI, it is on github now. The cl.net repo is severely out of date (master looks OK, but the fsbv branch is ancient and libffi doesn't even show). The web page should point to github, and the cl.net repo should either be deleted or synced up with github. Thanks, Liam

4 4

[cffi-devel] how to treat expected failures in tests
by Anton Vodonosov 14 Mar '12

14 Mar '12

Hello. For my common lisp testing project I aggregate results of a library test suite into single value - ok/fail. I just tested ECL and have the following output from CFFI test suite: 4 out of 228 total tests failed: DEFCFUN.NOOP, CALLBACKS.BFF.1, STRING.ENCODING.UTF-16.BASIC, STRING.ENCODINGS.ALL.BASIC. No unexpected failures. What meaning do you put into the term "expected failure"? Does it mean the library is buggy, but these bugs are known? Or it means that some non-required features are absent, but the library in general OK? I am interested in both short answer - as a library author, how do you think CFFI test suite should be marked if only expected failures present - OK or FAIL? And also I am curious in this concrete example, what these 4 failures mean for CFFI on ECL? Best regards, - Anton

10 25

[cffi-devel] Patch for ABCL to dynamically load CFFI JNA requirement
by Mark Evenson 12 Mar '12

12 Mar '12

Please consider the referenced patch for inclusion in cffi-0.10.7. Comments towards improvments solicited. Improvements to ABCL CFFI implementation: o autoload the 'jna.jar' dependency if possible (requires abcl-1.1.0-dev) o initial implementation of callbacks Needs ABCL specific tests, but I can load CL+SSL with this patch. [1]: http://slack.net/~evenson/abcl/cffi/abcl-cffi-20120224a.diff Cheers, easyE -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[cffi-devel] Reviewing cffi-libffi
by Liam Healy 11 Mar '12

11 Mar '12

Luís, Since the last email, I have created a function mem-aptr that returns the pointer of an array of structures and therefore reproduces the behavior of mem-aref with the deprecated bare struct reference. I wrote documentation for this function. I've tested the new function, and I think that it does the right thing. I also renamed the branch to "libffi"; the fsbv branch is now dead. Can you review to see that it looks right? Also, please add some official tests that test this function. My next step would be to merge master into libffi to integrate the changes there since I branched off, but I'd hold off doing that until near the time that we would do the reverse (merge libffi into master) in case there are further changes in master. Are there any issues you can foresee in doing these merges? Liam On Sat, Feb 11, 2012 at 4:20 PM, Liam Healy <lhealy(a)common-lisp.net> wrote: > Luis, > > I've managed to go through this list and make all the changes that I knew > how to do and didn't require much research for me. Here is a summary of > what I have done, with the git commit to the fsbv branch: > > 9d1d5b5 Rename system to cffi-libffi, add restart to default > *foreign-structures-by-value* > 95052e5 Use hash table for libffi-type-pointer > 4b5d7fb Moved slots-in-order after foreign-struct-type, clean up > libffi-*.lisp > 953fbaf Fix conditionalization syntax in cffi-fsbv.asd > cc73a6f Add Windows grovel file > 1ff74af Eliminate package cffi-fsbv, put :sizet in keyword package > > Do these changes address your concerns? Can you test? > > Thanks, > > Liam > >

1 0

[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] Structure pointer with new structure syntax: mem-aptr
by Liam Healy 05 Mar '12

05 Mar '12

I think Martin is right, so I have implemented mem-aptr and updated the manual. Here are Ryan's examples: (cffi:defcstruct rp-struct (x :short) (y :short)) (defun test-old-ref (&optional (count 0)) (declare (notinline cffi:mem-ref cffi:mem-aref)) (cffi:with-foreign-object (ptr '(:struct rp-struct) 2) (format t "~&Old-ref style:~%ptr : ~A~%aref: ~A~%" ptr (cffi:mem-aref ptr 'rp-struct count)))) (defun test-new-ref (&optional (count 0)) (cffi:with-foreign-object (ptr '(:struct rp-struct) 2) (format t "~&New-ref style:~%ptr : ~A~%aref: ~A~%" ptr (cffi:mem-aptr ptr '(:struct rp-struct) count)))) CFFI(14): (test-old-ref) STYLE-WARNING: bare references to struct types are deprecated. Please use (:STRUCT RP-STRUCT) instead. STYLE-WARNING: bare references to struct types are deprecated. Please use (:STRUCT RP-STRUCT) instead. STYLE-WARNING: bare references to struct types are deprecated. Please use (:POINTER (:STRUCT RP-STRUCT)) instead. Old-ref style: ptr : #.(SB-SYS:INT-SAP #X7FFFF6E97FF0) aref: #.(SB-SYS:INT-SAP #X7FFFF6E97FF0) NIL CFFI(15): (test-new-ref) New-ref style: ptr : #.(SB-SYS:INT-SAP #X7FFFF6E97FF0) aref: #.(SB-SYS:INT-SAP #X7FFFF6E97FF0) NIL CFFI(16): (test-old-ref 1) STYLE-WARNING: bare references to struct types are deprecated. Please use (:STRUCT RP-STRUCT) instead. STYLE-WARNING: bare references to struct types are deprecated. Please use (:STRUCT RP-STRUCT) instead. STYLE-WARNING: bare references to struct types are deprecated. Please use (:POINTER (:STRUCT RP-STRUCT)) instead. Old-ref style: ptr : #.(SB-SYS:INT-SAP #X7FFFF6E97FF0) aref: #.(SB-SYS:INT-SAP #X7FFFF6E97FF4) NIL CFFI(17): (test-new-ref 1) New-ref style: ptr : #.(SB-SYS:INT-SAP #X7FFFF6E97FF0) aref: #.(SB-SYS:INT-SAP #X7FFFF6E97FF4) NIL This looks right to me. I made a new branch libffi; the old branch fsbv will be abandoned. Note that generation of a pointer from mem-aref for structures is only supported when using the deprecated "bare" structures form, for compatibility reasons; otherwise you should use mem-aptr. Please checkout this branch and see if it works correctly for you and looks right. I agree as Martin said the other examples are incorrectly written, so I'm not bothering with them. Head: 0fec6ff839 - Update manual to include mem-aptr Liam On Fri, Feb 24, 2012 at 7:34 AM, Martin Simmons <martin(a)lispworks.com>wrote: > To answer Ryan's point, I think there should be a different function to > get a > pointer to an element of an array, called something like mem-aptr. It > should > work for all element types, not just aggregates. > > That allows mem-aref to have "value" semantics for all types. For > aggregates, > converting to a plist is one possible way to representing it. > > -- > Martin Simmons > LispWorks Ltd > http://www.lispworks.com/ > > > >>>>> On Mon, 20 Feb 2012 12:12:44 -0500, Liam Healy said: > > > > Ryan - > > > > I am forwarding this to CFFI-devel and Martin directly (though I'm pretty > > sure he's subscribed to cffi-devel). Can you please send future messages > > to cffi-devel? I'm not sure many people read the github mailing list; > this > > issue should get wider visibility. Thanks. > > > > Liam > > > > On Mon, Feb 20, 2012 at 12:02 PM, Ryan Pavlik < > > > reply+i-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019(a)reply.github.com > > > wrote: > > > > > I'm not sure what you mean. It doesn't really matter that a pointer is > > > aggregate or not. The goal is to get at the Nth member of an > > > array-of-something. In the case of scalar C types, you're getting the > > > value; in the case of structs it's far more useful to get a pointer, > > > because you probably only want a single value out of the struct, or to > > > **put a value into the struct**. (The `setf` form works for scalars > in the > > > latter case, but not for "member-of-struct-of-index-N"... you most > likely > > > want the pointer in these cases.) > > > > > > It also occurred to me after posting that there is no difference > between > > > `(mem-aref ptr '(:pointer (:struct foo)) N)` and just simply > `(mem-aref ptr > > > :pointer N)` ... both return a pointer value as if `ptr` is a `void > > > *ptr[k]`. > > > > > > A struct of more bytes works the same way: > > > > > > ``` > > > (cffi:defcstruct my-struct > > > (x :long) > > > (y :long) > > > (x :long) > > > (t :long)) > > > > > > ... > > > > > > Old-ref style: > > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) > > > aref: #.(SB-SYS:INT-SAP #X7FFFEEFC7FD8) > > > New-ref style: > > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) > > > aref: (T 0 Y 0 X 0) > > > New-ref with :pointer style: > > > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) > > > aref: #.(SB-SYS:INT-SAP #X00000000) > > > ``` > > > > > > Note that on my system, a pointer is 8 bytes, not 4. This is why I > > > initially found the problem, when trying to access an array of points > > > defined by 2 short; each member is 4 bytes, and it was giving offsets > to > > > `sizeof(void*)`. > > > > > > --- > > > Reply to this email directly or view it on GitHub: > > > https://github.com/cffi/cffi/pull/2#issuecomment-4057418 > > > > > >

1 0