cffi-devel January 2006

cffi-devel@common-lisp.net

34 participants
97 discussions

[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

[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] 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

[anaphora-devel] New patches: 30-Jan-2006
by loliveira＠common-lisp.net 31 Jan '06

31 Jan '06

Mon Jan 30 11:41:14 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Add option to defcenum New option to defcenum in order to be able a base type different from the default, :int. M ./TODO +1 M ./src/enum.lisp -4 +7 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060130.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[anaphora-devel] Reactivate Your PayPal Account
by PayPal Security Service 31 Jan '06

31 Jan '06

1 0

[anaphora-devel] Amazon - Security Service Amazon - Warning: Unauthorized Access Report (DTM975W003V34721L5KM)
by Amazon 30 Jan '06

30 Jan '06

1 0

[anaphora-devel] Update Your PayPal Account
by PayPal Customer Support 30 Jan '06

30 Jan '06

1 0

[anaphora-devel] Auto-nag: cffi link verifier failed
by root＠common-lisp.net 30 Jan '06

30 Jan '06

You are being nagged on because your project's name showed up in the nightly Checkbot run. Checkbot checks for broken links etc. This probably means that you are either pointing to a broken link or that someone is pointing to a broken link on your site. Or something else, it check's a bunch of stuff. Update your webpages or you shall be nagged again next week. To find out what's wrong with your webpages, please consult: http://common-lisp.net/checkbot/checkbot-common-lisp.net.html Any questions? You got this email but your webpage doesn't seem to be listed on the checkbot webpage? You can reach the author of this cronjob at clo-devel(a)common-lisp.net Thanks!

1 0

[anaphora-devel] Update your Account information For your Bank
by Bank of America 30 Jan '06

30 Jan '06

1 0

[anaphora-devel] Update your Account information For your Bank
by Bank of America 30 Jan '06

30 Jan '06

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel January 2006