cffi-devel January 2006

cffi-devel@common-lisp.net

34 participants
97 discussions

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

10 Jan '06

Luís 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 forgot this other issue: This approach is good enough for Lisp to C. But what about callbacks, i.e. C to Lisp? Do you know how a foreign function would react when returned an unexpected stack pointer? gcc -fno-omit-frame-pointer helps around this, but is not general. Without a hint, one simply doesn't know what calling convention the foreign caller expects. Clean up the stack or not, that is the question. Regards, Jörg Höhle.

1 0

[cffi-devel] try-foreign-library-alternatives patch
by Stephen Compall 10 Jan '06

10 Jan '06

I was getting a load-foreign-library-error on the following: (define-foreign-library libcurl (:unix (:or "libcurl.so.3" "libcurl.so")) ((:not :unix) (:default "libcurl"))) (use-foreign-library libcurl) until I patched try-foreign-library-alternatives as in the attached darcs patch, also at http://csserver.evansville.edu/~sc87/cffi/tfla-success.patch If load-foreign-library is supposed to answer non-nil on success, a different patch is in order. -- Stephen Compall http://scompall.nocandysw.com/blog

1 0

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

09 Jan '06

Mon Jan 9 08:40:53 CET 2006 James Bielman <jamesjb(a)jamesjb.com> * update uffi-compat to new translator interface Patch courtesy of: Robert J. Macomber <xbxyh8 at rojoma.com> M ./uffi-compat/uffi-compat.lisp -6 +6 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060109.tar.gz

1 0

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

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel January 2006