gmane.lisp.cffi.devel

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 fallback to heap allocation. CCL and Allegro do this. SBCL and CLISP don't. If we did that check ourselves we'd get more consistent behaviour across the various Lisps we support and that might reduce the likelihood of overflowing the stack with big objects, particularly strings. Also, it would be nice if SBCL and CCL could handle stack overflows without crashing.

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 still alive - 10000000 still alive - 100000000 still alive - 1000000000 still alive - 1410065408 still alive - 1215752192 zsh: 14633 segmentation fault ./alloca So, at least ~10 MB for the 32 bit FreeBSD machine, at least ~1 GB for the amd64 Linux box. Given this, I'd think that making stack allocation be the default and heap allocation an option would be beneficial. If you really don't like it, making the default a compile-time option would be better than mandating an allocation policy, I think. Let me know which way you like it. Thanks! Hans

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:

Re: First usages of CFFI

Stephen Compall — 2008-06-17T03:04:43

This is explained in tutorial format in §3.9 `Calling Lisp from C' in the official manual, and reference documentation is in §11 `Callbacks'. The official manual may be found on the website, but I strongly recommend that you use the one you should have received with CFFI. `defcenum' would be good for this. Interestingly, this arg is called "closure" in libraries that know what it hacks around. You may wish to call it that to make its nature clear to Lisp-readers. I believe this was mentioned on #lisp, but those should not be indented a full tab-stop. The communities of Lisp indenters are not nearly as divergent as with some languages, and I don't think you'll find one that would encourage that. Yes, but it's for freeing, not allocating. See §3.8 `Memory management' for some tips. Unfortunately, you can't signal ERROR here after you convert it to a real callback; see the aforementioned §3.9 for why. For generalized conditions, think of this as a game of volleyball, where the call to whatever C function calls GENERIC-HANDLER is the net.

First usages of CFFI

Marko Tapio Manninen — 2008-06-17T00:59:12

Hi, so far i have compiled some programs, that use CFFI, but now id like to create my own. As usual i counter my limits of knowledge and hope to find some answers here. I'm using libevent library (later doing same with libev), that has a simple event based server application, which i want to use from ccl / sbcl. I'll put two c functions first, and then some header information and finally some lisp code i have created. Im particularry interested getting some comments, how the work should be done. Yet there re two parts of the code, where i have stuck and they are: void evhttp_set_gencb(struct evhttp *http, void (*cb)(struct evhttp_request *, void *), void *cbarg) {} (defcfun ("evhttp_set_gencb" %evhttp-set-gencb) :void (http evhttp) ???) Actually same part occurs on evbuffer: void (*cb)(struct evbuffer *, size_t, size_t, void *); Regards, -Marko -------------------------------------------------------------------------------------------------------------------------------------- // ACTUAL APPLICATION void generic_handler(struct evhttp_request *req, void *arg) { struct evbuffer *buf; buf = evbuffer_new(); if (buf == NULL) err(1, "failed to create response buffer"); evbuffer_add_printf(buf, "Requested: %sn", evhttp_request_uri(req)); evhttp_send_reply(req, HTTP_OK, "OK", buf); } int main(int argc, char **argv) { struct evhttp *httpd; event_init(); httpd = evhttp_start("0.0.0.0", 5007); /* Set a callback for requests to "/specific". */ /* evhttp_set_cb(httpd, "/specific", another_handler, NULL); */ /* Set a callback for all other requests. */ evhttp_set_gencb(httpd, generic_handler, NULL); event_dispatch(); /* Not reached in this code as it is now. */ evhttp_free(httpd); return 0; } // SOME C CODE TO DEFINE #define HTTP_OK 200 struct evhttp; struct evhttp_request; struct evbuffer { u_char *buffer; u_char *orig_buffer; size_t misalign; size_t totallen; size_t off; void (*cb)(struct evbuffer *, size_t, size_t, void *); void *cbarg; }; struct event_base * event_init(void) {} struct evhttp * evhttp_start(const char *address, u_short port) {} void evhttp_free(struct evhttp* http) {} void evhttp_set_gencb(struct evhttp *http, void (*cb)(struct evhttp_request *, void *), void *cbarg) {} // LISP PART (cffi:define-foreign-library libevent (:darwin "libevent.dylib") (t (:default "libevent"))) (cffi:use-foreign-library libevent) (defconstant HTTP_OK 200) (defconstant HTTP_NOCONTENT 204) (defconstant HTTP_MOVEPERM 301) (defconstant HTTP_MOVETEMP 302) (defconstant HTTP_NOTMODIFIED 304) (defconstant HTTP_BADREQUEST 400) (defconstant HTTP_NOTFOUND 404) (defconstant HTTP_SERVUNAVAIL 503) (defctype size-t :unsigned-int) (defcstruct evbuffer (*buffer :unsigned-char) (*orig_buffer :unsigned-char) (misalign size-t) (totallen size-t) (off size-t) (*cb :pointer) ; struct? (*cbarg :pointer)) (defcstruct event-base) (defcstruct evhttp-request) (defcstruct evhttp) (defcfun ("evbuffer_new" %evbuffer-new) :pointer) (defcfun ("evbuffer_add_printf" %evbuffer-add-printf) :void (buf evbuffer) (msg :string) (uri :string)) (defcfun ("evhttp_request_uri" %evhttp-request-uri) :string (req evhttp-request)) (defcfun ("evhttp_send_reply" %evhttp-send-reply) :void (req evhttp-request) (flag :int) (msg :string) (buf evbuffer)) ;;; unwind-protect to create evbuffer-new? (defun generic-handler (req &optional (arg nil)) (let ((buf (%evbuffer-new))) (if (null buf) (error "Failed to create response buffer") (progn (%evbuffer-add-printf buf "Requested: %sn" (%evhttp-request-uri req)) (%evhttp-send-reply req HTTP_OK "OK" buf))))) (defcfun ("event_init" %event-init) :event-base) (defcfun ("evhttp_start" %evhttp-start) :evhttp (address :char) (port :unsigned-short)) (defcfun ("evhttp_set_gencb" %evhttp-set-gencb) :void (http evhttp) ???) (defcfun ("event_dispatch" %event-dispatch) :int) (defcfun ("evhttp_free" %evhttp-free) :void (http evhttp)) ;;; MAIN SERVER START UP FUNCTION ;(server "0.0.0.0" 5009) (defun server (host port) (%event-init) (let ((httpd %evhttp-start host port) (%evhttp-set-gencb httpd #'generic-handler nil) (%event-dispatch) (%evhttp-free httpd))))

New patches: 15-Jun-2008

Luis Oliveira — 2008-06-16T04:00:28

Sun Jun 15 20:06:10 EDT 2008 Luis Oliveira common-lisp.net> * tests/Makefile: deal with BSD systems properly Suggestion and initial patch courtesy of Josh Elsasser. ./tests/Makefile -> ./tests/GNUmakefile M ./cffi-tests.asd -4 +3 M ./tests/GNUmakefile -1 +1 A ./tests/Makefile An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-080615.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary