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

Re: [cffi-devel] vararg / New foreign library interface
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Luis Oliveira wrote: >Allegro resets the stack pointer to whatever value it had before >pushing the foreign call's arguments to the stack. This approach >works for either stdcall or cdecl. I'd believe CLISP's ffcall is insensitive to the actual stack value on return as well. But that's not the only difference. Edi Weitz recompiled the .dll used by cl-gd for ease of use by Lisp. The reason is name decoration: the original contains names like "myfun@8", whereas Edi's version has names "myfun" -- or vice-versa. The "@8" suffix means thath the function takes 8 bytes of arguments, probably two 32-bit pointers, or two 32-bit ints, or a mix of both, or whatever. In CLISP, using def-call-out, you must give the exact matching name. As a result, it's much easier to interface when the library contains the typical "short" names. However, IIRC, Visual Basic has it the other way by default, but can accomodate both. I believe authors aware of the problem when coming from other languages would normally use the short form. Sadly, gd does not (historic reasons, probably). Note that name decoration can be independent on the calling convention. IIRC, MS-VC etc. can use .def(inition) file and define the mapping themselves that they want in their library. All of that is from memory, from times when I tried to figure out the difference between :stdc and :stdc-stdcall. What it means for cffi is that there may come the day when defcfun needs another keyword to specify the name decoration, so as to be able to interface to library X. Then the cffi macro could add the "@N" to the given name itself, since it can compute the size of the arguments. That's my vision of things. Or cffi could delegate this to the underlying Lisp. AFAIK, Lispworks has some keywords for that difference. CLISP does not. Yet cffi still needs a keyword to be able to tell Lispworks whether to set the keyword or not... Regards, Jörg Höhle.

1 0

Re: [cffi-devel] vararg / New foreign library interface
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Luís Oliveira >Also, define-foreign-library should probably be extended to take a >calling convention argument Indeed, that would be the next thing. However, how much Lisps let you choose that? Am I wrong or is this only a MS-Windows host issue? MacOS? > though ideally, IMHO, every Lisp would be >like Allegro in this regard and we wouldn't have to pick between >cdecl and stdcall and it would work with either calling convention. What does Allegro do? Regards, Jörg Höhle.

2 1

AW: [cffi-devel] New patches: 7-Jan-2006
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Luis Oliveira wrote: > * Pushing cffi-features symbols to *features* > - Renamed :cffi/no-foreign-funcall and :cffi/no-long-long to > cffi-features:foreign-funcall and cffi-features:long-long >respectively > (with the opposite meanings of course). I find this unfortunate. While there are guidelines against the use of negation (and the likely use of double negation), I'd prefer not to clober *features* on full-featured implementations. Therefore, #+|- NO-foobar made a lot of sense. It's name embodied that something was not as nice as it could be. That's lost now. Try not to think in terms of autoconf/UNIX: #define HAVE_XYZ. [BTW, there are too many activities going on right now, I can't follow-up anymore] Regards, Jorg Hohle.

2 1

AW: [cffi-devel] vararg / New foreign library interface
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

James Bielman wrote: >FOREIGN-FUNCALL-IN-LIBRARY No, because foreign-funcall takes a pointer. That means, the name to address resolution has already happened before. Oops, wrong. foreign-funcall-pointer takes a pointer. foreign-funcall takes a string, which indeed means it's on its own w.r.t. address resolution :-( >perhaps silently ignoring :LIBRARY options on those implementations We had the "uniformity" topic recently. Remember, I had to send patches to several packages to add :module to UFFI code to make it work with CLISP. >(with-default-library ("msvcrt.dll") > (defcfun "sprintf" :int Quite reasonable, as one can expect many files to have this structure: binding-to-XYZ.lisp (set-library-somehow XYZ) (defcfun x [in XYZ]) (defcfun y [in XYZ]) Regards, Jorg Hohle

2 1

Re: [cffi-devel] New foreign library interface
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Hi, >For example, one way to handle this would be for LOAD-FOREIGN-LIBRARY >to return a cookie Cookie or "designator" is IMHO the way to go. I feel it's a waste to reimplement in CFFI what UFFI already had to fuss around with directories, file extensions, features etc., reimplementing itself what's possibly in various Lisp implementations. I nuked all of that crap in my own UFFI wrappers. The "cookie" is UFFI's module name (typically a keyword, e.g. :odbc), and I assoc that one to the filename. This association shall be maintained outside of UFFI/CFFI. It's the user who's setting this, and possibly the distribution maintainer (e.g. Debian). That association is not even in package UFFI (I put it in USER). That way, it can be defined even before UFFI is loaded (e.g. .clisprc). You don't need tricky constructions to the effect of being able to load UFFI first, patch the paths, then load system foo. The proposals I've seen here for CFFI looked to me like they might get this wrong. > (define-foreign-library opengl > (:darwin (:framework "OpenGL")) > (:unix (:alternatives "libGL.so" "libGL.so.1" > #p"/myhome/mylibGL.so")) This is exactly what I criticize. You, the programmer, do you know the library directories, extensions, version numbers of OpenGL on all platforms of the users of your library? Do you know all the appropriate *features*? Do you have means to test what you write yourself? Presumably, you don't. A Debian distributor might know, but not the code maintainer of an individual package. Therefore, again, a central algorithm & means of mapping makes more sense that people's wild guesses, different for each package and author. I very much prefer (defcfun "myfun" :module/library :my-cookie-designator :arguments ...) Hmm, not sure I made myself clear, feel free to ask. Regards, Jorg Hohle

