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

Re: [cffi-devel] user list?
by Stephen Compall 05 Jan '06

05 Jan '06

James Bielman wrote: > Patches against the documentation that notice such things and comment > out the offending sections (so they can be moved to the TODO list, or > other places) would be especially useful. Those making such patches, please note the @ignore block works just as well as @comment/@c and makes for smaller patches. :) -- Stephen Compall http://scompall.nocandysw.com/blog

1 0

Re: [cffi-devel] a few tiny patches
by Hoehle, Joerg-Cyril 05 Jan '06

05 Jan '06

James bielman wrote: >BTW, I raised the message size limit to (IIRC) 300k or so, You mentioned that already, however >you should be able to get by without gzipping these patches is there a particular interest for doing so? I.e. would you or Luis or anybody else appreciate being able to immediately review the patch in the e-mail? Could there be a problem with CRLF appearing in appended patch files when transmitted from MS-Windows systems and getting into darcs unnoticed? Regards, Jorg Hohle.

2 1

[cffi-devel] user list?
by Keith Irwin 05 Jan '06

05 Jan '06

Folks-- Is there likely to be a user list for cffi in the near future? If not, is it okay to ask user oriented questions (or provide dumb-user feedback)? For instance, I was trying to defcstruct the GdkEventKey structure for SBCL, and couldn't use stuff like :uint32 and so on as shown in the manual. So I had to spend a lot of time guessing (and staring at cffi-sbcl.lisp). So, it seems I have to use :char for :gint8 and so on. The following finally allowed me to extract the keypress (for cl-browser) I was looking for, but, alas, it wasn't so plain given the C documentation for the actual struct (as follows). ;; CL/CFFI version (defcstruct gdk-event-key "GdkEventKey" (gdk-event-type :int) (gdk-window :pointer) (send-event :char) ;; int8 (time :unsigned-int) (state :unsigned-int) (keyval :unsigned-int) (length :int) (text :string) (hardware-keycode :unsigned-short) (group :unsigned-char)) ;; C version typedef struct { GdkEventType type; GdkWindow *window; gint8 send_event; guint32 time; guint state; guint keyval; gint length; gchar *string; guint16 hardware_keycode; guint8 group; } GdkEventKey; What confuses me a bit is the C docs. What's the diff between guint and guint32? Since I'm on a 32bit machine, they're the same, right? Anyway, I figure I'm you're target luser. Never programmed significantly in C and am really liking how simple CFFI seems (after sb-alien). Are you planning on mapping more names to the SBCL part of all this? Having something like :unsigned-int32 as well as :unsigned-int would allow me to remain as ignorant as I want to. ;) (Translation: since I deal with word size so rarely, I always have to think hard about it and remember stuff, and that, well, interrupts the flow, you know?) Okay, well, the work you're doing is fantastic. It's a lot of fun. I might even make cl-browser the minimalist working browser out there, if only to force myself to learn more of the huge GTK api. Keith

2 1

[cffi-devel] lispname/cname ordering
by Matthew Backes 04 Jan '06

04 Jan '06

CFFI tends to have name specifications like (c-name lisp-name) whenever fully specifying the names as a list. In CFFI-Grovel, we're tentatively doing (lisp-name &rest c-names) in several places (for constants and enums). This is so that we can easily provide a list of alternative c-names for the groveler to try as it hunts for the symbol. e.g.: (defconstant (path-max "PATH_MAX" "MAXPATHLEN")) which covers both SYSVish and BSDish systems. But this is bad because it's backwards from what CFFI does. Anyone have any ideas on a good syntax? I'd really like groveler forms to strongly resemble CFFI (or CL) forms to reduce user confusion. Matthew Backes lucca(a)accela.net

3 2

[cffi-devel] New patches: 3-Jan-2006
by loliveira＠common-lisp.net 03 Jan '06

03 Jan '06

