cffi-devel

cffi-devel@common-lisp.net

1113 discussions

[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

[cffi-devel] Problem with SDL_Init using CFFI with Clisp in Windows 98
by Jeremy Smith 01 Feb '06

01 Feb '06

Hi, I'm posting this to the CFFI discussion group, I previously posted it to the Lisp Application Builder list. Anyway, the L/AB people have made an SDL module that lets CFFI-supported Lisps use SDL (it's a very portable gaming library). I use Clisp exclusively, so I wanted to see SDL work properly with it, just so I can develop my application using it. At first I wrote my own SDL header module using ah2cl.lisp, but later I came across the L/AB module, and used that instead. What I'm getting to is, I read on comp.lang.lisp that the CFFI-based SDL module does not work on Windows 98 under Clisp. I just tested it on my Windows 98 laptop (P166 :-) and it says the same thing. "FFI: FOREIGN-LIBRARY-FUNCTION: No dynamic object named 'SDL_Init' in library :DEFAULT" My hack that uses FFI (not CFFI) to run SDL works fine on Windows 98, so the issue is definitely part of CFFI. I did a little bit of detective work: Clisp's top-level view shows the scope, at the time of the above error as (from src/cffi-clisp.lisp): `(funcall (load-time-value (ffi::foreign-library-function ,name (ffi::foreign-library :default) nil (ffi:parse-c-type ',ctype))) ,@fargs)))) The FFI documentation says nothing about a load-time-value, and ffi::foreign-library is not mentioned either. Strange! My best guess is that CFFI is doing something strange with CLisp's FFI that has a better alternative. This feature of FFI that the CFFI developers chose may be broken on Windows 98. For a comparison, here is my SDL header code, which does work on Windows 98: (ffi:def-call-out SDL_Init (:name "SDL_Init") (:library "sdl.dll") (:return-type ffi:int) (:arguments (flags Uint32))) Okay, I could say "it works this way, but CFFI does it another way that is broken", but I don't know the ins and outs of CFFI, and why the developers chose to use the load-time-vaue macro (or whatever it is), so I won't comment on a better way to do it. But maybe CFFI's CLisp module could use a different feature of FFI to do its run-time DLL calls. Anyway, CFFI is a great project, and I had no headaches setting it up, so I'm very pleased with it. I don't even use Windows 98 (I'm on Windows XP), but it seems best to fix things so that my application and others will run on that platform, without people cursing Lisp. Cheers, Jeremy. -- | Jeremy Smith BSc (Hons) | Chief Scientist, Decompiler Technologies | Member, British Computer Society | England

2 1

[cffi-devel] darcs patch: Add check for FreeBSD and remove some redundant assign...
by keriax＠gmail.com 01 Feb '06

01 Feb '06

Wed Feb 1 22:40:58 VLAT 2006 keriax(a)gmail.com * Add check for FreeBSD and remove some redundant assignments.

2 1

[cffi-devel] darcs patch: Add check for FreeBSD and remove some redundant assign...
by keriax＠gmail.com 01 Feb '06

01 Feb '06

Wed Feb 1 22:40:58 VLAT 2006 keriax(a)gmail.com * Add check for FreeBSD and remove some redundant assignments.

1 0

[cffi-devel] darcs patch: Added check for FreeBSD and removed some redundant code.
by keriax＠gmail.com 01 Feb '06

01 Feb '06

Wed Feb 1 21:50:45 VLAT 2006 keriax(a)gmail.com * Added check for FreeBSD and removed some redundant code.

1 0

[cffi-devel] Bitfields and defcenum
by Luís Oliveira 01 Feb '06

01 Feb '06

Hello, While building CFFI bindings for GLUT and using enums for defining bitfield masks, I came across this example: (defcenum display-mode (:rgb 0) (:rgba 0) (:index 1) (:single 0) (:double 2) (:accum 4) (:alpha 8) (:depth 16) (:stencil 32) (:multisample 128) (:stereo 256) (:luminance 512)) defcenum won't accept this because it contains duplicate values. This a misfeature introduced by myself that I forgot to fix and people have complained[1] about this before. Unless someone has any objections, I'll implement something like what CLISP has. But this makes me wonder if another abstraction, say DEFBITFIELD would be useful. Something like: (defbitfield name (0 sym1 sym2 ...) (1 sym3) (2 sym4) ...) Along with type translator on these types that would construct an integer from a list of these symbols and vice-versa. Any other suggestions before I push a patch with something like this? BTW, I silently pushed a patch that adds a new option to defcenum by allowing a base-type (when the default, :int, is not appropriate). [1] http://article.gmane.org/gmane.lisp.cffi.devel/26 -- 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

[cffi-devel] unnamed callback (closures?)
by Hoehle, Joerg-Cyril 31 Jan '06

31 Jan '06

Hi, While people certainly appreciate that CFFI provides callbacks (their current state in UFFI or Kenny Tilton's hello-c fork is unknown to me), I wonder why they apply to named functions only. In CLISP, every closure can be turned into a callback, and this is valuable since it allows to retrieve context information out of the closure. Is cffi's limitation caused by some implementations? Of course, typical C callbacks provide a void *data pointer, but I'd feel silly if I had to hide some Lisp object within such a pointer. Actually, I don't even know how to map an arbitrary Lisp object this way (it would need some awful int -> obj registration code)! The pattern I'm looking for is (defun my-application (let (x y) ...code... (register-callback 'close-window #'(lambda (data event) (return-from my-application))) (register-callback 'increase-x #'(lambda (data event) (incf x (event->value event)))) (main-loop))) Given the name limitation, I wonder whether the following work-around may be acceptable (using defcallback not at top-level). If yes, I believe the cffi manual should mention it explicitly. Otherwise, it might as well work only in N out of M implementations running cffi, and users would start to write unportable code without knowing. (defun my-callback (closure) (flet foo (defcallback ... ; problem: name is nevertheless global ;; possibly as a macro & backquotes ...))) Or (defun my-application (let (x y) (flet ((quit (data event) (return-from my-application)) (inc (data event) (incf x (event->value event)))) (defcallback close ... :body (quit date event)) (register-callback 'close-window (callback close))))) Possibly this needs a macro&backquote generator, because DEFCALLBACK registers the given name globally in a property list. Thus it disallows running multiple instances of the above. GENSYM might help, but wouldn't this be a kludge? This is quite similar to the (often undocumented) ability to use typical top-level forms in lexical contexts (e.g. the FAQ: is DEFCLASS within a function call etc. possible or not, and what happens). Many libraries don't define the semantics of their macros precisely enough. Regards, Jorg Hohle

4 3

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