Re: [cffi-devel] Problem with SDL_Init using CFFI with Clisp in W indows 98
Hi, Jeremy Smith wrote:
CFFI-based SDL module does not work on Windows 98 under Clisp. I just tested it on my Windows 98 laptop (P166 :-) and it says the same thing. "FFI: FOREIGN-LIBRARY-FUNCTION: No dynamic object named 'SDL_Init' in library :DEFAULT"
I've a different opinion from James :) The one difference I see is that your CLISP code explicitly mentions the library to look after. That is the most portable way and the way I recommend, even for UNIX. It's precise, and you won't get hit by name clashes (e.g. Yaroslav Kavenchuk found duplicate sprintf across MS-Windows .dlls, one crashes, the other not... Which one you get depends on the order in which the system opened libraries, AFAIK it's not even controlled by CLISP.) CFFI does not provide such a mechanism. There has been some recent work in that area, e.g. define-foreign-library and use-foreign-library. But it still seems (or my darcs copy is too old) that CFFI is not at the point where it can say for each function, or at the top of a file defining functions, "this/these belong/s to library XYZ". Please correct me if I'm wrong and this is antinews. W.r.t. CLISP: o In MS-Windows >98, constantly using :library :default should work (clisp will scan all open libraries, you bet this takes time). o On Linux, CLISP was patched last year to make :library :default so that it would scan all libraries (to help people (e.g. CFFI users) *and* to work around bugs in other software, e.g. incomplete library dependencies). o Doesn't Frank Buss got a patch to make MS-Windows-98 work (I lost track of it)? However, if MS-Windows-98 does not have means to inspect dlls for symbols (e.g. psapi.dll), then I don't see how this can be patched. You can try to find a psapi.dll for MS-windows98?? You could only modify CFFI to emit a (:library *my-library*) into the code from defcfun and the above mentioned cffi:use-foreign-library to set that variable. IMHO, the problem is with CFFI, not CLISP. Lispworks would also benefit from using module names. My bet/hope is that this is just a matter of time and volunteers to write code, and CFFI will behave nicely :-) Modules and the like have already been discussed in this list, here and there. But we need people like you to complain to make discussions progress to real code! Regards, Jorg Hohle.
Jorg Hohle wrote:
o Doesn't Frank Buss got a patch to make MS-Windows-98 work (I lost track of it)?
Yes, I have patched it: http://sourceforge.net/mailarchive/message.php?msg_id=14620889 The compiled CLISP version, but without command line support, is available at http://www.lispbuilder.org/ -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
"Hoehle, Joerg-Cyril" wrote:
Hi,
Jeremy Smith wrote:
CFFI-based SDL module does not work on Windows 98 under Clisp. I just tested it on my Windows 98 laptop (P166 :-) and it says the same thing. "FFI: FOREIGN-LIBRARY-FUNCTION: No dynamic object named 'SDL_Init' in library :DEFAULT"
Sorry folks, I looked on the web for 'cffi-devel' and all I could find was the list's email address in 3d letters! No subscribe information. So I emailed that. It doesn't help that it's called "Aphora" or something, when people are looking for cffi. Anyway, I thought the email had got lost in the system, so I didn't give an update. It just popped up on the list one day, and I didn't have time to refute it. The update is, Frank Buss has fixed the problem in Clisp, but there are still issues with CFFI not specifying DLL names explicitly. Cheers, Jeremy. -- | Jeremy Smith BSc (Hons) | Chief Scientist, Decompiler Technologies | Member, British Computer Society | England
Joerg, Jeremy, at this time with the current cffi sdl file I created for a small project I'm adding manually the following line (load-foreign-library "libSDL.so") after the (in-package #:sdl) in your windows platform you should add your dll, not the so file. I suspect you should add the dll to your DLL PATH to allow cffi to find it. In unix I can write a fullpath to the library to make it work in any directory but I don't know if it will work in windows. Regards, rogersm. Hoehle, Joerg-Cyril wrote:
Hi,
Jeremy Smith wrote:
CFFI-based SDL module does not work on Windows 98 under Clisp. I just tested it on my Windows 98 laptop (P166 :-) and it says the same thing. "FFI: FOREIGN-LIBRARY-FUNCTION: No dynamic object named 'SDL_Init' in library :DEFAULT"
I've a different opinion from James :) The one difference I see is that your CLISP code explicitly mentions the library to look after. That is the most portable way and the way I recommend, even for UNIX. It's precise, and you won't get hit by name clashes (e.g. Yaroslav Kavenchuk found duplicate sprintf across MS-Windows .dlls, one crashes, the other not... Which one you get depends on the order in which the system opened libraries, AFAIK it's not even controlled by CLISP.)
CFFI does not provide such a mechanism. There has been some recent work in that area, e.g. define-foreign-library and use-foreign-library. But it still seems (or my darcs copy is too old) that CFFI is not at the point where it can say for each function, or at the top of a file defining functions, "this/these belong/s to library XYZ". Please correct me if I'm wrong and this is antinews.
W.r.t. CLISP: o In MS-Windows >98, constantly using :library :default should work (clisp will scan all open libraries, you bet this takes time). o On Linux, CLISP was patched last year to make :library :default so that it would scan all libraries (to help people (e.g. CFFI users) *and* to work around bugs in other software, e.g. incomplete library dependencies).
o Doesn't Frank Buss got a patch to make MS-Windows-98 work (I lost track of it)? However, if MS-Windows-98 does not have means to inspect dlls for symbols (e.g. psapi.dll), then I don't see how this can be patched. You can try to find a psapi.dll for MS-windows98??
You could only modify CFFI to emit a (:library *my-library*) into the code from defcfun and the above mentioned cffi:use-foreign-library to set that variable.
IMHO, the problem is with CFFI, not CLISP. Lispworks would also benefit from using module names. My bet/hope is that this is just a matter of time and volunteers to write code, and CFFI will behave nicely :-) Modules and the like have already been discussed in this list, here and there. But we need people like you to complain to make discussions progress to real code!
Regards, Jorg Hohle. _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Hi, I have a question about Lisp macros. I'm currently reading On Lisp, which is the classic text on them, but I'm only 1/4 of the way through. I know the CFFI developers have got the whole FFI macro thing down cold. I have the following callback code: (cffi:defcallback mbox-add-field :pointer ((self :pointer) (args :pointer)) (cffi:with-foreign-pointer (buf 255) (cffi:with-foreign-pointer (val 255) (cffi:foreign-funcall "PyArg_ParseTuple" :pointer args :string "ss" :pointer buf :pointer val) (mbox-add-field (cffi:foreign-string-to-lisp (cffi:mem-ref buf :string)) (cffi:foreign-string-to-lisp (cffi:mem-ref val :string))) ) ) (py_buildvalue "s" "")) This callback is retrieved with this code: (cffi:get-callback ,callback) I have 2 questions, one specific to Python. *How do I create a callback with a gynsym'd symbol, which actually refers to a lambda expression and not a defun'd function? The %callback thing seems hard-wired to specifically naming it with a symbol, and creating a global scope for it, which is okay as long as I can create non-clashing lambda's. *The Python specific one is: Given a function which takes the following definition: (defpy add-field(string: key string: value) (setf (gethash key *map*) value) (gethash key *map*)) And would expand to this: (cffi:defcallback add-field :pointer ((self :pointer) (args :pointer)) (cffi:with-foreign-pointer (key 255) (cffi:with-foreign-pointer (value 255) (cffi:foreign-funcall "PyArg_ParseTuple" :pointer args :string "ss" :pointer key :pointer value) (setf (gethash (cffi:foreign-string-to-lisp (cffi:mem-ref key :string)) *map* (cffi:foreign-string-to-lisp (cffi:mem-ref value :string))) ) ) (py_buildvalue "s" "")) That is: It calls ParseTuple to get its args, which is a multi-arg FFI function, and are defined in a string, "s" for string, "l" for long, and so on. Then it uses the foreign-string-to-lisp to call mem-ref to deferefence the pointer to the string that Python returns (and Python frees it up, not the caller). I guess I should ask about macro stuff like this on comp.lang.lisp, but I thought I'd try here first, as it's more specific to CFFI. Thanks, Jeremy.
Jeremy Smith <jeremy@decompiler.org> writes:
I have 2 questions, one specific to Python.
*How do I create a callback with a gynsym'd symbol, which actually refers to a lambda expression and not a defun'd function? The %callback thing seems hard-wired to specifically naming it with a symbol, and creating a global scope for it, which is okay as long as I can create non-clashing lambda's.
I'm not sure what you want here. You can write a macro that expands into a defcallback with a name created by gensym. (defmacro foo (....) `(defcallback ,(gensym) (...) ...)) What exactly do you want to do?
*The Python specific one is: Given a function which takes the following definition:
Did you forget to actually ask the question? I couldn't understand what the question was. -- Luís Oliveira luismbo (@) gmail (.) com Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
participants (5)
-
Frank Buss -
Hoehle, Joerg-Cyril -
Jeremy Smith -
Luís Oliveira -
Roger Sen Montero