cffi-devel January 2007

cffi-devel@common-lisp.net

7 participants
5 discussions

[cffi-devel] cffi-clisp.lisp multiple-value-bind usage of variable "error" conflicts with another package
by Fred Stone 14 Feb '07

14 Feb '07

I am attempting to use cffi on a Clisp 2.41 build running under Cygwin. I can get cffi to load using asdf, but when I loaded a package that uses cffi, I got an error message "ERROR is a constant: may not be used as a variable". In cffi-clisp.lisp, around line 234; (multiple-value-bind (ff error) ... is causing the problem. I patched this to: (multiple-value-bind (ff fferror) and also corrected the subsequent two references to error on lines 249 and 250 and managed to get past this particular problem. In trying to localize the source of the name conflict, it appears that one of the optional modules that I have included in Clisp is the source of the conflit. These would include GDI, PCRE, RAWSOCK, LDAP, FASTCGI or ZLIB. The BASE build without the optional modules didn't have the name conflict, while the FULL build does. I have not determined which of the modules above was defining the constant "error".

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel January 2007