cffi-devel April 2008

cffi-devel@common-lisp.net

12 participants
10 discussions

[cffi-devel] Merging the cffi+lotsastuff branch; new dependencies
by Luís Oliveira 17 May '08

17 May '08

Hello, I'd like to merge cffi+lotsastuff[1] with the main branch soon. People have started using that branch in several projects and that has generated unnecessary confusion. This branch includes the following new features: - efficient external-format support for foreign strings - cffi-grovel - emulated long-long types - other minor stuff The only problem is that this branch brings in 3 new dependencies: babel[2], trivial-features[3] and alexandria[4]. Is this a big problem? I hope it isn't and I'll do the merge soon unless there are any objections. [1] http://common-lisp.net/~loliveira/darcs/cffi+lotsastuff/ [2] http://www.cliki.net/trivial-features [3] http://common-lisp.net/project/babel/ [4] http://common-lisp.net/project/alexandria/ -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

7 14

[cffi-devel] how to debug CFFI:LOAD-FOREIGN-LIBRARY-ERROR
by Tamas K Papp 21 Apr '08

21 Apr '08

Hi, After recently upgrading my Cairo deb packages, I am getting this error message when tryign to load the library via CFFI: Unable to load foreign library (NIL). Error opening shared object "libcairo.so": /usr/lib/libcairo.so: undefined symbol: pixman_format_supported_destination. [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR] Restarts: 0: [RETRY] Try loading the foreign library again. 1: [USE-VALUE] Use another library instead. 2: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {AFF2349}> on #<ASDF:CL-SOURCE-FILE "cairo" {AFD70B9}>. 3: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {AFF2349}> on #<ASDF:CL-SOURCE-FILE "cairo" {AFD70B9}> as having been successful. 4: [ABORT] Return to SLIME's top level. 5: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker" {B4A26A1}>) Backtrace: 0: (CFFI::FL-ERROR "Unable to load foreign library (~A).~% ~A") 1: (CFFI::LOAD-FOREIGN-LIBRARY-PATH NIL "libcairo.so") 2: (CFFI:LOAD-FOREIGN-LIBRARY (:DEFAULT "libcairo")) Before filing a bug report, I would like to find out what this means (I am pretty clueless about shared libraries). Does it mean that someone who compiled a library made a mistake, or should I load another library with this symbol in CFFI, etc. Sorry for the dumb question, but I don't know where to start. Tamas

2 1

[cffi-devel] problem with translation to foreign types
by Tamas K Papp 21 Apr '08

21 Apr '08

