cffi-devel

cffi-devel@common-lisp.net

1113 discussions

[cffi-devel] Take a look at my photos on Facebook
by Justin Heyes-Jones 12 Jan '10

12 Jan '10

Hi Cffi-devel, I set up a Facebook Profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Justin To join Facebook, please follow the link below: http://www.facebook.com/p.php?i=665915554&k=4Y1UX2R5QT6G6BD1WF32YWVUR6BAY54… Already have an account? Add this email address to your account http://www.facebook.com/n/?merge_accounts.php&e=cffi-devel@common-lisp.net&… was invited to join Facebook by Justin Heyes-Jones. If you do not wish to receive this type of email from Facebook in the future, please click on the link below to unsubscribe. http://www.facebook.com/o.php?k=21c7e4&u=100000643783761&mid=1b5b8aeG5af336… Facebook's offices are located at 1601 S. California Ave., Palo Alto, CA 94304.

2 1

[cffi-devel] New patches: 6-Jan-2010
by Luis Oliveira 07 Jan '10

07 Jan '10

Wed Jan 6 18:21:10 EST 2010 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-manual: navigation improvements. - Add WITH-FOREIGN-OBJECTS and WITH-FOREIGN-STRINGS to the dictionary menus. (This unfortunately seems to require specifying the @node declarations in full.) - Make the table of contents more manageable by turning @unnumberedsecs into @headings. - Fix docstring in DEFSTRUCT example. M ./doc/cffi-manual.texinfo -172 +177 Fri Jan 1 12:46:35 EST 2010 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-lispworks: add IGNORE declaration to CREATE-FOREIGN-FUNCALLABLE M ./src/cffi-lispworks.lisp +1 Fri Jan 1 12:45:29 EST 2010 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-lispworks: make null-pointer-p check its argument's type M ./src/cffi-lispworks.lisp +1 Fri Jan 1 12:34:43 EST 2010 Luis Oliveira <loliveira(a)common-lisp.net> * Documentation: add note about RT, update description of no-long-long. M ./doc/cffi-manual.texinfo -2 +16 Fri Jan 1 12:26:00 EST 2010 Luis Oliveira <loliveira(a)common-lisp.net> * Preliminary support for ABCL. M ./cffi.asd -1 +2 A ./src/cffi-abcl.lisp M ./tests/bindings.lisp -1 +1 M ./tests/defcfun.lisp -2 +3 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-100106.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] (no subject)
by Stelian Ionescu 24 Dec '09

24 Dec '09

I have (cffi:define-foreign-library sdl-glue (:windows "lispbuilder-sdl-glue.dll")) (use-foreign-library sdl-glue) On Linux, this returns fine, although it doesn't load any library. I see code in lispbuilder-sdl that relies on it signaling an error. Is it a regression ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

4 9

Re: [cffi-devel] CFFI problem in Lispworks 5.1 32-bit with :long-long emulation
by Luís Oliveira 23 Dec '09

23 Dec '09