Tue Jan 3 21:28:16 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * gensym name and typo fixes M ./src/cffi-clisp.lisp -1 +1 M ./src/strings.lisp -2 +2 M ./src/types.lisp +1 M ./src/utils.lisp -1 +1 Tue Jan 3 16:35:51 CET 2006 Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net> * ffi:with-c-var's symbol-macrolet repeatedly applies foreign-value, avoid it M ./src/cffi-clisp.lisp -19 +18 Tue Jan 3 16:35:27 CET 2006 Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net> * TODO: foreign-alloc needs testcases M ./TODO +1 Mon Jan 2 16:29:57 CET 2006 Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net> * with-foreign-pointer [cmucl,sbcl]: forgot one instance of EVAL (constantp case) M ./src/cffi-cmucl.lisp -2 +1 M ./src/cffi-sbcl.lisp -2 +1 Mon Jan 2 16:22:02 CET 2006 Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net> * clisp defcallback: free unless invalid (possibly from old image) M ./src/cffi-clisp.lisp -1 +2 Tue Jan 3 10:24:48 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * document new type translator interface in the manual M ./doc/cffi-manual.texinfo -58 +249 Sun Jan 1 11:09:35 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * ramble a bit in comments about the new interface M ./src/types.lisp -1 +9 Sun Jan 1 10:31:54 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * ignore NAME in :wrapper UNPARSE method M ./src/types.lisp +1 Sun Jan 1 10:30:28 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * properly handle alloc param chain for typedef translators M ./examples/translator-test.lisp +24 M ./src/types.lisp -7 +15 Sun Jan 1 10:17:27 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * remove DEFINE-TYPE-TRANSLATOR from package exports M ./src/package.lisp -1 Sun Jan 1 10:15:35 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * new translator GF protocol, as discussed in IRC M ./examples/gettimeofday.lisp -4 +2 M ./examples/translator-test.lisp -12 +10 M ./src/enum.lisp -4 +2 M ./src/foreign-vars.lisp -3 +3 M ./src/functions.lisp -4 +3 M ./src/package.lisp -3 M ./src/strings.lisp -16 +8 M ./src/types.lisp -146 +86 Sun Jan 1 05:39:15 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * fix missing newline issues M ./src/early-types.lisp +1 M ./src/foreign-vars.lisp +1 Wed Dec 28 18:41:02 CET 2005 James Bielman <jamesjb(a)jamesjb.com> * remove obsolete comment in MAKE-LOAD-FORM method M ./src/early-types.lisp -2 Wed Dec 28 18:30:14 CET 2005 James Bielman <jamesjb(a)jamesjb.com> * new file, translator example A ./examples/translator-test.lisp Wed Dec 28 18:24:21 CET 2005 James Bielman <jamesjb(a)jamesjb.com> * new translator interface updates - Add UNPARSE generic function for unparsing types. - Reverse the order of the type name and class in translator GFs. - Add NEXT-* versions of the translator GFs. M ./TODO +6 M ./examples/gettimeofday.lisp -4 +4 M! ./src/early-types.lisp -2 +15 M ./src/enum.lisp -2 +2 M ./src/foreign-vars.lisp -2 +2 M ./src/functions.lisp -3 +3 M ./src/package.lisp +3 M ./src/strings.lisp -13 +14 M ./src/types.lisp -36 +86 Fri Dec 23 20:53:48 CET 2005 James Bielman <jamesjb(a)jamesjb.com> * fix unused variable warnings M ./src/types.lisp +4 Fri Dec 23 20:51:27 CET 2005 James Bielman <jamesjb(a)jamesjb.com> * specify :argument-precedence-order for translator generics M ./examples/gettimeofday.lisp -4 +4 M ./src/package.lisp -1 M ./src/strings.lisp -6 +6 M ./src/types.lisp -7 +8 Fri Dec 23 20:41:15 CET 2005 James Bielman <jamesjb(a)jamesjb.com> * new type translator implementation M ./examples/gettimeofday.lisp -11 +11 M ./src/early-types.lisp +5 M ./src/enum.lisp -11 +4 M! ./src/foreign-vars.lisp -13 +7 M ./src/functions.lisp -11 +13 M ./src/package.lisp -1 +7 M ./src/strings.lisp -21 +32 M! ./src/types.lisp -160 +140 Tue Jan 3 01:45:25 CET 2006 Luis Oliveira <loliveira(a)common-lisp.net> * load-foreign-library changes - Pass :foreign t to LOAD on Allegro. - Use sys::load-object-file on CMUCL. M ./src/cffi-allegro.lisp -5 +4 M ./src/cffi-cmucl.lisp -2 +2 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060103.tar.gz