Hi, I have a problem getting automatic type translation to work. In my cl-cairo2 package (http://www.cliki.net/cl-cairo2), some cairo functions expect booleans, but I want them to work with integers etc. I set up a translate-to-foreign method as described in the manual, and was using it, but recently it stopped working, in the sense that translate-to-foreign still works when called manually, but functions don't seem to call it (they did before, I changed nothing), and when trying to check with convert-to-foreign, that does not work either. I reduced my problem to a small, clean example: (require :cffi) (cffi:defctype my-double :double) (defmethod cffi:translate-to-foreign (value (type (eql 'my-double))) (coerce value 'double-float)) (cffi:translate-to-foreign 10 'my-double) ; => 10d0 (cffi:convert-to-foreign 10 'my-double) ; => 10, should be 10d0! What am I doing wrong? Thanks, Tamas PS: cl-cffi 20080217-1, sbcl 1:1.0.14.0-1.

2 3

[cffi-devel] Casting
by christopher melen 19 Apr '08

19 Apr '08

Hi, I've generated a set of CFFI bindings for FFTW (http://www.fftw.org). FFTW has its own versions of malloc and free (fftw_malloc, fftw_free). So for example, one would do (where fftw_complex is a specific FFTW type) - fftw_complex *in; in = (fftw_complex*) fftw_malloc(sizeof(fftw_complex) * N); There is a rudimentary set of SBCL bindings for FFTW which binds the above in the following way - (defun fftw-malloc-complex (size) (sb-alien:cast (fftw::|fftw_malloc| (* *sizeof-fftw-complex-in-bytes* size)) (* fftw::|fftw_complex|))) My question is: how do I cast using CFFI? Thanks, Chris __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

2 1

[cffi-devel] [SPAM] From The Desk Of Barrister Weekon Perelman,
by Barrister＠common-lisp.net 19 Apr '08

19 Apr '08

Spam detection software, running on the system "clnet", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: From The Desk Of Barrister Weekon Perelman, Weekon Legal Practitioner & Chamber. 1087 Cheang Wattana Road,Nonthanburi, Bangkok, Thailand Email:barrwilliams_smith@hotmail.com Tel:+66853351163. Dear Sir/Madam, [...] Content analysis details: (7.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 FORGED_HOTMAIL_RCVD2 hotmail.com 'From' address, but no 'Received:' 1.6 DEAR_SOMETHING BODY: Contains 'Dear (something)' 2.8 MILLION_USD BODY: Talks about millions of dollars -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.6 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+ 3.4 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+

1 0

[cffi-devel] [SPAM] From The Desk Of Barrister Weekon Perelman,
by Barrister＠common-lisp.net 19 Apr '08

19 Apr '08

1 0

[cffi-devel] New patches: 7-Apr-2008
by loliveira＠common-lisp.net 08 Apr '08

08 Apr '08

Mon Apr 7 07:11:46 EDT 2008 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-tests: Lispworks needs to have libm.so loaded M ./tests/bindings.lisp -1 +5 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-080407.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] LispWorks 5.0/5.1 and LONG-LONG support
by Chun Tian (binghe) 07 Apr '08

07 Apr '08

Hi, dear CFFI Developers Since LispWorks 5.1 has been released yesterday, I can start to talk about it. * :long-long and :unsigned-long-long support LispWorks 5.0 64-bit can already support :long-long and :unsigned-long- long, but the FLI:FOREIGN-TYPED-AREF function cannot support them, and, LispWorks 5.1 64-bit has fixed this, now FLI:FOREIGN-TYPED-AREF can support 64-bit integers. * LispWorks *features* Though LispWorks cannot use a >=version like compile feature like those in Allegro, but since LW is very stable and its version grows very slowly (0.1/year ^_^), I think we can use #+(and lispworks-64bit (not lispworks5.0)) to mean "LispWorks 64-bit version >= 5.1" I attach a simple patch, which opens the 64-bit integer support on LW 5.0 & 5.1 (64-bit). Hope it can be reviewed and merged into CFFI trunk. I'll always need these changes to compile & load IOLIB project on 64-bit LispWorks. Regards, Chun Tian (binghe)

2 15

[cffi-devel] New patches: 6-Apr-2008
by loliveira＠common-lisp.net 07 Apr '08

07 Apr '08

Sun Apr 6 19:36:31 EDT 2008 Luis Oliveira <loliveira(a)common-lisp.net> * Define FOREIGN-LIBRARY class before it's used... M ./src/libraries.lisp -5 +5 Sun Apr 6 19:33:31 EDT 2008 Luis Oliveira <loliveira(a)common-lisp.net> * Implemented simple compiler-macro for FOREIGN-ALLOC M ./src/types.lisp -8 +14 Sun Apr 6 19:28:52 EDT 2008 Luis Oliveira <loliveira(a)common-lisp.net> * Small optimization in PARSE-TYPE Don't need to check for cycles (which starts off by consing up a hash table) when not dealing with foreign-typedefs. Initial patch courtesy of Greg Pfeil. M ./src/early-types.lisp -1 +2 Sun Apr 6 19:25:33 EDT 2008 Luis Oliveira <loliveira(a)common-lisp.net> * Fix bitrot in cffi-ecl.lisp M ./src/cffi-ecl.lisp -19 +15 Sun Apr 6 18:13:10 EDT 2008 Luis Oliveira <loliveira(a)common-lisp.net> * Clozure CL chokes on the CALLBACKS.BFF.* tests, disabled them M ./tests/callbacks.lisp -6 +7 Sat Apr 5 15:54:12 EST 2008 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-clisp: add support for the upcoming 2.45 version CLISP 2.45 introduces a couple of backwards-incompatible changes to some of the unexported FFI functions we use. M ./src/cffi-clisp.lisp -16 +40 Sat Apr 5 11:28:58 EST 2008 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-tests: restore support for 32-bit lisps running on x86-64 M ./tests/Makefile -7 +10 M ./tests/bindings.lisp +1 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-080406.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] CLISP no longer supports ffi::foreign-library-function
by Barry Fishman 05 Apr '08

05 Apr '08

As of (From the CLISP src/Changelog): 2006-10-05 Sam Steingold <sds(a)podval.org> merged LOOKUP-FOREIGN-FUNCTION & FOREIGN-LIBRARY-FUNCTION into FIND-FOREIGN-FUNCTION; LOOKUP-FOREIGN-VARIABLE & FOREIGN-LIBRARY-VARIABLE into FIND-FOREIGN-VARIABLE ... This includes CVS releases starting with clisp-2.41. FFI::FOREIGN-LIBRARY-FUNCTION and FFI::FOREIGN-LIBRARY-VARIABLE have effectively been made legasy. In the current CVS head (but not the last clisp-2.44.1 release) these functions have quietly disappeared. This causes problems with the CLISP CVS head in cffi-clisp.lisp. I'm not sure what version of CLISP need to be supported. Should the new FFI::FIND-FOREIGN-FUNCTION and FFI::FIND-FOREIGN-VARIABLE interface now be used. -- Barry Fishman

2 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel April 2008