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

2013年,企业薪酬还需保密吗
by vincent.Cheng 11 Apr '13

11 Apr '13

1 0

Un mensaje solidario de Ricardo y Alejandra Darin .... .........................ref 0
by axawqpknialwkbaxo_noreply＠yahoo.com 11 Apr '13

11 Apr '13

1 0

小秘书也有春天
by Joan.Niu 11 Apr '13

11 Apr '13

1 0

Fight for superior intimate life
by Charlie Alvarado 11 Apr '13

11 Apr '13

Spend continuous nights of joy http://sedaofset.com/interest.html

1 0

[cffi-devel] cff-tests doesn't load (can't build libffi.so ?)
by Anton Vodonosov 05 Apr '13

05 Apr '13

Hello. (ql:quickload :cffi-tests) doesn't work in the latest quicklisp - 2013-03-12, cffi 0.11.0. It worked in the previous quicklisp. Best regards, - Anton

1 0

[cffi-devel] version 0.11.1 released
by Luís Oliveira 03 Apr '13

03 Apr '13

bugfix: the ABCL backend now loads the required contribs properly. bugfix: some callback bugs were fixed in the ACBL backend. (Thanks to Mark Evenson.) bugfix: the groveller was failing to regenerate its lisp files whenever a grovel- or wrapper-file was modified. -- Luís Oliveira http://r42.eu/~luis/

1 0

Re: [cffi-devel] preparing to test ABCL trunk
by Mark Evenson 03 Apr '13

03 Apr '13

On 4/2/13 10:58 PM, Luís Oliveira wrote: > On Tue, Apr 2, 2013 at 1:43 PM, Mark Evenson <evenson(a)panix.com> wrote: >> Yes, it fixes this problem. >> >> I thought I had already sent you a message confirming that this change >> should be applied: sorry if that didn't happen. > > Grabbed ABCL 1.1.1 to test before preparing a bugfix release for CFFI > but I'm seeing a bunch of failures related to callbacks. Were you > aware of these failures? Should I delay the release so we (hopefully > you!) can look at these failures? > > 29 unexpected failures: CALLBACKS.CHAR, CALLBACKS.UNSIGNED-CHAR, > CALLBACKS.SHORT, CALLBACKS.UNSIGNED-SHORT, CALLBACKS.LONG, > CALLBACKS.UNSIGNED-LONG, CALLBACKS.LONG-LONG, > CALLBACKS.UNSIGNED-LONG-LONG, CALLBACKS.POINTER, > CALLBACKS.NIL-FOR-NULL, FOREIGN-GLOBALS.NAMESPACE.1, > FOREIGN-GLOBALS.NAMESPACE.2, FOREIGN-GLOBALS.NAMESPACE.4, > MAKE-POINTER.HIGH, FOREIGN-ALLOC.1, FOREIGN-ALLOC.2, FOREIGN-ALLOC.3, > FOREIGN-ALLOC.4, FOREIGN-ALLOC.6, FOREIGN-ALLOC.8, FOREIGN-ALLOC.9, > NULL-POINTER-P.NON-POINTER.1, NULL-POINTER-P.NON-POINTER.2, > NULL-POINTER-P.NON-POINTER.3, > STRUCT-VALUES-DEFAULT.TRANSLATION.MEM-REF.1, > STRUCT-VALUES-DEFAULT.TRANSLATION.MEM-REF.2, FSBV.2, FSBV.3, FSBV.4. > I've [just submitted all that I have at the moment to address these issues][24], which isn't much. Unfortunately, last week has been a week of fever and so forth, so when I am going to be able to work on these things again is uncertain. Therefore, I would advise releasing a minor revision of CFFI with this and Stellian's work to go with Quicklisp April 2013. [24]: https://github.com/cffi/cffi/pull/24 Some of the FOREIGN-GLOBALS* tests appear to pass on some platforms and not others. Callbacks with pointers seem to just not work, for which I [posted a test case in Java][1], but got a less than clear response. When I get healthy again, I will revisit more pure-Java examples to understand exactly how JNA is supposed to be working. [1]: https://groups.google.com/forum/?fromgroups=#!topic/jna-users/qPUkrTqoesU

1 0

[cffi-devel] close-foreign-library assert
by nan 22 Mar '13

22 Mar '13

Hello again! I am working on a project which used to be completely in C++, now i am gradually moving some of it to CL. For this reason i need to work on both sides, which requires me to reload cffi bindings too often. I couldn't find anything related to this in documentation. Probably this is not an intended use case so there is no support. Which means i need to use my hammer again, restart image :) So, i started playing with load-foreign-library/close-foreign-library (probably not intended for this purpose) and whenever i call close-foreign-library with the result of load-foreign-library, i get this explosion: Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map->l_init_called' failed! Tracing this assert shows it was triggered from dlclose system call in sbcl source, and i am not entirely sure where i should report this bug. I am still on archlinux using sbcl-git package from aur. Could it be another archlinux related bug? Thanks.

2 11

[cffi-devel] "Unhandled memory fault" on any memory allocation after fork
by agile software 21 Mar '13

21 Mar '13

Hi all ! First, thank you for your great work on this library. I just use it for the first time. I write the following code to test unix fork: =============================================== (asdf:oos 'asdf:load-op :cffi) (defpackage :testfork (:use :common-lisp :cffi)) (in-package :testfork) (defcvar "errno" :int) (cffi:defcfun ("getpid" unix-getpid) :int) (cffi:defcfun ("getuid" unix-getuid) :int) (cffi:defcfun ("getgid" unix-getgid) :int) (cffi:defcfun ("fork" unix-fork) :int) (cffi:defcfun ("exit" unix-exit) :void (code :int)) (cffi:defcfun ("wait" unix-wait) :int (statloc :pointer)) (when (zerop (unix-fork)) (with-foreign-pointer-as-string (str 6 str-size :encoding :ascii) (lisp-string-to-foreign "Hello, foreign world!" str str-size)) (unix-exit 0)) (progn (format t "I'm parent, Pid=~A~%" (unix-getpid)) (format t "one child claimed!~A~%" (unix-wait (cffi:null-pointer))) ) =============================================== When I add two lines using with-foreign-pointer-as-string and lisp-string-to-foreign, my SBCL always crashes, and tell me " fatal error encountered in SBCL pid XXXX: Unhandled memory fault. " I have tried other memory allocation macros, I get the same result. But if I remove them, the program runs and exits normally. What's the problem about allocating memory in child process? Or I use them in the wrong way? My environment is : OSX 10.8.3 Processor Intel Core i7, SBCL 1.0.55.0-abb03f9, cffi_0.10.7.1 installed from quicklisp Thank you very much!

2 2

[cffi-devel] always recompile with "asdf:load-system"
by iso 20 Mar '13

20 Mar '13

Hello everyone. Since this is my first post, thanks for the great library! After updating to new version (via quicklisp) i first had issues with my grovel file. I used to be able to reference types defined outside of grovel file, now i can't. I am not sure if it was a bug or a feature but somehow it compiled before! Anyways, after modifying a few things it is now working. My real problem is whenever i load a system based on cffi, project always compiles. With or without a change in the project. This is also started happening with the new version. I suspect it might be about grovel, loaded a few projects that is based on cffi, one uses cffi-grovel (static-vectors) the other one doesn't (cl-opengl). cl-opengl compiles at first time and then loads. cffi-grovel always compiles. Thanks.

5 10