1 0

[cffi-devel] a few tiny patches
by Hoehle, Joerg-Cyril 03 Jan '06

03 Jan '06

I had the following in my queue: o more (gensym "NAME") and typo fix o clisp defcallback: free unless invalid (possibly from old image) o with-foreign-pointer [cmucl,sbcl]: forgot one instance of EVAL (constantp case) o TODO: foreign-alloc needs testcases o ffi:with-c-var's symbol-macrolet repeatedly applies foreign-value, avoid it Regards, Jörg Höhle.

2 1

[cffi-devel] generate mapping from windows.h with the cffi module of swig
by Frank Buss 03 Jan '06

03 Jan '06

Surendra Singhi wrote: > You can also try SWIG (cvs version) it fully supports C. thanks, I've tried it and now it generates a mapping for e.g. TCL (which is 16 mb), but when specifying -cffi, it reports some messages (see below) and generates only a 6000 line lisp file for CFFI, with all mappings until GENERIC_MAPPING, but all other missing. Deleting this stops at the next structure. Looks like the CFFI support is missing some features. This is the command line I've used: swig -DGUID_DEFINED -D_TCHAR_DEFINED -D_M_IX86 -D_WIN32 \ -Iwindows -Iwindows/w32api -includeall -cffi interface.i and this the interface.i: %include "windows.i" %module windows %{ #include "windows.h" %} %include "windows.h" I've used the cygwin header files and patched it a bit to fix some errors, you can download the package at http://www.frank-buss.de/tmp/cffi.zip I'll post this to the cffi-devel mailing list, too, perhaps someone can take a look at it and fix the cffi swig module. The error messages: /usr/local/share/swig/1.3.28/windows.i:6: Warning(453): Can't apply (unsigned char const &). No typemaps are defined. /usr/local/share/swig/1.3.28/windows.i:9: Warning(453): Can't apply (signed char const &). No typemaps are defined. /usr/local/share/swig/1.3.28/windows.i:12: Warning(453): Can't apply (unsigned short const &). No typemaps are defined. /usr/local/share/swig/1.3.28/windows.i:15: Warning(453): Can't apply (short const &). No typemaps are defined. /usr/local/share/swig/1.3.28/windows.i:18: Warning(453): Can't apply (unsigned int const &). No typemaps are defined. /usr/local/share/swig/1.3.28/windows.i:21: Warning(453): Can't apply (int const &). No typemaps are defined. /usr/local/share/swig/1.3.28/windows.i:23: Warning(453): Can't apply (unsigned long long). No typemaps are defined. /usr/local/share/swig/1.3.28/windows.i:24: Warning(453): Can't apply (unsigned long long const &). No typemaps are defined. /usr/local/share/swig/1.3.28/windows.i:26: Warning(453): Can't apply (long long). No typemaps are defined. /usr/local/share/swig/1.3.28/windows.i:27: Warning(453): Can't apply (long long const &). No typemaps are defined. Structure GENERIC_MAPPING has a slot that we can't deal with. nodeType: access, name: , type: with this typedef for ACCESS_MASK: typedef DWORD ACCESS_MASK, *PACCESS_MASK; -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de

2 1

Re: [cffi-devel] a thought on string encodings
by Hoehle, Joerg-Cyril 03 Jan '06

03 Jan '06

Hi, James Bielman wrote: >I think CLISP has enough to implement these fairly efficiently, The devil's details lie in the many keyword arguments... For example, all :offsets means that the CLISP code must provide for possible addition, instead of directly using the pointer. But it's ok to leave it in. For example, I somewhat dislike LispWork's convert-from-foreign-string because it takes both :length and :null-terminated-p keys, which are not orthogonal. :length nil :null-terminated-p nil is an error. (Perhaps I should also dislike the ANSI-CL functions with :Test and :Test-not etc.?) Plenty of keyword arguments tend to make implementations clumsy. Also, they tend to hide the low-level basic functionality from the nice-to-have (cf. cffi:foreign-alloc). Most of your proposal seems in-line with ideas I had for APIs for CLISP, however the following stroke me: >Function: FOREIGN-STRING-TO-LISP pointer encoding &key start end >Convert octets from START to END (octet indices) I think a) you should leave :start and :end to Lisp vectors and stick to :offset with foreign pointers b) octets indices will be unnatural and thus error-prone for people mostly on MS-windows, constantly manipulating UTF-16 strings. I suggest you use :offset (in bytes, as usual) and :count (also in bytes/octets) instead. Unlike LispWork's function, these are othogonal. >Function: LISP-STRING-TO-FOREIGN string encoding &key start end >Function: LISP-STRING-OCTET-LENGTH string encoding &key start end :start + :end consistently provided for Lisp strings is good. >Function: FOREIGN-STRING-LENGTH pointer encoding >This should be smart enough to look for 8-bit vs 16-bit null >terminators, as appropriate for the encoding. TRT >I don't think it will support much beyond :ascii or :iso-8859-1 in >non-Unicode Lisps---I don't want to encumber CFFI with a bunch of >character code tables. I agree, but You don't have users in Asia yet, do you? In other words, you should provide for extensibility. One way would be to pass non-recognized encoding designators through to the underlying Lisp (which would make it difficult to find out the number of zero terminators for functions of yours that need it, and possibly others quirks waiting at the corner). >Function: LISP-STRING-TO-FOREIGN string encoding &key buffer >BUFFER must be large enough to accommodate the foreign >string---this can be queried with LISP-STRING-OCTET-LENGTH. This will lead to double work being done by mbslen() et al. on behalf of people calling first *-length, then *-to-foreign. While I see the need to be able to write directly into a buffer area, there ought to be better APIs than this one. Regards, Jorg Hohle.

1 0

Re: [cffi-devel] a thought on string encodings
by Hoehle, Joerg-Cyril 03 Jan '06

03 Jan '06

James Bielman wrote: >Now that this is working, I will start pulling the >implementation-specific code into an encoding-aware >%FOREIGN-STRING-TO-LISP function in CFFI-SYS. How are you going to represent the encodings? - use the implementation's objects? - introduce your own names? - restrict yourself to known encodings, e.g. UTF-8 (users on MS-Windows would appreciate UTF-16)? >#+clisp >(defcfun "strlen" :unsigned-int > (s :pointer)) Hmm, I lost track of whether that works on MS-Windows in a MS-VC build (as opposed to mingw/cygwin/unix-like). Yeah, I should really add this string stuff to clisp instead. Regards, Jorg Hohle.

3 3

Re: [cffi-devel] a thought on string encodings
by Hoehle, Joerg-Cyril 03 Jan '06

03 Jan '06

Yaroslav Kavenchuk wrote: >>Thus (let ((custom:*foreign-encoding* charset:foo))) won't work as >expected, you >It does ext:letf[*] Thanks, Yaroslav. I forgot about that one, which is odd since IIRC it's me who pressed Sam Steingold to explicitly mention this is the CLISP impnotes. -- Blush. Still I don't appreciate interfaces that need unwind-protect etc. or special variables to work. I very much prefer functional APIs. The other ones get scoping typically wrong. Consider th effect of (ext:letf ((custom:*foreign-encoding* charset:utf-16)) (convert-some-string) (foreign-funcall some-function-which calls back into Lisp)) Within the extent of the callback, the encoding would be set to an unusual value... Regards, Jorg.

2 1