On Wed, Dec 23, 2009 at 4:07 AM, Matt Lamari <matt.lamari(a)gmail.com> wrote: > > Sorry for the late response. > > I don't have the code/opportunity to test all the cases; but wonder if > the enclosed patch - touching all the #+lispworks-64bit, is what's > really needed. . . ? Well, could you tell me whether my previous patch works for you and why you need this one? > I.e. every 64-bit replaced with (or lispworks5.1 lispworks-64bit) > or the like > > > > > Luís Oliveira wrote: >> On Thu, Nov 19, 2009 at 5:33 PM, Matt Lamari <matt.lamari(a)gmail.com> wrote: >> >>> (defcfun test :int64) >>> >> [...] >> >>> The long-long gets through and fails in the lispworks-specific "Ecase" >>> (that has them removed for non-64-bit lispworks). >>> >> >> Long-long emulation is not implemented for DEFCFUN, DEFCALLBACK, etc. >> It turns out that Lispworks does in fact support long-long on 32-bit >> platforms for DEFCFUN at least. Please let me know if the attached >> patch works for you. >> >> > > > --- cffi-lispworks.lisp 2009-06-16 11:20:08.000000000 -0500 > +++ c:\t\cffi-lispworks.lisp 2009-12-22 22:04:10.350220400 -0600 > @@ -62,7 +62,7 @@ > > ;;;# Misfeatures > > -#-lispworks-64bit (pushnew 'no-long-long *features*) > +#-(or lispworks5.1 lispworks-64bit) (pushnew 'no-long-long *features*) > > ;;;# Symbol Case > > @@ -156,9 +156,9 @@ > (:unsigned-int '(:unsigned :int)) > (:long :long) > (:unsigned-long '(:unsigned :long)) > - #+lispworks-64bit > + #+(or lispworks5.1 lispworks-64bit) > (:long-long '(:long :long)) > - #+lispworks-64bit > + #+(or lispworks5.1 lispworks-64bit) > (:unsigned-long-long '(:unsigned :long :long)) > (:float :float) > (:double :double) > @@ -170,10 +170,10 @@ > #+#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and) '(or)) > (defun convert-foreign-typed-aref-type (cffi-type) > (ecase cffi-type > - ((:char :short :int :long #+lispworks-64bit :long-long) > + ((:char :short :int :long #+(or lispworks5.1 lispworks-64bit) :long-long) > `(signed-byte ,(* 8 (%foreign-type-size cffi-type)))) > ((:unsigned-char :unsigned-short :unsigned-int :unsigned-long > - #+lispworks-64bit :unsigned-long-long) > + #+(or lispworks5.1 lispworks-64bit) :unsigned-long-long) > `(unsigned-byte ,(* 8 (%foreign-type-size cffi-type)))) > (:float 'single-float) > (:double 'double-float))) > @@ -186,7 +186,7 @@ > > ;; Lispworks 5.0 on 64-bit platforms doesn't have [u]int64 support in > ;; FOREIGN-TYPED-AREF. That was implemented in 5.1. > -#+(and lispworks-64bit lispworks5.0) > +#+(and (or lispworks5.1 lispworks-64bit) lispworks5.0) > (defun 64-bit-type-p (type) > (member type '(:long :unsigned-long :long-long :unsigned-long-long))) > > @@ -196,7 +196,7 @@ > (define-compiler-macro %mem-ref (&whole form ptr type &optional (off 0)) > (if (constantp type) > (let ((type (eval type))) > - (if (or #+(and lispworks-64bit lispworks5.0) (64-bit-type-p type) > + (if (or #+(and (or lispworks5.1 lispworks-64bit) lispworks5.0) (64-bit-type-p type) > (eql type :pointer)) > (let ((fli-type (convert-foreign-type type)) > (ptr-form (if (eql off 0) ptr `(inc-pointer ,ptr ,off)))) > @@ -230,7 +230,7 @@ > (if (constantp type) > (once-only (val) > (let ((type (eval type))) > - (if (or #+(and lispworks-64bit lispworks5.0) (64-bit-type-p type) > + (if (or #+(and (or lispworks5.1 lispworks-64bit) lispworks5.0) (64-bit-type-p type) > (eql type :pointer)) > (let ((fli-type (convert-foreign-type type)) > (ptr-form (if (eql off 0) ptr `(inc-pointer ,ptr ,off)))) > > -- Luís Oliveira http://r42.eu/~luis/

2 1

[cffi-devel] New patches: 11-Dec-2009
by Luis Oliveira 12 Dec '09

12 Dec '09

Fri Dec 11 11:49:38 EST 2009 Stelian Ionescu <sionescu(a)cddr.org> * Update email address. M ./grovel/grovel.lisp -1 +1 Fri Dec 11 11:49:09 EST 2009 Stelian Ionescu <sionescu(a)cddr.org> * Remove spurious PRINT call. M ./grovel/asdf.lisp -1 +1 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-091211.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] plural forms for WITH-FOREIGN-POINTER and in general
by Tamas K Papp 10 Dec '09

10 Dec '09

Hi, Two suggestions: 1. Could we have a plural form of WITH-FOREIGN-POINTER (similarly to WITH-FOREIGN-OBJECTS, WITH-FOREIGN-STRINGS). 2. In my own code, I usually use something like this: (defmacro with-multiple-bindings (macro) "Define a version of `macro' with multiple arguments, given as a list. Application of `macro' will be nested. The new name is the plural of the old one (generated using format)." (let ((plural (intern (format nil "~aS" macro)))) `(defmacro ,plural (bindings &body body) ,(format nil "Multiple binding version of ~(~a~)." macro) (if bindings `(,',macro ,(car bindings) (,',plural ,(cdr bindings) ,@body)) `(progn ,@body))))) (with-multiple-bindings with-foreign-pointer) Incorporating something similar would replace the repetitions in the CFFI code, and make it easier to define plural forms. Cheers, Tamas

2 2

[cffi-devel] New patches: 25-Nov-2009
by Luis Oliveira 26 Nov '09

26 Nov '09

Tue Nov 24 18:20:02 EST 2009 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-manual: the :STRING type does not support ub8 arrays anymore M ./doc/cffi-manual.texinfo -8 +2 Tue Nov 24 18:17:41 EST 2009 Luis Oliveira <loliveira(a)common-lisp.net> * libtest: support 64-bit on OSX Leopard M ./tests/GNUmakefile -6 +8 Tue Nov 24 18:14:42 EST 2009 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-tests: show Lispworks the full path to libm.dylib M ./tests/bindings.lisp +2 Tue Nov 24 18:13:21 EST 2009 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-lispworks: turns out Lispworks does support llong on 32-bit platforms M ./src/cffi-lispworks.lisp -2 +2 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-091125.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] CFFI problem in Lispworks 5.1 32-bit with :long-long emulation
by Matt Lamari 24 Nov '09

24 Nov '09

The problem manifests itself while trying to compile the latest CL-SQLite; but can be replicated with: (defcfun test :int64) Error: :LONG-LONG fell through ECASE expression. Wanted one of (:CHAR :UNSIGNED-CHAR :SHORT :UNSIGNED-SHORT :INT :UNSIGNED-INT :LONG :UNSIGNED-LONG :FLOAT :DOUBLE :POINTER :VOID). 1 (abort) Return to level 0. 2 Return to top loop level 0. The long-long gets through and fails in the lispworks-specific "Ecase" (that has them removed for non-64-bit lispworks). It looks as though something higher up is meant to filter/emulate this. There seems to be emulation code in types.lisp The :long-long comes from the method (defmethod canonicalize ((tp emulated-llong)) :long-long) But somehow this :long-long proliferates down all the way to the lispworks-specific code. By the way, and I don't know if this is relevant; but (fli:size-of '(:long :long :int)) returns 8 in this Lispworks - I mention it only as someone on #lisp asked me to try it. How should I proceed? Thanks, Matt

2 1

[cffi-devel] GC write-protected mappings vs. the OS kernel
by Samium Gromoff 11 Nov '09

11 Nov '09

Good day, While debugging mysterious ioctl() failures in lh-usb on SBCL, I have discovered that using CFFI:WITH-POINTER-TO-VECTOR-DATA doesn't guarantee that the vector is in a writable region. Normally, with userspace code, this isn't a problem, because, as pointed on #lisp, the SEGV is handled by the lisp runtime and the user code is resumed. However this, understandably, interacts badly with kernel's expectations, which simply refuses to write to a write-protected region. That is where my discovery ended, and a discussion on #lisp ensued, including, among others, Alastair Bridgewater, James Knight and Paul Khuong. The rough consensus seemed to be (correct me if I got this wrong) that SBCL needs to provide an abstraction for the missing operation, as the chances of kernel adopting a mechanism allowing to perform syscall continuation[1] through invocation of user-provided fault handlers are pretty slim. While thinking about this I have stumbled upon: http://common-lisp.net/project/cffi/darcs/cffi/doc/shareable-vectors.txt which says: The implementation must guarantee the memory pointed to by PTR-VAR will not be moved during the dynamic contour of this operator, either by creating the vector in a static area or temporarily disabling the garbage collector. IMO, this could be extended with specification of required protections. regards, Samium Gromoff -- 1. We can't just restart the syscall, as we might be unwilling to reexecute the side-effects which happened in-kernel up to the fault point. Of course this leads us to PCLSRing.. _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

3 5

Re: [cffi-devel] memutil.lisp breaks compile
by Sebastian Tennant 08 Nov '09

08 Nov '09

Quoth Henrik Hjelte <henrik(a)evahjelte.com>: > http://www.mail-archive.com/cffi-devel@common-lisp.net/msg01656.html This link appears to be broken (404 Not Found). Was it intended to point to this conversation: http://thread.gmane.org/gmane.lisp.cffi.devel/1720 by chance? > If there is a problem compiling it is usually because a version of cffi > pretends to be uffi, and the cffi developers refuses to fix this. Opinion is divided. To name but a few: Jeff Cunningham and Hans Hübner think it should be renamed. Luís Olivera and Daniel Herring think it's best left as it is. Luís is concerned about breaking things that depend on (or at least benefit from) his kludge (no offence intended). Daniel Herring makes the point that hijacking names to provide upgarde/compatibility layers is a time-honoured tradition. In my humble opinion, hijacking names works for comprehensive drop-in replacements based on consensus amongst parties. CFFI is clearly not a comprehensive drop-in replacement for UFFI and there's clearly no consensus on the issue. I'm therefore in favour of changing the name. Can't packages that 'use' UFFI (but really use CFFI) be easily updated like so: sed -i~ 's/\<uffi\>$::\?$/cffi\1/g' *.lisp > If this is the case, you might want to remind them to fix this on their > mailing list. Cross-posted to cffi-devel. Regarding the original subject, elephant now compiles, but not when using clbuild's recompile command. $ ./clbuild clean elephant $ ./clbuild recompile elephant [...] WARNING: COMPILE-FILE warned while performing #<COMPILE-OP (:VERBOSE NIL) {10036E8E81}> on #<CL-SOURCE-FILE "memutil" {100399B3A1}>. unhandled ASDF:COMPILE-FAILED in thread #<SB-THREAD:THREAD "initial thread" RUNNING {100361EDE1}>: erred while invoking #<COMPILE-OP (:VERBOSE NIL) {10036E8E81}> on #<CL-SOURCE-FILE "memutil" {100399B3A1}> However, if I issue the command again the same warning is issued but about a different file (serializer2.lisp) so it's nothing to do with memutil.lisp per se. Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap

2 1

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