cffi-devel

cffi-devel@common-lisp.net

1113 discussions

[cffi-devel] CLisp exe vs FFI
by Ken Tilton 13 Feb '07

13 Feb '07

I would consider as merely a first sanity-checking step simply using native CLisp ffi to make one lousy call to SQL and get /that/ to work in an exe. ie, reduce the number of variables in play. Then try it with CFFI, but not uffi-compat. Then with uffi-compat, but still writing my own (one?) bindings. Then worry about cl-sql bindings running thru a maze of FFIs. hth,kt

1 0

[cffi-devel] C++ Exceptions.
by Collin Lynch 13 Feb '07

13 Feb '07

First, thanks for making this system, and apologies if this isn;t the list for these questions but there appears to be no cffi-users list. In any case, is there any way to catch the underlying c++ exceptions within a cffi-wrapper? I have developed a C++ library that defines its own exceptions and I would like to trap them and generate an appropriate Lisp Condition. At present deliberately triggering an error (say by passingincorrect parameters to a constructor) gives me back a null pointer. Thanks, Collin Lynch.

4 5

Re: [cffi-devel] calls with variable number of arguments which are determined at run-time
by James Bielman 09 Feb '07

09 Feb '07

Lars Rune Nøstdal <larsnostdal(a)gmail.com> writes: > Anyone have some suggestions as to how I can call foreign-functions > with variable number (the count, types and values determined at > run-time!) of arguments? > > I've nagged the CLL'ers about this and Pillsy came up with a hack > that works: > > I was wondering if there where better ways to do this? Hi Lars, Off the top of my head, I think any reasonable approach is going to need to involve calling the compiler. Only the compiler knows how to actually build the stack frames and such for the call. For example, there are arcane rules on some architectures about whether floating point values are passed on the stack or in registers depending on the number of arguments and their positions. One possibility for making it a little less gruesome performance-wise is to build a cache of precompiled functions for a set of function types. For each distinct set of argument types you can COMPILE a lambda that builds the appropriate FOREIGN-FUNCALL, and store it in an EQUAL hashtable with the list of arguments (:INT :FLOAT). What's the use case for this? Surely not sprintf; there's about a million better ways to format text without resorting to such things... ;-) Down with varargs! James

4 3

[cffi-devel] calls with variable number of arguments which are determined at run-time
by Lars Rune Nøstdal 09 Feb '07

09 Feb '07

Hey, Anyone have some suggestions as to how I can call foreign-functions with variable number (the count, types and values determined at run-time!) of arguments? I've nagged the CLL'ers about this and Pillsy came up with a hack that works: http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/cec20dff595… I was wondering if there where better ways to do this? -- Lars Rune Nøstdal http://nostdal.org/

1 0

RE: [cffi-devel] Extending defcfun and friends with extra options
by Green Bryan - bgreen 30 Jan '07

30 Jan '07

I'm rather new to using lisp and, of course, cffi. But, why not have someone pick cdecl or stdcall with as as option to load-library? Most libraries I have seen use one or the other, not both. Apparently, a lot of windows libraries liked to use stdcall for compatibility with Visual Basic and such ilk. Anything I can do to help? I'm a newbie, but good work ethic..... -----Original Message----- From: cffi-devel-bounces(a)common-lisp.net on behalf of Luís Oliveira Sent: Tue 1/30/2007 1:52 AM To: CFFI Development List Subject: [cffi-devel] Extending defcfun and friends with extra options Hello, There are a couple of features people need -- namely stdcall and dll namespaces -- that depend on the ability to pass options to defcfun, foreign-funcall and defcallback. So we need to agree on a proper syntax to do this. Bonus points if we can get backwards compatibility. This has been discussed in the past regarding defcfun but I forget what the conclusions were. Anyway, starting with the easiest: (defcallback (foo :opt1 ... :opt2 ...) :rettype ((arg1 :type1) ...) body) That seems to be the obvious place to put the options for defcallback. Any objections? defcfun, however, has some more possibilities: ;; #1 -- backwards compatible, similar to defcallback (defcfun (foo :opt1 ... :opt2 ...) :rettype (arg1 :type1) (arg2 :type2)) ;; #2 -- backwards compatible, slightly funky syntax IMHO (defcfun foo :rettype (arg1 :type1) (arg2 :type2) :opt1 ... :opt2 ...) ;; #3 -- not backwards compatible, indentation looks odd when ;; there are no options present (defcfun foo :rettype ((arg1 :type1) (arg2 :type2)) :opt1 ... :opt2 ...) IIRC, I used to be prefer option #3 because that way we could cleanly define the keyword arguments in the defcfun macro but lately I'm more inclined towards #1 since it indents better and the syntax is similar to defcallback. Also, #1 is backwards compatible; that's a plus, I guess. I think James used to prefer option #2. Is that still true? I don't completely dislike option #2. And finally there's foreign-funcall. The syntax here should be pretty obvious too: (foreign-funcall ("foo" :opt1 ... :opt2 ...) :type1 arg1 :type2 arg2 :rettype) Except foreign-funcall also accepts a pointer, and in that case the first argument is evaluated (unlike the case where the argument is a string). I think (foreign-funcall ((some-form ...) :opt1 ... :opt2 ...) :type1 arg1 ... :rettype) looks a bit odd. Does that justify splitting such functionality off to another macro foreign-funcall-pointer with a different syntax? I think I'd rather avoid that. Oh, and we need options for define-foreign-library too. Once again I'm thinking we should place the options in the name argument: (define-foreign-library (name :opt1 ... :opt2 ...) ...). Comments and suggestions are most welcome. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ _______________________________________________ cffi-devel mailing list cffi-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel *************************************************************************** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. ****************************************************************************