2 1

Re: [cffi-devel] vararg
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Stephen Compall wrote: >Of course, CLISP's :library option is unevalled .... antinews. The initial version did this, but it's been changed since, some time ago. Please file a bug report to clisp if this is not documented. BTW, your e-mail appeared here in an almost unreadable format (looking like nested attachments, whereas the main window only contained the cffi list signature. But then, I must apologize for sending e-mails out with this MS-Outlook crap, which does not handle replies correctly, which does not allow to control word-wrapping etc. Sadly, it's the only one I can use from here. Regards, Jorg

1 0

[cffi-devel] uffi-compat bitrot (and patch)
by Robert J. Macomber 09 Jan '06

09 Jan '06

With the new type translator system, uffi-compat broke a little. I've written a patch for it, though I'm not 100% sure it's correct. However, with the patch, it passes all uffi's tests, and cl-gd seems to work properly. The patch is attached. -- Robert Macomber / Thas on #lisp xbxyh8(a)rojoma.com

2 1

[cffi-devel] Lisp-name conversion
by Surendra Singhi 09 Jan '06

09 Jan '06

Hi, Is there any way which allows one to control the way cffi does the conversion from c-names to lispy names? Is it possible to disable this feature or customize it? Thanks. -- Surendra Singhi http://www.public.asu.edu/~sksinghi/index.html ,---- | By all means marry; if you get a good wife, you'll be happy. If you | get a bad one, you'll become a philosopher. | -- Socrates `----

2 1

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

07 Jan '06

Sat Jan 7 07:15:26 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * add :default expression to auto-append library suffixes M ./src/libraries.lisp +20 Sat Jan 7 07:14:52 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * allow t in library feature expression as default M ./src/libraries.lisp +2 Sat Jan 7 12:05:58 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * remove some finished items from the TODO list M ./TODO -9 Sat Jan 7 06:34:55 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * signal an error when trying to load undefined "logical" foreign libraries M ./src/libraries.lisp -1 +3 Fri Jan 6 06:03:25 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * implement new callback interface for corman M ./src/cffi-corman.lisp -1 +8 Fri Jan 6 06:01:25 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * implement new callback interface for ecl Untested: the ECL backend does not seem to build for me. M ./src/cffi-ecl.lisp -4 +25 Fri Jan 6 05:57:53 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * implement new callback interface for cmucl Unsolved problems still prevent CFFI from working in a saved image on CMU CL. M ./src/cffi-cmucl.lisp -4 +28 Fri Jan 6 04:42:17 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * implement new callback interface for lispworks M ./src/cffi-lispworks.lisp -8 +30 Fri Jan 6 04:08:39 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * fix callbacks in saved images in clisp, sbcl, allegro, and openmcl M ./src/cffi-allegro.lisp -9 +48 M ./src/cffi-clisp.lisp -19 +61 M ./src/cffi-openmcl.lisp -8 +32 M ./src/cffi-sbcl.lisp -10 +11 M ./src/functions.lisp -4 +5 Sat Jan 7 04:17:09 CET 2006 Luis Oliveira <loliveira(a)common-lisp.net> * New types. Sized ints and aliases. - Defined the :[u]int{8,16,32,64} types by looking at the sizes of the built-in types. - Removed :[u]int{8,16,32,64} from cffi-clisp. - New typedefs: :uchar, :ushort, :uint, :ulong, :llong, and :ullong. - New test: misc-types.sized-ints. - Removed the related TODO items. M ./TODO -4 M ./src/cffi-clisp.lisp -8 M ./src/early-types.lisp +4 M ./src/types.lisp -24 +53 M ./tests/misc-types.lisp +7 Sat Jan 7 03:18:35 CET 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Substitute missing ensure-string. M ./src/libraries.lisp -1 +3 Sat Jan 7 03:13:48 CET 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Remove the TODO item related to load-foreign-library M ./TODO -4 +1 Sat Jan 7 03:11:26 CET 2006 Luis Oliveira <loliveira(a)common-lisp.net> * %foreign-funcall-pointer for ECL M ./src/cffi-ecl.lisp +8 Sat Jan 7 03:10:01 CET 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Remove old comments in cffi-clisp and cffi-sbcl M ./src/cffi-clisp.lisp -7 M ./src/cffi-sbcl.lisp -6 Sat Jan 7 03:08:05 CET 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Foreign library changes - Fix loading of foreign libraries in cffi-allegro. Now tries to load whatever is passed to %load-foreign-library instead of refusing to load files with types that aren't in excl::*load-foreign-types*. - Changes to %close-foreign-library in CMUCL and SBCL. Use string= instead of string-equal to match libraries. - Lispworks: use :connection-style :immediate in %load-foreign-library. - New foreign library interface. M ./src/cffi-allegro.lisp -5 +8 M ./src/cffi-cmucl.lisp -1 +1 M ./src/cffi-lispworks.lisp -1 +1 M ./src/cffi-sbcl.lisp -1 +1 M ./src/libraries.lisp -14 +193 M ./src/package.lisp -2 +9 Sat Jan 7 02:56:44 CET 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Pushing cffi-features symbols to *features* - Renamed :cffi/no-foreign-funcall and :cffi/no-long-long to cffi-features:foreign-funcall and cffi-features:long-long respectively (with the opposite meanings of course). - Also new features (in the cffi-features package): darwin, unix, windows, ppc32 and x86. More could be added. The cffi-sys backends are responsible for pushing these features. M ./cffi.asd +1 M ./src/cffi-allegro.lisp -5 +12 M ./src/cffi-clisp.lisp -6 +14 M ./src/cffi-cmucl.lisp -5 +14 M ./src/cffi-corman.lisp -3 +9 M ./src/cffi-ecl.lisp -4 +13 M ./src/cffi-lispworks.lisp -5 +12 M ./src/cffi-openmcl.lisp -2 +9 M ./src/cffi-sbcl.lisp -1 +11 A ./src/features.lisp M ./src/package.lisp -3 M ./src/types.lisp -3 +3 M ./tests/callbacks.lisp -3 +3 M ./tests/defcfun.lisp -1 +1 M ./tests/foreign-globals.lisp -3 +3 M ./tests/funcall.lisp -3 +3 M ./tests/struct.lisp -1 +1 Sat Jan 7 02:54:54 CET 2006 Luis Oliveira <loliveira(a)common-lisp.net> * New TODO item about CLISP fasl portability M ./TODO +9 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060107.tar.gz

1 0

[cffi-devel] New foreign library interface
by Luís Oliveira 07 Jan '06

07 Jan '06

Hello, There's been some discussion on IRC about what CFFI's "smarter" foreign library interface should look like. I put together some code and here's what my attempt looks like: (define-foreign-library opengl (:darwin (:framework "OpenGL")) (:unix (:alternatives "libGL.so" "libGL.so.1" #p"/myhome/mylibGL.so")) (:windows "opengl32.dll") ;; and a hypothetical example of a particular platform ;; where the OpenGL library is split in two. ((:and :some-system :some-cpu) "libGL-support.lib" "libGL-main.lib")) The library is then used with the following macro: (use-foreign-library opengl) So here's what's going on when loading this opengl library: - First, the proper clause is selected in a cond-like fashion. The symbols in there are tested against symbols in *features* that belong to the cffi-features[1] package. The :and, :or and :not operators are supported. - Then, the rest of the elements in the clause are handled. There can be more than one. For example you could define GLUT and OpenGL in one define-foreign-library form and whatever support libraries those might need. - Each of the elements can be: a) A string, eg. "libGL.so". In this case it's passed to load-foreign-library directly. What this means in e.g. unix-like systems is that the library will be searched in: 1. the LD_LIBRARY_PATH environment variable. 2. the directories in /etc/ld.so.cache (or equivalent) 3. /usr/lib and /lib If that fails, it tries to find it in the directories inside cffi:*foreign-library-directories* which is similar to asdf:*central-registry* in the sense that you can push stuff like '*default-pathname-defaults* or '(user-homedir-pathname) and they'll be "evaluated". b) A pathname, in which case CFFI doesn't try to find it and simply passes its namestring to load-foreign-library. c) A list of the form (:alternatives ...). Here we try to load each of the alternatives in order until one is loaded successfully. If none of the alternatives are loaded we get an error. d) A pair of the form (:framework "name"). CFFI will try to load the "name" framework, looking at the directories in cffi:*darwin-framework-directories* which is similar to cffi:*foreign-library-directories*. This list contains the following paths by default: 1. ~/Library/Frameworks 2. /Library/Frameworks 3. /System/Library/Frameworks Obviously, the user can push more paths into this list. There are some functions that I'm not sure are worth exporting: find-foreign-library, find-and-load-foreign-library and find-darwin-framework. Also, maybe a functional interface to use-foreign-library could be useful? Comments? [1] We'll be removing :cffi/no-foreign-funcall, and pushing cffi-features:foreign-funcall instead. Also, we provide others like cffi-features:{windows,unix,darwin,ppc32,x86} so that users can rely on these across different lisps. -- Luís Oliveira luismbo (@) gmail (.) com Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

3 9