cffi-devel

cffi-devel@common-lisp.net

1113 discussions

[cffi-devel] a thought on string encodings
by Hoehle, Joerg-Cyril 02 Jan '06

02 Jan '06

Hi, I hope encoding stuff will be the next great addition to CFFI. Here's some vague idea I once had. I got the impression that there are (at least) two types of functions: - one where the conversion depends on whatever dynamic calling context - another where the conversion is fixed, i.e. depends on the function only, not on the caller (but possibly on the library). Given CFFI's post transformers, I suspect that there's an opportunity to model both kinds of functions, i.e. - some where defcfun expands to defaults of custom:*foreign-encoding* (in CLISP speak) - some where the wrappers within defcfun impose a given encoding, e.g. ASCII, ISO-8859-1, UTF-8 or UTF16. Examples that come to mind are the GDI YouNameIt*W() functions on MS-Windows, where the strings are all UTF-16. One could use that alternatively with getenv(), which might ask for UTF-8 (or just use the default from the Lisp system). Sometimes it seems, the encoding depends on the library to which the function belongs. Just my $0.02, and I'm eager to see what kind of design you'll come up with. Regards, Jörg Höhle.

2 1

Re: [cffi-devel] Calling function expecting char**
by Hoehle, Joerg-Cyril 02 Jan '06

02 Jan '06

James Bielman wrote: >I wonder if MEM-AREF might be >better given a more generic name and documented as the default accessor >for foreign pointers. I think mem-AREF is fine, since (apropos "AREF") will find it, and it nicely fits array access. Yet I also thought MEM-REF's offset-as-bytes needs better visibility (presence in the user's mind & documentation). That's precisely why I submitted one patch to the documentation on 2005-12-23. Let's hope it will be enough and this issue will not become a FAQ or a FMB (frequently made bug). I think it's perfectly fine for MEM-REF to count in bytes. Such a low-level operator is needed. > I don't think user code will need to use the more >primitive features of MEM-REF directly very often... What about dereferencing a pointer (not as a slot in a struct)? mem-ref is the only candidate for that. BTW, thanks to Yaroslav for checking whether the documentation works. Every project needs such contributions. Regards, Jorg Hohle.

1 0

[cffi-devel] Re: [Sbcl-devel] Re: CFFI Callbacks on SBCL
by Thomas F. Burdick 01 Jan '06

01 Jan '06

On 12/31/05, Juho Snellman <jsnell(a)iki.fi> wrote: > <luismbo(a)gmail.com> wrote: > > We're not even testing if the callback moves or not. Our libtest is > > not saving the callbacks' address. > > > > Here's the a testcase, using sb-alien (sort of): > > Thanks. The problem is that the callback support assumes that > #'SB-VM::ENTER-ALIEN-CALLBACK can never move [*]. Which is no > longer true on x86 and x86-64 as of a few releases ago, since > everything is in the dynamic space by default, and will get > relocated when the core is saved [**]. Okay, that makes sense now. Any pointers to the discussion of why purify doesn't happen by default anymore on those platforms? (curious). > A workaround is to run PURIFY once before creating any callbacks. The > proper solution would be adding a level of indirection into the > generated callback wrappers. Maybe make 'SB-VM::ENTER-ALIEN-CALLBACK a > static symbol, so that it will be guaranteed to not move, and then > emit instructions to peek into its symbol-function slot. The layout of symbols is unlikely to change soon, so that will work fine. But another option would be to cater to what the trampolines do now and move the ENTER-ALIEN-CALLBACK function to static space.

2 1

[cffi-devel] Re: CFFI Callbacks on SBCL
by Luís Oliveira 01 Jan '06

01 Jan '06

I'm Cc-ing cffi-devel and sbcl-devel, since I'm sure more people will be interested in this and hopefully others will help in figuring this out. On 2005-dec-31, at 13:59, Thomas F. Burdick wrote: > I noticed in the #lisp logs that you're having problems preserving > callbacks across image saves. SBCL already goes to quite a bit of > effort to make sure this works. From C's point of view, the callbacks > will never move. But because your library is in lisp, and persists > across image saves, from its point of view, callback objects can move > at arbitrary times. Instead of storing SAPs, you should store the > alien-value object that alien-lambda returns. If you actually need > the SAP, get it only when you need it, using alien-sap. We're not even testing if the callback moves or not. Our libtest is not saving the callbacks' address. Here's the a testcase, using sb-alien (sort of): luis@nhop:/tmp$ cat sbcl-callback.lisp (use-package :sb-alien) (define-alien-routine "qsort" void (base system-area-pointer) (nmemb int) (size int) (compar system-area-pointer)) (defparameter *callback* (sb-alien::alien-lambda int ((a system-area-pointer) (b system-area-pointer)) (let ((x (sb-sys:signed-sap-ref-32 a 0)) (y (sb-sys:signed-sap-ref-32 b 0))) (cond ((> x y) 1) ((< x y) -1) (t 0))))) (defun test () (let ((array (alien-sap (make-alien (unsigned 32) 10)))) (dotimes (i 10) (setf (sb-sys:signed-sap-ref-32 array (* i 4)) (nth i '(7 2 8 9 6 1 10 3 5 4)))) (qsort array 10 4 (alien-sap *callback*)) (dotimes (i 10) (format t "~A " (sb-sys:signed-sap-ref-32 array (* i 4)))) (free-alien (sap-alien array (* (unsigned 32)))))) luis@nhop:/tmp$ sbcl --sysinit /dev/null --userinit /dev/null This is SBCL 0.9.8.3, 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. * (load "sbcl-callback.lisp") T * (test) 1 2 3 4 5 6 7 8 9 10 NIL * (sb-ext:save-lisp-and-die "test.core") [undoing binding stack and other enclosing state... done] [saving current Lisp image into /tmp/test.core: writing 1584 bytes from the read-only space at 0x01000000 writing 1368 bytes from the static space at 0x05000000 writing 22609920 bytes from the dynamic space at 0x09000000 done] luis@nhop:/tmp$ sbcl --core test.core This is SBCL 0.9.8.3, 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. * (test) debugger invoked on a SB-KERNEL::MEMORY-FAULT-ERROR: memory fault 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-KERNEL::MEMORY-FAULT-ERROR) 0] Any pointers? Well, I'm off to party. Happy new year! -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

