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

Re: [cffi-devel] bits from a new tutorial
by Hoehle, Joerg-Cyril 23 Dec '05

23 Dec '05

>Agreed. Still, the ability to call varargs functions seems to be >useful. Namely, James is working on an Objective-C bridge on top of >CFFI that uses this functionality. Are you sure that is varargs or do you mean polymorphism, i.e. each different signature has a different entry point (address), but they are still refered under an identical name? That remembers me with the stdcall calling convention & name decoration on MS-Windows, where there are two versions of the gd.dll: one with typical C names, another with things like "@8" appended, when there are 8 bytes worth of arguments. Regards, Jörg Höhle.

2 1

[cffi-devel] New patches in cffi-luis: 22-Dec-2005
by loliveira＠common-lisp.net 22 Dec '05

22 Dec '05

Thu Dec 22 20:39:04 CET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Push :cffi to *features* M ./src/package.lisp +3 Thu Dec 22 18:01:47 CET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Make defcfun accept a docstring M ./src/functions.lisp +1 Thu Dec 22 17:20:55 CET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Fix indentation. M ./src/cffi-clisp.lisp -1 +1 M ./src/types.lisp -6 +6 Tue Dec 20 12:16:27 CET 2005 Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net> * Add background info on free'ing callbacks M ./src/cffi-clisp.lisp -1 +5 Thu Dec 15 09:56:49 CET 2005 Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net> * cffi-clisp:%defcallback: simplify it M ./src/cffi-clisp.lisp -9 +10 Wed Dec 14 14:39:08 CET 2005 Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net> * foreign-slot-value|set compiler-macro update M ./src/types.lisp -10 +9 Wed Dec 14 14:37:25 CET 2005 Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net> * use ffi:foreign-variable in foreign-symbol-pointer M ./src/cffi-clisp.lisp -10 +9 Fri Dec 9 18:22:37 CET 2005 Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net> * ffi:memory-as is a perfect match for %mem-ref M ./src/cffi-clisp.lisp -8 +3

1 0

AW: [cffi-devel] bits from a new tutorial
by Hoehle, Joerg-Cyril 22 Dec '05

22 Dec '05

Luís Oliveira wrote: >This tutorial shows the usefulness of foreign-funcall for C functions >with varargs. Lispworks unfortunately doesn't export this >functionality. I consider it an omission in a foreign API if all that is provided is varargs. I'd bug the respective developers until they provide a function that takes an array of some such. execv() is an excellent example of how it can be done right. If there's some such function in the API, I urge you to call that, not the C varargs function. Calling the latter is like trying to call a macro at run-time in Lisp: macros and varargs are syntactic sugar for compile-time. At run-time, it's too late. Considering the baroque calling conventions of C compilers (Duane Retting posted details in comp.lang.lisp about some exotic ones not too long ago), it's no surprise that varargs are not supported. E.g. Duane Rettig's article made me wonder whether: 1. one can portably call syslog() from any foreign (non C) language, and 2. whether varags are compatible with full prototypes, which clisp's ffcall likes to use. With that I mean that if I understand Duane right, the calling conventions for foo(char *, ...); when called in C as foo("abl",(double)x,(int)y,(whatever)z) can be different from the calling convention that arises from a declaration as foo(char*,double,int,whatever); The call could crash?!? Maybe I misunderstood Duane Rettig, but I feel like there's a problem. Well, I should take that to comp.lang.lisp again (or comp.lang.C or whatever). W.r.t. syslog() (this one once came up in the clisp mailing list), probably the only sensible interface is to call it as (foreign-funcall "syslog" "%s" <Lisp-formatted-string>) Regards, Jörg Höhle.

2 1

[cffi-devel] why does cffi not use CLISP's long-long/int64?
by Hoehle, Joerg-Cyril 22 Dec '05

22 Dec '05

Luis Oliveira wrote: >> Is there a CLISP version currently used with cffi that has FFI but no >> long-long? What lead to this line in cffi-clisp.lisp? >I test CFFI mostly on MacOS X. Here, CLISP doesn't seem to support >long long. I see. I can't remember seeing a bug-report on the clisp sourceforge bug tracker, nor in the mailing lists. Actually, there's currently a general problem with long-long as ffi:s/uint64: it's completely incompatible. I realized this yesterday only (also Pascal Bourguignon gave some hints one year ago, which I did not understand). [callbacks] >> Something like this? >>+ (let ((cb-fun (get ',name 'clisp-callback-function))) >>+ (when cb-fun (ffi:foreign-free cb-fun))) >>+ (setf (get ',name 'clisp-callback-function) ,cb-var) Yes. Excuse me, I didn't look closely enough to see that you use two plist items with this patch. Actually, I wouldn't bother freeing them when they can occur at top-level only. BTW, does somebody know how to have darcs tell me what changes occurred between my repository and the main one? darcs changes gives output upto the initial revision. I just want to see a summary of changes. darcs send -o file contains this plus all the diffs. I don't want to see the diffs. Is darcs pull --dry-run the answer? Regards, Jörg Höhle.

