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

[cffi-devel] Problem with conc-name, dumping CFFI::AGGREGATE-STRUCT-SLOT
by Andy Hefner 26 May '09

26 May '09

Compare the definitions of the structures WORKING and BROKEN: (use-package :cffi) (defcstruct foo (x :int)) (defcstruct working (y foo)) (defcstruct (broken :conc-name broken-) (y foo)) Compiling the WORKING definition works perfectly, while compiling BROKEN produces the following error in SBCL: ; caught ERROR: ; don't know how to dump #<CFFI::AGGREGATE-STRUCT-SLOT {10041256D1}> (default MAKE-LOAD-FORM method called). This appears to stem from the application of the following compiler macro (and ultimately the result of foreign-struct-slot-set-form) to the generated accessors: (define-compiler-macro foreign-slot-set (&whole form value ptr type slot-name) "Optimizer when TYPE and SLOT-NAME are constant." (if (and (constantp type) (constantp slot-name)) (foreign-struct-slot-set-form value ptr (get-slot-info (eval type) (eval slot-name))) form)) This occurs for arrays as well as structures for the slot type, but not simpler types (:int, etc).

2 1

[cffi-devel] [ELS 2009] Call for participation
by Marco Antoniotti 20 May '09

20 May '09

Apologies for multiple postings.... ************************************************************************ 2nd European Lisp Symposium (ELS 2009) Milan, Italy, May 27-29, 2009 Universita` degli Studi di Milano-Bicocca www.european-lisp-symposium.org ************************************************************************ CALL FOR PARTICIPATION ********************** REGISTRATION IS OPEN AT www.european-lisp-symposium.org. Check out the updated program. Scope and Program Highlights: ***************************** The purpose of the European Lisp Symposium is to provide a forum for the discussion of all aspects of the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2009 program includes presentations of high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives, all involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, and so on. The European Lisp Symposium will feature the following highlights: - Scott McKay of ITA Software will talk about how Lisp use has evolved in his circannual industry work. - Mark Tarver of Lambda Associates will talk about Qi as a viral mutation of the Lisp DNA. - Mauro Pezze` of University of Milan-Bicocca will host a panel on Programmers' Productivity from a Software Engineering point of view. - Joao Pavao Martins and Ernesto Morgado of SISCOG will talk about the role of LISP in the success of SISCOG - Christophe Rhodes will give an unportable tutorial. - Michele Simionato will give a tutorial on Scheme module system and Scheme libraries portability issues across implementations. Social Events: ************** Friday 29th evening, Conference Banquet Saturday 30th morning, Guided tour to the "Futurismo" Exhibit in the center of Milan; 2009 marks the 100th anniversary of the Futurism Manifesto; stretching it, the harbinger of Lisp 50 years later. Program Chair: ************** * Antonio Leitao, Technical University of Lisbon, Portugal Local Chair: ************ * Marco Antoniotti, DISCo, Universita`† Milano Bicocca, Italy Program committee: ****************** * Giuseppe Attardi, Universita` di Pisa , Italy * Pascal Costanza, Vrije Universiteit Brussel, Belgium * Irene Durand, Universite` Bordeaux 1, France * Marc Feeley, Universite` de Montreal, Canada * Ron Garret, Amalgamated Widgets Unlimited, USA * Gregor Kiczales, University of British Columbia, Canada * Scott McKay, ITA Software, Inc., USA * Peter Norvig, Google Inc., USA * Julian Padget, University of Bath, UK * Kent Pitman, HyperMeta, USA * Christian Queinnec, Universite` Pierre et Marie Curie, France * Christophe Rhodes, Goldsmiths College, University of London, UK * Robert Strandh, Universite` Bordeaux 1, France * Mark Tarver, Lambda Associates, UK * Didier Verna, EPITA Research and Development Laboratory, France * JonL White, TheGingerIceCreamFactory of Palo Alto, USA * Taiichi Yuasa, Kyoto University, Japan Registration Fees: ****************** * Students EU100, regular EU220. Registration will include the proceedings, coffee breaks, the symposium dinner and other amenities. Accommodation is not included.

1 0

[cffi-devel] Set :dlopen-flags to :global-lazy in %load-foreign-library in lispworks?
by HUANG, Jianshi 19 May '09

19 May '09

Hello, I'd like to suggest a change to %load-foreign-library in lispworks. :dlopen-flags in fli:register-module is default to :local-lazy, which means setting RTLD_LOCAL || RTLD_LAZY flag when calling dlopen. This will not allow me to open shared libraries in sequential that depends on previously loaded ones. So I suggest to set :dlopen-flags to :global-lazy as default in % load-foreign-library in cffi-lispworks.lisp. The code will look like: (defun %load-foreign-library (name path) "Load the foreign library NAME." (fli:register-module (or name path) :connection-style :immediate :real-name path + :dlopen-flags :global-lazy)) P.S. Here's the Lispworks documentation: http://www.lispworks.com/documentation/lw51/FLI/html/fli-120.htm#marker-105… Cheers, Jianshi -- ---------------------

3 5

[cffi-devel] Bus error ... ?! Help, please ...
by Frank Goenninger 11 May '09

11 May '09

