gmane.lisp.cffi.devel

New patches: 23-Jul-2008

Luis Oliveira — 2008-07-24T04:00:14

Wed Jul 23 00:47:29 EDT 2008 Stephen Compall nocandysw.com> * Expand body only once for uffi:with-cstring. M ./uffi-compat/uffi-compat.lisp -7 +7 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-080723.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

Re: [PATCH] Expand body only once for uffi:with-cstring.

Luís Oliveira — 2008-07-23T23:17:17

Pushed! Thanks.

[PATCH] Expand body only once for uffi:with-cstring.

Stephen Compall — 2008-07-23T04:54:27

Got an explosion in CLSQL-PostgreSQL with a uffi:with-cstrings expansion, as 7 strings makes 128 copies of the body. On the theory that the compiler can inline flets far easier than factor them, this patch puts the body in an flet and calls the resulting function from the two contexts `with-cstring' creates.

Re: Conflicting symbols problem on OpenMCL/CCL whenloading CFFI

Daniel Katz — 2008-07-02T11:48:47

On Jul 2, 2008, at 4:05 AM, Luís Oliveira wrote: Oops -- you're right. I had clbuild still pointing to the old repository by mistake. Sorry for the confusion and thanks for the pointer!! Dan

Re: Conflicting symbols problem on OpenMCL/CCL whenloading CFFI

Luís Oliveira — 2008-07-02T08:05:28

You don't seem to have the latest version: HTH

Conflicting symbols problem on OpenMCL/CCL whenloading CFFI

Daniel Katz — 2008-07-02T01:04:38

Hi - I just tried to load the latest CFFI from darcs into CCL 1.2, and I got a symbol conflict between CCL:COPY-FILE and ALEXANDRIA.0.DEV:COPY- FILE: When I look in the CFFI code, the problem seems to come from cffi-- openmcl.lisp where ALEXANDRIA and CCL are both being :use-d without any shadowing. As far as I can tell, there are no calls to either COPY-FILE function anywhere in the CFFI code, so it seems to me that choosing one of these functions to shadow the other should be a simple affair since it shouldn't matter at all which one is chosen.. Would it be possible to get this fixed? Thanks. Dan

Re: CFFI + Slime + std::cout

Stephen Compall — 2008-06-28T21:23:20

The following message is a courtesy copy of an article that has been posted to comp.lang.lisp as well. Sohail Somani taggedtype.net> writes: This is really a CFFI question, and you may wish to send further followups to the CFFI list instead. Create a C++ shared library with a few elements, then load and initialize it using CFFI: 1. A subclass of std::ostream that holds a void(*)(const char*) as an instance variable, forwarding all output received to that function. 2. A function like extern "C" void init_mylispcout (void (*writer) (const char*)); that replaces std::cout with an instance of #1. I forget whether C++ allows you to change std::cout. 3. A CFFI callback in Lisp to be passed to #2, that writes the output on some Lisp stream. 4. A CFFI defcfun on #2.

Re: strange behaviour of CFFI with LW on OS X

Antoine Allombert — 2008-06-25T15:42:46

Luís Oliveira a écrit : Right, it works. Thanks !

Re: strange behaviour of CFFI with LW on OS X

Luís Oliveira — 2008-06-25T15:40:43

On Wed, Jun 25, 2008 at 4:21 PM, Antoine Allombert labri.fr> wrote: [...] Right, while that was a problem with your code, it's not the main problem: MEM-REF's offset is measured in bytes. You want to use MEM-AREF instead.

Re: strange behaviour of CFFI with LW on OS X

Stelian Ionescu — 2008-06-25T15:23:58

_______________________________________________ cffi-devel mailing list cffi-devel< at >common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel

Re: strange behaviour of CFFI with LW on OS X

Antoine Allombert — 2008-06-25T15:21:24

Luís Oliveira a écrit : It gives the same result. I evaluated my form on other machines with good result but I was unable to find the difference between the systems (same LW, same cffi). That's why I am asking about the use by cffi of local libraries or files.

Re: strange behaviour of CFFI with LW on OS X

Stelian Ionescu — 2008-06-25T15:17:22

_______________________________________________ cffi-devel mailing list cffi-devel< at >common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel

Re: strange behaviour of CFFI with LW on OS X

Luís Oliveira — 2008-06-25T15:14:03

Hello, On Wed, Jun 25, 2008 at 4:09 PM, Antoine Allombert labri.fr> wrote: You've allocated 2 bytes and then referenced 2 ints (8 bytes probably). Try (with-foreign-object (ptr :int 2) ...). HTH.

strange behaviour of CFFI with LW on OS X

Antoine Allombert — 2008-06-25T15:09:26

Hello everybody, I face a weird situation with LW and CFFI on OS X 10.4. When I evaluate the form : > (cffi:with-foreign-pointer (ptr 2) (setf (cffi:mem-ref ptr :int 0) 0) (setf (cffi:mem-ref ptr :int 1) 1) (let ((i 0)) (loop for i from 0 below 2 collect (cffi:mem-ref ptr :int i)))) The result is : (256 1) The first value of the pointer has been turned from 0 to 256. I tried other similar tests using explicit "foreign-alloc" with similar results. Note that in each case, the last modified place of the pointer keeps his right value while the value of the other places of the pointer are changed. I use the correct package. So I am wondering if it could be a problem in my system. Any idea or ptoposition welcome. Regards.

Re: Re: WITH-FOREIGN-STRING allocates on heap?

Martin Simmons — 2008-06-20T15:22:24

There is an interaction with threads that Hans's C test code did not trigger. You can't expect to get 1 GB per stack for every thread!

Re: Re: WITH-FOREIGN-STRING allocates on heap?

Chun Tian (binghe — 2008-06-20T15:20:31

Hi, cffi-devel As an addition, I tested your code on LispWorks 5.1.1 (64-bit Linux Edition), seem there's no limit on stack size, though LispWorks has a default value, when it reached, I got a prompt to decide whether increase it (by 50%/300%). Some outputs when I break the run manually (and LispWorks fine, no error): [60114] #: total allocated 3,077,836,800 [60115] #: total allocated 3,077,888,000 [60116] #: total allocated 3,077,939,200 P.S. By looking at LispWorks FLI, I cannot find any option in FLI:WITH- FOREIGN-STRING. Don't know how to control a foreign string be allocated in heap or stack... --binghe

Re: WITH-FOREIGN-STRING allocates on heap?

Luis Oliveira — 2008-06-20T13:28:02

[...] Many Lisps seem to operate with much smaller stacks. Here's the test I used: (defconstant +size+ (* 50 (expt 2 10))) ; 50 KB (defun test () (labels ((ek (n) (cffi:with-foreign-pointer (p #.+size+) (loop for i below +size+ do (setf (cffi:mem-ref p :char i) 0)) (format t "[~A] ~A: total allocated ~:D~%" n p (* +size+ n)) (ek (1+ n))))) (ek 1))) (compile 'test) SBCL: ~2 MB followed by "the party is over." CCL: ~2 MB followed by a segfault. CLISP: 8 MB followed by a graceful stack overflow. Allegro: ~4 MB followed by a graceful stack overflow. (used 40 KB chunks otherwise Allegro refused to do stack allocation) This is on linux/amd64 (but I think my copy of Allegro is a 32-bit version). Hopefully my test is not (too) bogus. Since the size argument has to be known at compile-time (IIRC), maybe WITH-FOREIGN-POINTER can look at that size and decide if it should

Re: WITH-FOREIGN-STRING allocates on heap?

Hans Hübner — 2008-06-20T07:26:34

Is this really a realistic issue with modern systems? Some sampling: #include main(int argc, char *argv[]) { int size = 1; while (1) { char* s = alloca(size); memset(s, 0, size); printf("still alive - %d\n", size); size *= 10; } } netzhansa 16_> uname -a FreeBSD netzhansa.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root< at >dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 netzhansa 17_> ./alloca still alive - 1 still alive - 10 still alive - 100 still alive - 1000 still alive - 10000 still alive - 100000 still alive - 1000000 still alive - 10000000 Segmentation fault (core dumped) deng-hhueb 772_$ uname -a Linux deng-hhueb 2.6.22.2-42.asl.2.intel.fc3 #1 SMP Thu Sep 20 14:27:32 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux deng-hhueb 773_$ ./alloca still alive - 1 still alive - 10 still alive - 100 still alive - 1000 still alive - 10000 still alive - 100000 still alive - 1000000 st

Re: WITH-FOREIGN-STRING allocates on heap?

Luís Oliveira — 2008-06-20T07:13:17

I believe we were worried about big strings and the possibility of overflowing the stack. I suppose we could add an argument to WITH-FOREIGN-STRING and :STRING to force stack allocation.

WITH-FOREIGN-STRING allocates on heap?

Hans Hübner — 2008-06-20T04:21:07

Hi, is there a good reason why WITH-FOREIGN-STRING allocates the buffer on the heap instead of using WITH-FOREIGN-OBJECT, which will allocate on the stack on platforms that support it? Thanks, -Hans

Re: First usages of CFFI

Marko Tapio Manninen — 2008-06-17T21:25:45

Thanks you for help. That made a trick. I managed to create a small server that responds well with cffi and libevent now. -Marko Stephen Compall kirjoitti 17.6.2008 kello 20.07: