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

Re: [cffi-devel] Crashes on X86-64 CLISP
by Hoehle, Joerg-Cyril 03 Feb '06

03 Feb '06

James, >I don't know if anyone has tested CFFI on an X86-64 CLISP, but the >following tests crash with an unexpected segfault: I'm in the process of modifying the ffcall/FFI, but so far I've only planned to modify long-long support. I'm not aware of anything else not yet in the bugtracker. Do you have access to an -64 machine or was that a user report? > STRUCT.ALIGNMENT.1 This is quite surprising, since it dereferences a single byte. There should be no problems with alignment with byte-oriented access. Does this machine pass the clisp testsuite (ffi.tst)? >so far I haven't found anything yet. What if you run the stepper in interpreted mode? Does the crash happen exactly within a call to ffi:MEMORY-AS or elsewhere? This test doesn't seem to do anything else. Does it actually invoke (ffi:memory-as address 'ffi:uint8 0) Or (ffi:memory-as address 'character 0)? What if you call (ffi:memory-as (address-of *the-s-s-ch*) 'ffi:uint8/char/...) directly? Regards, Jorg Hohle.

2 1

[cffi-devel] New patches: 2-Feb-2006
by loliveira＠common-lisp.net 03 Feb '06

03 Feb '06

Thu Feb 2 19:30:09 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Remove documentation string from test type. M ./tests/misc-types.lisp -2 +2 Thu Feb 2 19:12:13 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Add ERRORP keyword argument to FOREIGN-ENUM-VALUE / FOREIGN-ENUM-KEYWORD. - If ERRORP is false, converting nonexistent enum values and keywords will return NIL instead of signalling an error. M ./src/enum.lisp -10 +12 Thu Feb 2 18:41:28 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Add an optimization for defining non-translatable types. - New generic function on types: TRANSLATE-P. This is true for all types except built-in foreign types and typedefs defined non-translatable. - Incompatible change: DEFCTYPE now accepts keyword arguments :TRANSLATE-P and :DOCUMENTATION instead of an optional docstring. - Define the standard integers types as non-translatable. M ./src/early-types.lisp -1 +18 M ./src/functions.lisp -3 +3 M ./src/types.lisp -25 +25 Thu Feb 2 06:49:08 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Evaluate define-foreign-librare earlier for CMUCL Since we're wrapping use-foreign-library with an eval-when to load foreign library at compile-time, we need to do the samething with define-foreign-library otherwise use-foreign-library will try to load an undefined library. M ./src/libraries.lisp -1 +1 Thu Feb 2 06:47:53 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Implement defbitfield - New macros and functions: DEFBITFIELD, FOREIGN-BITFIELD-VALUE, FOREIGN-BITFIELD-SYMBOLS. M ./TODO +2 M ./src/enum.lisp -9 +87 M ./src/package.lisp +3 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060202.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] Crashes on X86-64 CLISP
by James Bielman 03 Feb '06

03 Feb '06

Hi, I don't know if anyone has tested CFFI on an X86-64 CLISP, but the following tests crash with an unexpected segfault: DEREF.ARRAY-OF-AGGREGATES STRUCT.ALIGNMENT.1 STRUCT.ALIGNMENT.2 STRUCT.ALIGNMENT.3 STRUCT.ALIGNMENT.4 STRUCT.ALIGNMENT.5 STRUCT.ALIGNMENT.6 STRUCT.ALIGNMENT.7 STRUCT.NESTED-SETF I'll see if I can figure out what's going on here, but so far I haven't found anything yet. James

1 0

Re: [cffi-devel] must cffi-sys::with-pointer-to-vector-data go?
by Hoehle, Joerg-Cyril 02 Feb '06

02 Feb '06

Hi, there's an IMHO compelling reason why with-pointer-to-vector-data CANNOT be implemented using copying. As a result, the shareable vector API must be provided as a strictly optional, API on implementations that support it. The API's service would then merely be unification of various vendor APIs, a valuable goal for CFFI. The reason is as follows: Sharing produces problems similar to those of multiprocessor machines with separate caches. AFAIK, the 68060 processor can sniff the bus while "idle" and invalidate (or possibly reload) its cache. CFFI cannot do this. Trying to copy in one or the other direction does not implement sharing. It instead implements "with exclusive access from Lisp (resp. foreign) side within the scope of the body" -- depending on the direction of the copying. Here's a testcase. Try to imagine the following within the body of a macro that surrounds it with copying the block in one direction or the other. (setq/defparameter shared-array (make-shareable-byte-vector 2000)) (fill shared-array 2) (with-pointer-to-vector-data (ptr shared-array) (loop for i below (length shared-array) when (oddp i) do (setf (aref shared-array i) (mod i 256)) else do (setf (mem-aref ptr :ubyte i) 17))) ;2nd loop to verify result on shared-array not shown, but trivial. So what's the feature's name? #+cffi-feature:shareable-vector #+cffi-feature:shared-vector Regards, Jorg Hohle.

2 1

[cffi-devel] anaphora-devel vs cffi-devel confusion
by Nikodemus Siivola 02 Feb '06

02 Feb '06

There seems to be some sort of confusion with the cffi and anaphora mailing lists: I get the cffi emails with a subject line starting "[anaphora-devel]", and I'm also getting subscription notifications for cffi-devel as if they were for anaphora-devel. (I'm subscribed to cffi-devel, but definitely not the list owner, or even admin.) Is anyone else seeing this? Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."

2 1

[cffi-devel] New patches: 1-Feb-2006
by loliveira＠common-lisp.net 02 Feb '06

02 Feb '06

Wed Feb 1 21:57:29 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Fix allegro's %load-foreign-library Versions prior to 7.0 don't have a :foreign keyword argument for LOAD. Reported by Andrew Philpot. M ./src/cffi-allegro.lisp -1 +2 Wed Feb 1 13:17:12 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Make defcenum accept duplicate values. DEFCENUM will discard the previous value->keyword mapping (though not the respective keyword->value mapping of course) when it find a duplicate value. M ./src/enum.lisp -4 +5 Wed Feb 1 06:40:58 CST 2006 keriax(a)gmail.com * Add check for FreeBSD and remove some redundant assignments. M ./tests/Makefile -18 +9 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060201.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] %LOAD-FOREIGN-LIBRARY and keyword :FOREIGN
by Andrew Philpot 02 Feb '06

02 Feb '06

<in cffi-allegro.lisp> In Allegro 6.2 (and presumably all earlier versions), the keyword argument :FOREIGN to function LOAD is not defined. So perhaps you want something more like: (defun %load-foreign-library (name) "Load the foreign library NAME." ;; ACL 8.0 honors the :FOREIGN option and always tries to foreign load ;; the argument. However, previous versions do not and will only ;; foreign load the argument if its type is a member of the ;; EXCL::*LOAD-FOREIGN-TYPES* list. Therefore, we bind that special ;; to a list containing whatever type NAME has. (let ((excl::*load-foreign-types* (list (pathname-type (parse-namestring name))))) (ignore-errors (load name #+(and allegro-version>= (version>= 7 0)) :foreign #+(and allegro-version>= (version>= 7 0)) t)))) Andrew

2 1

[anaphora-devel] Python embedded API and passing arrays with CFFI
by Jeremy Smith 01 Feb '06

01 Feb '06

Hi folks, I'm trying to interface Python to Lisp using the official embedded API. One aspect of this is that you can setup callback functions to pass data from Python to Lisp. Here's an example of a module (defined in C) containing such functions, mapping a Python function name to the pointer: static PyMethodDef ZZMethods[] = { {"copy_webpage",emb_copy_webpage,METH_VARARGS, "copy_webpage"}, {NULL, NULL, 0, NULL}}; This structure is passed to Python with this command: Py_InitModule("ltzz", ZZMethods); It is an array of this structure: struct PyMethodDef { char *ml_name; PyCFunction ml_meth; int ml_flags; char *ml_doc; }; typedef struct PyMethodDef PyMethodDef; Enclosed is the Lisp code that is my attempt at expressing this structure, but when I try and run the function testlispy, it crashes out with this message: [6]> (testlispy) If you can see this, Python is loaded and working #<FOREIGN-ADDRESS #x0022B030> #<FOREIGN-ADDRESS #x0022B030> #<FOREIGN-ADDRESS #x0022B040> #<FOREIGN-ADDRESS #x0022B050> C:\Python22\Lib\types.py:52: Warning: 'yield' will become a reserved keyword in the future warning: Python C API version mismatch for module Methods: This Python has API version 1011, module Methods has version 1003. *** - handle_fault error2 ! address = 0x1 not in [0x19d70000,0x19ed27e8) ! SIGSEGV cannot be cured. Fault address = 0x1. Permanently allocated: 92032 bytes. Currently in use: 2346812 bytes. Free space: 426556 bytes. Am I on the right lines, and if not, where have I gone wrong? I think I've misunderstood the documentation regarding arrays of structures, but because Clisp has no proper debugging environment, the only way to test it out is to make a DLL and pass it a structure. Therefore, it's easier to post to cffi-devel. By the way, this project is for the Lisp community to use Python library code in their Lisp programs, which would be useful to me at least, so I'm not asking for help with a commercial project. Thanks for any help, Jeremy. -- | Jeremy Smith BSc (Hons) | Chief Scientist, Decompiler Technologies | Member, British Computer Society | England

2 2

AW: [cffi-devel] Bitfields and defcenum
by Hoehle, Joerg-Cyril 01 Feb '06

01 Feb '06

>But this makes me wonder if another abstraction, say DEFBITFIELD >would be useful. Something like: The more expressive, the better IMHO. >(defbitfield name > (0 sym1 sym2 ...) Never thought about it. But who says bitfields will soon say "arbitrary width". Not everything is a single bit. Regards, Jörg Höhle.

2 1

[cffi-devel] Re: unnamed callback (closures?)
by Hoehle, Joerg-Cyril 01 Feb '06

01 Feb '06

Jan Rychter wrote: >> What are the problems with unnamed callbacks? My guess was that they >> will never get garbage-collected, but how about storing all >of these in >> a table somewhere and explicitly freeing them after they are >no longer >> needed? In my case I do have a way of finding out when a >callback is no >> longer needed, and I suspect this is the case for many other >> applications. Martin Simmons wrote: >The function evas_object_event_callback_add already makes a >closure -- on the C side. Good observation. So maybe, if CFFI will not provide an unnamed callback API via #+cffi-features:xyz, maybe it could encapsulate this into a pattern and provide that? The pattern is that many callbacks (AFAIK, all GUI callbacks), provide some void* data thing that can be used as an indexing scheme as Martin Simmons from Lispworks describes (coincidentally IIRC, Allegro's documentation also mentions indices somewhere, and if you dig into CLISP, you'll find some to :) That could be put to use, together with a CFFI API for freeing the indices & callbacks. The one true callback would be a CFFI-internal one, named, which dispatches to registered closures. In fact one would need a family of such named callbacks, presumably one per function signature (e.g. cb(void*data,int,xyz*) etc. -- Uh oh. So there's maybe a need for a callback generator (macro writing macro). But possibly only one per GUI toolkit :-) Beside that, cffi-features:no-lambda-callback might be an independent API to add (together with a means to free them, if provided). I'd expect more than half of Lisps to have unnamed callbacks. In the long run, with dozens of optional interfaces, CFFI code will look like C preprocessor code, with all those #+ #-cffi-feature:foobar... BTW, I just realize that ANSI-CL got it right, and CFFI got it wrong IMHO: the keyword package is named #:keyword, not KEYWORDS. Because you refer to a single one each time. Regards, Jörg Höhle.

1 0