2 1

[cffi-devel] New patches: 31-Dec-2005
by loliveira＠common-lisp.net 31 Dec '05

31 Dec '05

Sat Dec 31 00:39:59 CET 2005 James Bielman <jamesjb(a)jamesjb.com> * support Allegro CL and CLISP modern modes M ./Makefile +3 M ./TODO -3 M ./src/foreign-vars.lisp -2 +4 M ./src/functions.lisp -1 +1 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-051231.tar.gz

1 0

[cffi-devel] New patches: 30-Dec-2005
by loliveira＠common-lisp.net 31 Dec '05

31 Dec '05

Fri Dec 30 22:52:18 CET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Fix more typos in cffi-manual. M ./doc/cffi-manual.texinfo -10 +10 Fri Dec 30 13:18:46 CET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Fix foreign-free example in the documentation. M ./doc/cffi-manual.texinfo -1 +1 Fri Dec 30 09:18:18 CET 2005 James Bielman <jamesjb(a)jamesjb.com> * add scripts/ directory and release script A ./scripts/ A ./scripts/release.sh Fri Dec 30 08:43:03 CET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Fix the struct.names test and update some CLISP comments. M ./src/cffi-clisp.lisp -6 +3 M ./tests/struct.lisp -1 +2 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-051230.tar.gz

2 1

[cffi-devel] cffi-manual: foreign-free example
by Yaroslav Kavenchuk 30 Dec '05

30 Dec '05

clisp from CVS head, cffi-051229.tar.gz CFFI[11]> (foreign-alloc 32) *** - Unknown CFFI type: 32. Thanks! -- WBR, Yaroslav Kavenchuk.

2 5

[cffi-devel] CFFI/CLISP - 2 out of 101 total tests failed
by Yaroslav Kavenchuk 30 Dec '05

30 Dec '05

clisp from CVS head, cffi-051229.tar.gz [4]> (asdf:operate 'asdf:test-op :cffi-tests) Doing 101 pending tests of 101 tests total. ... Test CFFI-TESTS::FUNCALL.VARARGS.DOUBLE failed Form: (CFFI:WITH-FOREIGN-POINTER-AS-STRING (CFFI-TESTS::S 100) (SETF (CFFI:MEM-REF CFFI-TESTS::S :CHAR) 0) (CFFI:FOREIGN-FUNCALL "sprintf" :POINTER CFFI-TESTS::S :STRING "%.2f" :DOUBLE (COERCE PI 'DOUBLE-FLOAT) :VOID)) Expected value: "3.14" Actual value: #<error during printing> ... Test CFFI-TESTS::STRUCT.NAMES failed Form: (CFFI:FOREIGN-SLOT-NAMES 'CFFI-TESTS::XPTO) Expected value: (CFFI-TESTS::TV-SECS CFFI-TESTS::TV-USECS) Actual value: (CFFI-TESTS::TV-USECS CFFI-TESTS::TV-SECS). ... 2 out of 101 total tests failed: CFFI-TESTS::FUNCALL.VARARGS.DOUBLE, CFFI-TESTS::STRUCT.NAMES. Thanks! -- WBR, Yaroslav Kavenchuk.

2 1

[cffi-devel] CFFI is now ASDF-INSTALLable
by James Bielman 30 Dec '05

30 Dec '05

Hi all, I uploaded a signed tarball of today's CFFI Darcs snapshot and added the appropriate magic to CLiki to make it ASDF-INSTALLable. I will try to keep this in sync with the Darcs tree until we start making proper releases. James

1 0

[cffi-devel] CFFI/CLISP issues with saved images
by Luís Oliveira 30 Dec '05

30 Dec '05

Hello, I was just testing CFFI/CLISP by loading the testsuite, dumping an image, loading it and running the tests. CLISP crashes. There are two problems: - The foreign library (in this case libtest.so) is not being reloaded. Joerg, any suggestions regarding what we should be doing in %foreign-funcall (or %load-foreign-library?) in order to fix this? Manually reloading the library after loading the image solves the crash. I recall CLISP's ffi:def-call-out taking care of this but - The callbacks become NULL pointers, thus all callback.* tests fail. Any suggestions for fixing that? Randomly placing load-time-value forms in %defcallback didn't seem to work. :-) Happy new year! -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel