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
On 2006-jan-09, at 09:30, Hoehle, Joerg-Cyril wrote:
(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])
I kind of like this way.
(define-foreign-library foo ...)
(use-foreign-library foo)
(defcvar "variable-in-library-foo")
(defcfun "function-in-library-foo" ...)
But, unfortunately, using this approach it might be easy to produce bindings that work in lisps that do global lookup and don't work on other lisps.
Regarding passing options to defcfun, my personal favourite is:
(defcfun "foo" :rettype ((arg1 :type1) (arg2 :type2)) :library bar :calling-convention xpto)
But I don't feel strongly about it. Either one of the options James sketched in his e-mail look good to me.
Also, define-foreign-library should probably be extended to take a calling convention argument 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.
-
Hoehle, Joerg-Cyril -
Luís Oliveira