Hi all: While resurrecting Kenny Tilton's Cello and trying to reuse some code of the cl-opengl bindings (trying to unite the two) I came across this error: Source: (define-foreign-library OpenGL (:darwin (:framework "OpenGL")) (:windows "opengl32.dll" :calling-convention :stdcall) (:unix (:or "libGL.so" "libGL.so.2" "libGL.so.1"))) (use-foreign-library OpenGL) (define-foreign-library GLU (:windows "glu32.dll") ((:and :unix (:not :darwin)) (:or "libGLU.so.1" "libGLU.so")) ((:not :darwin) (:default "libGLU"))) (use-foreign-library GLU) (defconstant GL_VERSION #x1f02) (defctype GLenum :unsigned-int) (defmacro defglfun ((cname lname) result-type &body body) `(progn (declaim (inline ,lname)) (defcfun (,cname ,lname :library OpenGL) ,result-type ,@body))) (defglfun ("glGetString" %glGetString) :pointer (name GLenum)) (defun gl-get-version () (let ((version-string (%glGetString GL_VERSION))) ;; <<<<---- BUS ERROR ! (break) (foreign-string-to-lisp version-string))) REPL: ; Foreign loading /System/Library/Frameworks/OpenGL.framework/OpenGL. CL-USER > (gl-get-version) Bus Error (Signal 10) Oh, btw, that happens no matter what function from OpenGL I try to call... So, something very fundamental must be wrong here. I just can't see what ... Please help! TIA!!!! Best, Frank

4 10

[cffi-devel] Static vectors suitable for FFI
by Stelian Ionescu 11 May '09

11 May '09

Attached is an implementation for SBCL. make-static-vector only allocates instances of (simple-array (unsigned-byte 8) (*)) but that can be extended to other unboxed arrays. The current sharable vector interface doesn't work very well because it doesn't allow me for instance to pin a list of vectors, but only a single vector at a time. Also, I'd prefer to avoid pinning at all given how it interferes with the GC. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

3 7

[cffi-devel] Threads and function pointers misunderstanding
by Benjamin Tovar 10 May '09

10 May '09

Hi, I am writing an application that creates a callback in lisp (cffi:defcallback callback-lisp ...), and then passes the pointer to a C library with something like (set-callback-in-c (cffi:callback callback-lisp). In C, I assign the function pointer as follows: /* global variable */ void (*callback)(void); void set_callback_in_c(void (*callback_from_lisp)(void)) { callback = callback_from_lisp; } And call (*callback)()); as needed. Now, everything works nicely, unless I use threads in C (pthreads). With threads, the first time I call (*callback)()); it segfaults, as if the pointer to the function was not valid (it does get assigned). I have no clue of what is going on, since it seems that the threads are not sharing the information to the function pointer. What I am missing here? I have tried with both Allegro and SBCL, on a Debian "testing". Thanks!

2 1

[cffi-devel] New patches: 29-Apr-2009
by Luis Oliveira 30 Apr '09

30 Apr '09

Wed Apr 29 16:25:05 EDT 2009 Stelian Ionescu <sionescu(a)common-lisp.net> * Bind *PACKAGE* in PROCESS-GROVEL-FILE. Reported by Zach Smith, patch by Nikodemus Siivola. M ./grovel/grovel.lisp -1 +2 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-090429.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] :long-long on AllegroCL on Mac OS X ???
by Frank Goenninger 29 Apr '09

29 Apr '09

Hi you CFFI gurus out there ! I am having a hard time to understand why CFFI won't accept the following definition on AllegroCL 8.1 on Mac OS X (10.5.6): (defctype magick_int64_t :long-long) ;; This goes ok (defctype MagickSizeType magick_int64_t) ;; This goes ok (defcfun "MagickGetImageSize" MagickSizeType (wand :pointer)) This last definition produces the error :LONG-LONG fell through a ECASE form. The valid cases were :CHAR, :UNSIGNED-CHAR, :SHORT, :UNSIGNED-SHORT, :INT, :UNSIGNED-INT, :LONG, :UNSIGNED-LONG, :FLOAT, :DOUBLE, :POINTER, and :VOID. [Condition of type EXCL:CASE-FAILURE] Looking into cffi/src/types.h I find that even on systems where :no- long-long is given an emulation should kick in... ... Any hints/pointers really appreciated ... Thanks!!! Best, Frank -- Frank Goenninger Cell: +49 175 4321058 E-Mail: frgo(a)me.com

3 2

[cffi-devel] ecl cffi compilation and callbacks
by Naveen Garg 19 Apr '09

19 Apr '09

I am not sure if this change has been accepted into cffi: diff -rN -u old-*cffi*/src/*cffi*-*ecl*.lisp new-*cffi*/src/*cffi*-*ecl*.lisp --- old-*cffi*/src/*cffi*-*ecl*.lisp 2008-02-02 23:17:14.000000000 +0100 +++ new-*cffi*/src/*cffi*-*ecl*.lisp 2008-02-02 23:17:14.000000000 +0100 @@ -54,6 +54,7 @@ #:with-*pointer*-to-vector-data #:%defcallback #:%callback + #:*foreign*-*symbol*-*pointer* #:%*foreign*-*symbol*-*pointer*)) http://article.gmane.org/gmane.lisp.ecl.general/3342/match=foreign+symbol+p… With this change cffi compiles on ecl, but I am having problem accessing callbacks in ecl from c. foreign-funcall works fine from within ecl... http://github.com/tinku99/ahklisp/blob?path[]=ecl&path[]=clinit.lisp&raw=tr… anyone else have this issue?

2 2

[cffi-devel] ECL 9.4.X now has support for "long long" on x86.
by Jean-Claude Beaudoin 15 Apr '09

15 Apr '09

Hello Luis, One of the main new features of ECL 9.4 is its support for C type "long long" on Intel x86. Here is a patch against CFFI 0.10.4 that gives access to this long awaited foreign type. Cheers, Jean-Claude Beaudoin

2 2