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

[cffi-devel] cstruct in groveller needs to escape %
by Greg Pfeil 07 Jan '13

07 Jan '13

This form: (cstruct %foo "foo" …) errors, as “%FOO” ends up literally in some C format string. “%” needs to be escaped as “%%”. CSTRUCT is probably not the only place it happens, but it’s where I’ve run into it.

2 1

[cffi-devel] CFFI-GROVEL ASDF integration
by Mark Cox 03 Jan '13

03 Jan '13

G'day, There is an issue with the ASDF component of CFFI-GROVEL when running on ECL. The problem stems from ASDF:OUTPUT-FILES returning two items. The attached patch hopes to handle this situation. Thanks Mark

6 23

[cffi-devel] Are github pull requests accepted?
by Juan Jose Garcia-Ripoll 24 Nov '12

24 Nov '12

I am just wondering whether this is a viable way to submit patches. I recently uploaded a couple of fixes to CFFI that enable users to completely forget about shared libraries and statically resolve symbols at compilation time -- CFFI's calls are directly translated into C ones. This is needed for platforms such as iOS that do not allow dynamically loading shared libraries. Users have reported that the feature works fine in such environments. More about this at the ECL mailing list: http://sourceforge.net/mailarchive/message.php?msg_id=30132113 and also in the comments in src/cffi-ecl.lisp Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

2 1

[cffi-devel] Possible bug reading *FOREIGN-LIBRARY-DIRECTORIES* on Windows 7
by Ralph Möritz 09 Nov '12

09 Nov '12

I've observed what appears to be a bug on Windows using CCL 1.8 & the latest CFFI version from Quicklisp (0.10.7.1). It seems *FOREIGN-LIBRARY-DIRECTORIES* is not being read correctly. I've placed `sqlite3.dll` in `C:\users\ralphm\temp\lib`. Below are the results of evaluating `(cffi:load-foreign-library '(:default "sqlite3"))` for different values of *FOREIGN-LIBRARY-DIRECTORIES*. It appears the trailing `/` is required but I haven't seen this documented in the manual - is this intended behaviour? '("c:/users/ralphm/temp/lib/") ==> #<FOREIGN-LIBRARY DEFAULT-3009 "sqlite3.dll"> '(#p"c:/users/ralphm/temp/lib/") ==> #<FOREIGN-LIBRARY DEFAULT-3009 "sqlite3.dll"> '("c:/users/ralphm/temp/lib") ==> Unable to load foreign library (DEFAULT-3009). Error opening shared library sqlite3.dll : The specified module could not be found. . '(#p"c:/users/ralphm/temp/lib") ==> Unable to load foreign library (DEFAULT-3009). Error opening shared library sqlite3.dll : The specified module could not be found. . Cheers, Ralph

2 1

[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] loading foreign libraries in a top-level form
by Anton Vodonosov 07 Nov '12

07 Nov '12

Hello. The CFFI manual says [1] that cffi:use-foreign-library is intended to be the top-level form used idiomatically to go ahead and load the library. And most developers follow this idiom. I would argue that this is inconvenient. My motivation is that cl-test-grid tests (ql:quickload) of every ASDF system in Quicklisp, and the presence of cffi:use-foreign-library as a top-level causes failures of system load if the foreign library is absent. In other words, I can not test compilation of Common Lisp code until the foreign library is provided. You may object that cl:compile-file does not execute top level forms. But by compilation I mean at least asdf:compile-op of ASDF system. ASDF systems consist often of several files which depend on each other, and in order to compile dependent files ASDF should not only compile, but also load the dependency files. For example, (asdf:operate 'asdf:compile-op :cl+ssl) fails with: Unable to load foreign library (LIBSSL). Error opening shared library libssl32.dll : %1 is not a Win32 executable . [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR] I think better idiom would be to not use top-lovel cffi:use-foreign-library, but instead have CL libraries to provide initialization routine which loads the foreign libraries. A supporting argument against top-level cffi:use-foreign-library is that as far as I know when we save an image of lisp, many lisps will not reload the foreign libraries when we load the image next time. I.e. the lisp image does not contain information about loaded libraries. Here, even with the approach with top-level cffi:use-foreign-library the CL library anyway needs to provide a routine to load the foreign library. Therefore, we could avoid the top-level cffi:use-foreign-library at all. I would like to know the opinion of CFFI developers. Do I miss anything? What are the reasons to support the top-level cffi:use-foreign-library? Best regards, - Anton [1] - http://common-lisp.net/project/cffi/manual/html_node/use_002dforeign_002dli…

3 3

[cffi-devel] SBCL-1.0.58 / CFFI crash
by Ryan Pavlik 05 Nov '12

05 Nov '12

The following crashes for me with CFFI (master) and sbcl-1.0.58 (actually as early as sbcl-1.0.57-49-gd720bc3) on amd64/x86_64: https://gist.github.com/fa8f380a218b55b4ae6a (This is a simplified case of a callback being used in cl-cairo2.) Altering some things causes it not to crash: * Not declaring P with DYNAMIC-EXTENT. * Not using STATUS_T as a return type, simply using :INT and 0. * Altering the FORMAT to a simpler version. However, I don't think any of these things are in error, and my guess is there is some corruption that happens regardless. This works without error on earlier versions of SBCL as well as CCL, but it's unclear whether something bad is happening silently. Am I doing something wrong here, or is there a bug in CFFI or SBCL? thanks, -- Ryan Pavlik <rpavlik(a)gmail.com> | https://github.com/rpav 425.220.9585

2 3

[cffi-devel] CFFI-GROVEL::%INVOKE on ECL
by Mark Cox 04 Nov '12

04 Nov '12

G'day again, The function %INVOKE in the CFFI-GROVEL package uses the function EXT:SYSTEM on ECL. EXT:SYSTEM requires streams with a file handle in order to function correctly. The attached patch ensures that this occurs. Thanks Mark

2 1

[cffi-devel] CFFI patches for ABCL
by Mark Evenson 04 Nov '12

04 Nov '12

I've [submitted a github pull request][1] for patches for running CFFI under ABCL. A little uncertain about the protocol for getting such things noticed and for the benefit of those not watching the repo, I am also mailing cffi-devel@. [1]: https://github.com/cffi/cffi/pull/14 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1