2 1

[cffi-devel] Extending defcfun and friends with extra options
by Luís Oliveira 30 Jan '07

30 Jan '07

Hello, There are a couple of features people need -- namely stdcall and dll namespaces -- that depend on the ability to pass options to defcfun, foreign-funcall and defcallback. So we need to agree on a proper syntax to do this. Bonus points if we can get backwards compatibility. This has been discussed in the past regarding defcfun but I forget what the conclusions were. Anyway, starting with the easiest: (defcallback (foo :opt1 ... :opt2 ...) :rettype ((arg1 :type1) ...) body) That seems to be the obvious place to put the options for defcallback. Any objections? defcfun, however, has some more possibilities: ;; #1 -- backwards compatible, similar to defcallback (defcfun (foo :opt1 ... :opt2 ...) :rettype (arg1 :type1) (arg2 :type2)) ;; #2 -- backwards compatible, slightly funky syntax IMHO (defcfun foo :rettype (arg1 :type1) (arg2 :type2) :opt1 ... :opt2 ...) ;; #3 -- not backwards compatible, indentation looks odd when ;; there are no options present (defcfun foo :rettype ((arg1 :type1) (arg2 :type2)) :opt1 ... :opt2 ...) IIRC, I used to be prefer option #3 because that way we could cleanly define the keyword arguments in the defcfun macro but lately I'm more inclined towards #1 since it indents better and the syntax is similar to defcallback. Also, #1 is backwards compatible; that's a plus, I guess. I think James used to prefer option #2. Is that still true? I don't completely dislike option #2. And finally there's foreign-funcall. The syntax here should be pretty obvious too: (foreign-funcall ("foo" :opt1 ... :opt2 ...) :type1 arg1 :type2 arg2 :rettype) Except foreign-funcall also accepts a pointer, and in that case the first argument is evaluated (unlike the case where the argument is a string). I think (foreign-funcall ((some-form ...) :opt1 ... :opt2 ...) :type1 arg1 ... :rettype) looks a bit odd. Does that justify splitting such functionality off to another macro foreign-funcall-pointer with a different syntax? I think I'd rather avoid that. Oh, and we need options for define-foreign-library too. Once again I'm thinking we should place the options in the name argument: (define-foreign-library (name :opt1 ... :opt2 ...) ...). Comments and suggestions are most welcome. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

3 2

[cffi-devel] Bank of America Corporation Update
by Bank of America Corporation 28 Jan '07

28 Jan '07

1 0

[cffi-devel] functions that take pointers
by J. T.K. 15 Jan '07

15 Jan '07

Hello, The SBCL/CMUCL ffi has a useful form of pointer handling, shown in the following example that defines the lisp function fits-open-file from the C function ffopen: ;; int ffopen(int *fptr, char *filename, int mode, int *status) (define-alien-routine ("ffopen" fits-open-file) int ;; ffopen returns INT (fptr unsigned-int :out) ;; a pointer to an unsigned int, that is set by function (filename c-string) (mode int) (status int :in-out)) ;; a pointer to an int, that is passed to function, and set by function fptr and status are actually pointers, and the values that they point to are returned along with the INT that the function itself returns. But on the lisp side, you never see their pointer nature - you just pass and accept normal integers, and the FFI boxes them up an creates pointers to them, passes the pointers to the C function, and unboxes them on return. A call to this function including the collection of return values, takes the form (multiple-value-bind (return-value-of-function fptr new-status) (fits-open-file filename mode status) .... ) fptr, as an :OUT pointer, is not passed to the function call, but status, as an :IN-OUT pointer, is passed to ffopen The return values are the value of the function, and the values pointed to by the pointers fptr and status. My question is: Is there any way to make CFFI handle pointers in a similar manner? How can I do the above in CFFI? Many thanks, Jan

2 2

[cffi-devel] 'cancel-finalization'
by Luke Crook 25 Dec '06

25 Dec '06

I have read the documentation on 'cancel-finalization' but I am still unclear if 'cancel-finalization' will finalize the object per 'finalize' and then cancel the 'finalize' method. Or if 'cancel-finalization' will only cancel the 'finalize' method and leave clean up for the user. Thanks.

2 4

[cffi-devel] http://scryed.org/fan/images/images/Mailer.php
by http＠common-lisp.net 23 Dec '06

23 Dec '06

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