2 1

[cffi-devel] swig - cffi module
by Vasilis M. 22 Dec '05

22 Dec '05

Hi, I try to add cffi support in swig. cffi module is a fork of Allegro CL module. Everything is working as described in http://cvs.sourceforge.net/viewcvs.py/swig/SWIG/Doc/Manual/Allegrocl.html?r… except automatic array handling and wide char support. A few questions before submitting the module to swig: c++ classes wraped by a (defclass c-proxy () ((foreign-pointer :initarg :foreign-pointer :reader foreign-pointer))) (cffi:defctype :c-proxy :pointer) (cffi:define-type-translator :c-proxy :to-c (value) `(foreign-pointer ,value)) for a c++ class with name cname there is a (cffi:defctype ff_cname :c-proxy) i want to check if a cffi-type is an alias of :c-proxy and i use (defun c-proxy-alias-p (cffi-type) (let ((tp (cffi::find-type cffi-type))) (when (subtypep (type-of tp) 'cffi::foreign-type-alias) (eql (cffi::name (cffi::actual-type tp)) :c-proxy)))) is there a way to do that without accessing cffi internals? any ideas for array handling?, as i can see there is no :array type in cffi. for wide char support Allegro CL module use (excl:with-native-string (out in :external-format #+little-endian :fat-le #-little-endian :fat) ...) and (excl:native-to-string ptr :external-format #+little-endian :fat-le #-little-endian :fat) Thanks, Vasilis Margioulas _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

3 2

[cffi-devel] Re: first clisp-specific patch: copyright, callbacks & spam
by Hoehle, Joerg-Cyril 22 Dec '05

22 Dec '05

