cffi-devel

cffi-devel@common-lisp.net

1113 discussions

Re: [cffi-devel] Optimizing type translators
by Hoehle, Joerg-Cyril 13 Feb '06

13 Feb '06

Luís Oliveira wrote: >So, the idea came up of providing some sort of compiler-macro-like >facility for type translators. I'm happy to see that progress is being made here, although I currently have no time to look at it and give feedback. >As I said, I'm trying to keep this simple, so the way this works now is >that one of these translators completely hijacks the normal >translators. Namely, it wouldn't follow the typedef chain and apply all >translators (what would it use the run-time ones? the >macroexpanion-time ones? I had the feeling that ther was a slight error in the old transformers: the transform-*-FORM should have defaulted to the run-time call to convert-*, but the default was the identity function. The idea is: if there's a compile-time (actually, macro-expand time) optimization, do it; otherwise call run-time converters. >foreign-slot-value (or mem-ref/mem-aref). Would it be a good >idea to use >these translators in the respective compiler macros? The mechanism should be general: if the type is known, handle it. I think that James' :translate-p is the wrong direction, at least, my understanding of it. Who's going to use it? With all theses current dreams about automatic translation via swig, cparse, xyz, are they going to set that flag or not? Can the automated translators actually decide whether to set that flag? Regards, Jörg Höhle.

1 0

[cffi-devel] Optimizing type translators
by Luís Oliveira 12 Feb '06

12 Feb '06

Hello, So, the idea came up of providing some sort of compiler-macro-like facility for type translators. James suggested the interface should look like the run-time translators so here's what I have. (I'm trying to keep it simple). Generic Functions: (macroexpand-type-to-foreign value-form var body type) (macroexpand-type-from-foreign value type) (macroexpand-to-foreign value-form var body type) (macroexpand-from-foreign value-form type) A few questions: - maybe expand-* instead of macroexpand-*? - *-to-foreign, as you can see is the equivalent to the previous :to-c-dynamic translation. Would we want to provide the equivalent of :to-c too? (defmethod macroexpand-to-foreign (value var body (type (eql 'coerce-to-double))) `(let (,var (double ,value)) ,@body)) vs. (defmethod macroexpand-to-foreign (value (type (eql 'coerce-to-double))) `(double ,value)) And then then the dynamic extent version would be called what? (macro)expand-dynamically-to-foreign? As I said, I'm trying to keep this simple, so the way this works now is that one of these translators completely hijacks the normal translators. Namely, it wouldn't follow the typedef chain and apply all translators (what would it use the run-time ones? the macroexpanion-time ones? Also this would make it a bit harder to determine whether a given type has a translator. Right now, what I do is call macroexpansion-{to,from}-foreign and one of the default methods will return 'no-expansion if no method was specialized on the type.) One final question. We can guarantee that these are used in defcfun, foreign-funcall, defcallback. However, we can't make such guarantees for foreign-slot-value (or mem-ref/mem-aref). Would it be a good idea to use these translators in the respective compiler macros? I'm inclined to say yes. Any comments? -- Luís Oliveira luismbo (@) gmail (.) com Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

1 2

[cffi-devel] Python callback figured out and working
by Jeremy Smith 11 Feb '06

11 Feb '06

Hi, I posted here asking for some help with macros. I also posted to comp.lang.lisp and got a nice reply from Pascal B., so I have it all working now and don't need any further help. CFFI-Devel would probably have been helpful, but I know the moderation is slow sometimes. Cheers, Jeremy.

1 0

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

11 Feb '06

Fri Feb 10 18:31:23 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Push CFFI-FEATURES:X86-64 on Allegro/amd64. M ./src/cffi-allegro.lisp +1 Fri Feb 10 16:00:55 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Removed outdated comment from the colorize script. M ./doc/colorize-lisp-examples.lisp -2 +1 Fri Feb 10 13:52:48 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Use slanted instead of italic for VAR in style.css M ./doc/style.css -1 +1 Fri Feb 10 10:05:07 CST 2006 Stephen Compall <scompall(a)nocandysw.com> * use lispcmt for code comments instead of @r - Add ROMANCOMMENTS option to manual. - Change all instances of @r to @lispcmt. M ./doc/cffi-manual.texinfo -47 +55 Thu Feb 9 21:50:38 CST 2006 Stephen Compall <scompall(a)nocandysw.com> * make Texinfo @r and colorize play nice - Comment out master menu entry for explain-foreign-slot-value so manual builds again. - Add @r to all Lisp comments in manual. - (Tutorial-easy_setopt): Revert previous @dots{}; it is literal `...', not an ellipsis. Oops. - In colorize-lisp-examples.lisp, remove the output generated by @r from Lisp blocks. Also shove around the process-file code some. M ./doc/cffi-manual.texinfo -51 +50 M ./doc/colorize-lisp-examples.lisp -33 +60 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060210.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

Re: [cffi-devel] New patches: 3-Feb-2006: x86-64
by Hoehle, Joerg-Cyril 10 Feb '06

10 Feb '06

James Bielman wrote: >> Could you please confirm my supposition that long-long works out of >> the box with clisp on your amd64 machine? >How would I go about testing this? I don't see a LONG-LONG type in >the FFI package (or do I need a CVS version? I'm using the latest >release). Map cffi:long-long to ffi:sint64 and ffi:uint64. I have not added an ffi:long-long type. Not ideal, but good enough. I've now updated CVS CLISP to support interfacing to a 64bit "long long" entity on all platforms where some 64bit type is available (e.g. gcc, MS-VC). In other words, cffi-features:no-long-long should be removed from cffi-clisp (or you may wish to conditionalize on the version number or whatever, but that's too restrictive since e.g. I'm convinced that ffi:uint64 has always worked on 64bit machines, where long=long long)). Please test & report if it fails. Furthermore, I think you need to think about what CFFI should do e.g. on the MS-VC platform. It does not have a "long long", it's called __int64 instead. But this is a 64bit type (and possibly some system structures or libraries use that, I don't know). CLISP's ffi:uint64 works with __int64. Actually, given my tests, I'd not recommend trying to call MS-VC __int64 receiving or returning functions via gcc long long or vice-versa. They may have incompatible calling conventions (speculation, but MS-VC6 has a different one from GCC4 on Linux/i686. I haven't tested cygwin/mingw). Pointers to such 64bit ints are no problem at all. Regards, Jorg Hohle.