Luís Oliveira wrote: >> ffi:memory-as is a perfect match for %mem-ref >Sure, sure. We would have used it if it were documented. ;-) You didn't read the documentation recently, did you? >darcs diff will produce a short patch. Ah, I used darcs send -uo file.patch instead >It'd be nice if cffi-devel wasn't moderated at all, but I suppose >it would get a lot of spam? I have no experience here, but IIRC Kevin Rosenberg or Marco Baringer have very strong opinions on the "subscribe first". I'd just appreciate if the mailing-list descriptions on common-lisp.net would mention that requirement. >However I suppose cffi-clisp's %defcallback should free the previous >callback with the same name (maybe this is what you're thinking >about). No, I did not mean that. > Something like this? >+ (let ((cb-fun (get ',name 'clisp-callback-function))) >+ (when cb-fun (ffi:foreign-free cb-fun))) >+ (setf (get ',name 'clisp-callback-function) ,cb-var) The comments specifically meant that this would not work, because (foreign-free #.#<FOREIGN-ADDRESS>) -> free(), which is not appropriate, while (foreign-free #.#<FOREIGN-FUNCTION>) lets clisp recognize and free the function. Cffi currently stores (foreign-address #<foreign-function>) in the plist, thus it cannot free the thing anymore. I haven't investigated what implications storing the #<FOREIGN-FUNCTION> object instead of its address would have on cffi invariants. Another possibility would be to attach a finalizer. But given that cffi callbacks are static only (and thus probably not numerous), I wouldn't bother the GC. There are other situations which create callbacks on the fly, without easy means to free them. For example, each time you pass a Lisp function to a foreign one with type (c-function ...): the Lisp side typically does not see pointer to the callback that gets created. >Btw, I have a question about CLISP's licensing. >My question is: does this mean CFFI (the whole CFFI?) would have to >be licensed under the GPL? I'm no lawyer either. the question arises from time to time and was even discussed not too long ago for UFFI (in clisp-list or clisp-devel). My understanding was that there's no problem, as the goal is to provide functionality also available in a great number of Common Lisp implementations. >If so, could these symbols CFFI uses be exported? I'm looking into that. Regards, Jörg Höhle.

2 1

[cffi-devel] why does cffi not use CLISP's long-long/int64?
by Hoehle, Joerg-Cyril 22 Dec '05

22 Dec '05

Hi, ffi:uint64 and ffi:sint64 are available on all platforms where CLISP ./configure finds support for the long long C type. Thus I wonder why cffi-clisp contains: (pushnew :cffi/no-long-long *features*) Is there a CLISP version currently used with cffi that has FFI but no long-long? What lead to this line in cffi-clisp.lisp? Regards, Jorg Hohle

2 1

[cffi-devel] Re: WG: first clisp-specific patch
by Luís Oliveira 22 Dec '05

22 Dec '05

On 2005-dec-21, at 18:48, Hoehle, Joerg-Cyril wrote: > Luis, here's the patch for you. > How do people submit shorter patches? Most of the 40KB is the > "context" that darcs appends. darcs diff will produce a short patch. Alternatively, puting your darcs tree somewhere where anyone can pull patches from is quite convenient. > --------------- > Your mail to 'cffi-devel' with the subject > > first clisp-specific patch > > Is being held until the list moderator can review it for approval. It'd be nice if cffi-devel wasn't moderated at all (namely, this would allow anyone to post via gmane.lisp.cffi.devel), but I suppose it would get a lot of spam? > -----Ursprüngliche Nachricht----- > Von: Höhle, Jörg-Cyril > Gesendet: Mittwoch, 21. Dezember 2005 17:58 > An: cffi-devel(a)common-lisp.net > Betreff: first clisp-specific patch > > > Hi, > > I used darcs pull /home/src/cffi-luis to create a local copy, > experiment a little with record and revert. darcs unrecord seems to > be good enough to cancel my patch that conflicted with the recent > changes to types.lisp. > > The current patch set is appended. I'd like to add more. The 96 > tests pass. > The patches are: > ffi:memory-as is a perfect match for %mem-ref Sure, sure. We would have used it if it were documented. ;-) > use ffi:foreign-variable in foreign-symbol-pointer > foreign-slot-value|set compiler-macro update > cffi-clisp:%defcallback: simplify it > Add background info on free'ing callbacks Regarding this comment: ;; The created callback function is not stack-allocated. + ;; It is valid until (ffi:foreign-free #<FOREIGN-FUNCTION>), + ;; but you can't use (ffi:foreign-free (callback name)), + ;; because that would invoke free() on the opaque c-pointer! + ;; Maybe cffi should make an exception and use the + ;; foreign-function object, not its address? I think the question whether (ffi:foreign-free (callback name)) works is pretty irrelevant since if people used that, the bindings wouldn't be portable anymore. However I suppose cffi-clisp's %defcallback should free the previous callback with the same name (maybe this is what you're thinking about). Something like this? + (let ((cb-fun (get ',name 'clisp-callback-function))) + (when cb-fun (ffi:foreign-free cb-fun))) + (setf (get ',name 'clisp-callback-function) ,cb-var) (setf (get ',name 'callback-ptr) (ffi:foreign-address ,cb-var))))) > BTW, cffi-gcl does not reflect the recent renaming fiesta (null-ptr- > p etc.). The GCL port has never been complete. I guess it'll have to wait either for someone who actually uses GCL to pick it up or for more important stuff to get finished first. > Further simple patches could cover possible performance > optimizations, or whatever. > > Regards & happy new year, > Jörg Höhle. > > <Joerg.patch> Btw, I have a question about CLISP's licensing. Quoting from CLISP's COPYRIGHT file: "This copyright does *not* cover user programs that run in CLISP and third-party packages not part of CLISP, if a) They only reference external symbols in CLISP's public packages (namely the packages COMMON-LISP, COMMON-LISP-USER, KEYWORD, CLOS, GRAY, EXT), i.e. if they don't rely on CLISP internals and would as well run in any other Common Lisp implementation. Or b) They only reference external symbols in CLISP's public packages (namely the packages COMMON-LISP, COMMON-LISP-USER, KEYWORD, CLOS, GRAY, EXT) and some external, not CLISP specific, symbols in third-party packages that are released with source code under a GPL compatible license and that run in a great number of Common Lisp implementations, i.e. if they rely on CLISP internals only to the extent needed for gaining some functionality also available in a great number of Common Lisp implementations." Since my legalese skills are weak specially in English I'm not even sure which of these two exceptions apply to CFFI. However, both talk about referencing external symbols only and cffi-clisp.lisp references a few internal symbols. My question is: does this mean CFFI (the whole CFFI?) would have to be licensed under the GPL? If so, could these symbols CFFI uses be exported? I'm certain relicensing CFFI under GPL would not be an option. Anyway, thanks for your patch and merry christmas! -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

2 1

[cffi-devel] New changes in cffi-luis
by Luís Oliveira 21 Dec '05

21 Dec '05

Wed Dec 21 17:02:35 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Make typedefs for structs work. - Make get-slot-info (and thus foreign-slot-value) work on typedefs to a struct type. - Regression test: STRUCT.4 Wed Dec 21 10:54:27 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Use fli:make-pointer instead of fli:*null-pointer* Use FLI:MAKE-POINTER here instead of FLI:*NULL-POINTER* for implementing CFFI-SYS:NULL-POINTER since old versions of Lispworks don't seem to have the latter. Patch courtesy of: Vebjorn Ljosa <vebjorn((a))ljosa.com> Tue Dec 20 04:38:49 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * CFFI-SYS-SPEC manual updates & Texinfo idioms Patch from: Stephen Compall <s11(a)member.fsf.org> - Use @var for arguments, rather than @code. - Use @deftpx for a chain of type defns, rather than repeated @deftp blocks. - Use @result{} instead of explicit =>. - Use @r with appropriate formatting for comments in @examples/@lisps. [didn't apply these changes since they didn't play well with the colorize script in the HTML output --luis] - Introduction: Convert naming convention to a list of general conventions, and define "foreign type". - Rename the pointer functions. - Document new functions. - Use new @impnote macro to add notes, so they can be conditionally removed from the manual. Tue Dec 20 03:58:58 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Forgot to export %close-foreign-library from cffi-lispworks.lisp Thu Dec 15 15:45:26 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Untabify cffi-ecl.lisp Thu Dec 15 09:58:34 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Preliminary support for close-foreign-library Unimplemented for ECL and Corman. Lously implemented in CMUCL (and possibly in the other ports too). Not exported. Wed Dec 14 11:08:39 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Fix parsing of types to match UFFI's behaviour Basically, extra quoting is supposed to be ignored. Thus 'foo, ''foo, '''foo, are all valid types. Mon Dec 12 05:37:39 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Bug fixes - WITH-FOREIGN-OBJECT should eval the type parameter. Fixed this as well as the examples and tests that assumed it wasn't evaluated. - document WITH-FOREIGN-OBJECT in the manual. - removed the pseudo ability to specialize arguments on define-type-translator. That didn't quite work, doh. - removed dead code from cffi-uffi-compat::foreign-type-size specialized on the uffi-array-type. - uffi-compat: parse (:array <type>) as (:array <type> 1) - uffi-compat: reflect the fact that CFFI:WITH-FOREIGN-OBJECT now evaluates the type parameter. Sun Dec 11 10:01:02 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Fix uffi-compat wrt to the ptr->pointer changes Sun Dec 11 06:45:57 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Added GETENV to uffi-compat Sun Dec 11 05:31:18 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Oops - Missing comma in define-type-translator. - Also, it almost but not quite accepted the method specifiers. Fixed. Sun Dec 11 05:22:01 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Type translation refactoring - Refactoring of the type translation mechanism, now based on generic functions. The only user-visible changes is that you can now specialize the on the argument of the translator, and there's no type argument now (which was useless too for user-defined types). - Don't export define-type-spec-parser since it's useless on its own. - The anonymous :enum type is gone. - Updated manual. Fri Dec 9 05:30:51 WET 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Update manual: CMUCL passes all tests. -- 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] Re: what I like about cffi -- darcs -- not
by Hoehle, Joerg-Cyril 21 Dec '05

21 Dec '05

Hi, >BTW, this was also my first use of darcs. I quite enjoy it and >appreciate its interactive mode. Grmpf. Now I discovered dacs --pull to update my local repository and of course, there was a conflict and darcs got really confused, or so I believe. Question 1: how would you like me to send patches? As a single large file (darcs send -o joerg.diff), or as a collection of the half-dozen darcs records that I used (with what command)? Question 2: The conflict occured in src/types.lisp where I had modified defctype. The change is completely superfluous now. But it's not until I went to the online repository that I understood that defctype was not at the bottom of the file but had moved up and was completely transformed. Even the local _darcs/current/src/types.lisp confused me since I believed that would reflect the newest remote content, but it contains a merge of remote and my local records -- somehow, without the conflict marker I get to se in the working directory. Any advice on how I should proceed from there on? Obviously, any new tool needs mastering & experience to cope with. Unrecord, unpull, rollback, amend-record and revert (or rather, their manpage) are still confusing me. I disliked darcs pull --verbose not telling me what patch introduced the conflict. At the end, it just said: We have conflicts in the following files: src/types.lisp I believe it could have been more precise, and name the patch. Regards, Jorg Hohle.

2 1