2 1

[cffi-devel] make Texinfo @r and colorize play nice
by Stephen Compall 10 Feb '06

10 Feb '06

http://csserver.evansville.edu/~sc87/cffi/atr-and-colorize.darcs.patch Thu Feb 9 21:50:38 CST 2006 Stephen Compall <scompall(a)nocandysw.com> * make Texinfo @r and colorize play nice - Comment out master menu entry for explain-foreign-slot-value so manual builds again. - Add @r to all Lisp comments in manual. - (Tutorial-easy_setopt): Revert previous @dots{}; it is literal `...', not an ellipsis. Oops. - In colorize-lisp-examples.lisp, remove the output generated by @r from Lisp blocks. Also shove around the process-file code some. -- Stephen Compall http://scompall.nocandysw.com/blog

2 3

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

10 Feb '06

Thu Feb 9 20:11:17 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Remove @r{} in manual's code comments (at least until the colorize script can cope with these) M ./doc/cffi-manual.texinfo -2 +2 Thu Feb 9 18:57:07 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * More minor doc changes. - @emph -> @var. - change var's style to something more sensible in the CSS file. - remove (setf callback) from the docs. - fix some typos. M ./doc/cffi-manual.texinfo -104 +102 M ./doc/style.css -1 +2 Thu Feb 9 18:36:50 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Make :boolean accept typedefs to integer types. M ./src/types.lisp -1 +1 Thu Feb 9 16:51:09 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Minor documentation changes - Have the Makefile's clean target delete some more of the temporary texinfo files. - Comment out reference to explain-foreign-slot-value. M ./doc/Makefile -2 +2 M ./doc/cffi-manual.texinfo -1 +1 Thu Feb 9 12:39:38 CST 2006 Stephen Compall <scompall(a)nocandysw.com> * reference prose in Pointers and Strings manual chapters - (Tutorial-easy_setopt): Use @dots{}. - (seealso): Remove old comment about @code formatting. - Pointers chapter: Describe the theory of foreign data, dealing with pointers per se, and expand on the allocation description. - (Strings): A short paragraph by way of introduction. M ./doc/cffi-manual.texinfo -10 +56 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060209.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] short patch to Pointers and Strings chapters
by Stephen Compall 09 Feb '06

09 Feb '06

http://csserver.evansville.edu/~sc87/cffi/cffi-manual-4s11.darcs.patch Thu Feb 9 12:39:38 CST 2006 Stephen Compall <scompall(a)nocandysw.com> * reference prose in Pointers and Strings manual chapters - (Tutorial-easy_setopt): Use @dots{}. - (seealso): Remove old comment about @code formatting. - Pointers chapter: Describe the theory of foreign data, dealing with pointers per se, and expand on the allocation description. - (Strings): A short paragraph by way of introduction. -- Stephen Compall http://scompall.nocandysw.com/blog

2 1

Re: [cffi-devel] Problem with SDL_Init using CFFI with Clisp in W indows 98
by Hoehle, Joerg-Cyril 09 Feb '06

09 Feb '06

Hi, Jeremy Smith wrote: >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" I've a different opinion from James :) The one difference I see is that your CLISP code explicitly mentions the library to look after. That is the most portable way and the way I recommend, even for UNIX. It's precise, and you won't get hit by name clashes (e.g. Yaroslav Kavenchuk found duplicate sprintf across MS-Windows .dlls, one crashes, the other not... Which one you get depends on the order in which the system opened libraries, AFAIK it's not even controlled by CLISP.) CFFI does not provide such a mechanism. There has been some recent work in that area, e.g. define-foreign-library and use-foreign-library. But it still seems (or my darcs copy is too old) that CFFI is not at the point where it can say for each function, or at the top of a file defining functions, "this/these belong/s to library XYZ". Please correct me if I'm wrong and this is antinews. W.r.t. CLISP: o In MS-Windows >98, constantly using :library :default should work (clisp will scan all open libraries, you bet this takes time). o On Linux, CLISP was patched last year to make :library :default so that it would scan all libraries (to help people (e.g. CFFI users) *and* to work around bugs in other software, e.g. incomplete library dependencies). o Doesn't Frank Buss got a patch to make MS-Windows-98 work (I lost track of it)? However, if MS-Windows-98 does not have means to inspect dlls for symbols (e.g. psapi.dll), then I don't see how this can be patched. You can try to find a psapi.dll for MS-windows98?? You could only modify CFFI to emit a (:library *my-library*) into the code from defcfun and the above mentioned cffi:use-foreign-library to set that variable. IMHO, the problem is with CFFI, not CLISP. Lispworks would also benefit from using module names. My bet/hope is that this is just a matter of time and volunteers to write code, and CFFI will behave nicely :-) Modules and the like have already been discussed in this list, here and there. But we need people like you to complain to make discussions progress to real code! Regards, Jorg Hohle.

5 5

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

08 Feb '06

rif (Raymund IIRC?) [rif(a)MIT.EDU] wrote: >I'm not sure I fully understand your example or concern. There's a .sig along "Common Lisp is for the things that work." >Obviously, if my program is multithreaded or the C program needs to >maintain the state across calls or I don't know what else, then the >semantics become very different. [...] >documentation caveats that it's not going to DTRT across all platforms >if you require true sharing? Calling something "shareable vector" and recognizing it's not true sharing is not something that works. Does this make my position clearer? There's IMHO already too much broken SW and APIs out there in the world (Lisp, Java, Python, C++, c#, C, whatever). We should try to focus on a) things that work b) things that work at large c) things that work reliably The environment API descibed in CLtL2 was removed from ANSI-CL. Why? because it was found to be subtly broken. No more reason than that. And I showed that it's blatantly broken to try to mimic shared vectors with copying. Do you see the parallels? In summary, I'm not against an optional shared-vector API at all. It may even be a distinguishing feature of CFFI vs. UFFI that it provides many optional APIs. But I'm really opposed to broken things, e.g. trying to provide/implement the shared-vector API using copying. Please strive for correctness, not brokeness. Regards, Jorg Hohle.

1 0

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