I have
(cffi:define-foreign-library sdl-glue (:windows "lispbuilder-sdl-glue.dll"))
(use-foreign-library sdl-glue)
On Linux, this returns fine, although it doesn't load any library. I see code in lispbuilder-sdl that relies on it signaling an error. Is it a regression ?
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
If the glue library is available then *lispbuilder-sdl-audio* is added to *features*. If *lispbuilder-sdl-audio* is not available then you have to use lispbuilder-sdl-mixer for sound. Right now the sdl-glue library has been built for Windows only. I still have to create a makefile for linux.
The glue library wraps the SDL audio callback thread. The main SDL process creates a helper thread to handle audio which performs a callback when the audio buffer needs to be filled. This new audio thread is 'unknown' to the Lisp environment (Lisp knows about the SDL process, but not any threads SDL creates). Thus when this 'unknown' audio thread performs the callback into the Lisp process, the Lisp process will most likely crash.
The sdl-glue library wraps the audio part of SDL so that the audio thread calls back into the glue library and not the Lisp process. During each iteration of the game loop the Lisp process asks sdl-glue if the audio buffer is empty, writing audio data into an internal sdl-glue bufffer if necessary. sdl-glue copies audio data from its internal buffer into the SDL audio buffer during the audio callback.
It seems that Lispworks and Corman Lisp are OK handling 'unknown' threads. But SBCL and CLISP will crash, hence the need for this glue library.
- Luke
On Tue, Dec 22, 2009 at 7:27 AM, Stelian Ionescu sionescu@cddr.org wrote:
I have
(cffi:define-foreign-library sdl-glue (:windows "lispbuilder-sdl-glue.dll"))
(use-foreign-library sdl-glue)
On Linux, this returns fine, although it doesn't load any library. I see code in lispbuilder-sdl that relies on it signaling an error. Is it a regression ?
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
If the glue library is available then *lispbuilder-sdl-audio* is added to *features*. If *lispbuilder-sdl-audio* is not available then you have to use lispbuilder-sdl-mixer for sound. Right now the sdl-glue library has been built for Windows only. I still have to create a makefile for linux.
The point is that your code relies on use-foreign-library signaling an error if the glue library cannot be loaded, but that's not the same thing as it non being there.
On Linux, use-foreign-library returns fine even if the library doesn't exist which means that :lispbuilder-sdl-audio is always pushed to *features* and that causes errors about undefined alien functions when running examples.
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
Ah... That explains a few bugs I've been seeing. Thank you.
Stelian Ionescu <sionescu <at> cddr.org> writes:
If the glue library is available then *lispbuilder-sdl-audio* is added to *features*. If *lispbuilder-sdl-audio* is not available then you have to use lispbuilder-sdl-mixer for sound. Right now the sdl-glue library has been built for Windows only. I still have to create a makefile for linux.
The point is that your code relies on use-foreign-library signaling an error if the glue library cannot be loaded, but that's not the same thing as it non being there.
On the other hand, I would be interested in understanding how a non-exist library library can be loaded successfully :)
On Linux, use-foreign-library returns fine even if the library doesn't exist which means that :lispbuilder-sdl-audio is always pushed to *features* and that causes errors about undefined alien functions when running examples.
Isn't this a bug in CFFI?
- Luke
On Tue, Dec 22, 2009 at 3:27 PM, Stelian Ionescu sionescu@cddr.org wrote:
(cffi:define-foreign-library sdl-glue (:windows "lispbuilder-sdl-glue.dll"))
(use-foreign-library sdl-glue)
On Linux, this returns fine, although it doesn't load any library. I see code in lispbuilder-sdl that relies on it signaling an error. Is it a regression ?
No, this was the intended behaviour. I can see why making it work more like ECASE instead of CASE might be desirable, though I'm not sure it's worth breaking backwards compatibility. I'm all ears to compelling arguments, though. :-)
Luís Oliveira <luismbo <at> gmail.com> writes:
On Tue, Dec 22, 2009 at 3:27 PM, Stelian Ionescu <sionescu <at> cddr.org>
wrote:
(cffi:define-foreign-library sdl-glue (:windows "lispbuilder-sdl-glue.dll"))
(use-foreign-library sdl-glue)
On Linux, this returns fine, although it doesn't load any library. I see code in lispbuilder-sdl that relies on it signaling an error. Is it a regression ?
No, this was the intended behaviour. I can see why making it work more like ECASE instead of CASE might be desirable, though I'm not sure it's worth breaking backwards compatibility. I'm all ears to compelling arguments, though.
lispbuilder-sdl and lispbuilder-sdl-ttf conditionally load different CFFI forms depending on the availability of a particular library.
For example, if the lispbuilder-sdl-ttf-glue.dll is available then the corresponding CFFI glue forms are conditionally loaded. If this library is unavailable, then different CFFI code will fake out passing the SDL_Color struct by value by passing a packed integer instead.
Similarly, if lispbuilder-sdl-glue.dll is available, then basic sound loading and mixing support is enabled directly from lispbuilder-sdl. If the library is not available, then this basic sound support is enabled only for Lispworks because Lispworks can handle 'unknown' threads.
Is there a mechanism in CFFI to enable this if define-foreign-library cannot be used?
- Luke
On Wed, Dec 23, 2009 at 1:11 AM, Luke J Crook luke@balooga.com wrote:
lispbuilder-sdl and lispbuilder-sdl-ttf conditionally load different CFFI forms depending on the availability of a particular library.
[...]
Is there a mechanism in CFFI to enable this if define-foreign-library cannot be used?
If you really want it to signal an error, you could add a clause such as (t (:or)). E.g.:
(define-foreign-library sdl-glue (:windows "lispbuilder-sdl-glue.dll") (t (:or)))
In this case, I suppose you could also do something like:
(defparameter *glue-loaded-p* #+windows t #-windows nil)
Or, perhaps even better:
(defparameter *glue-loaded-p* (foreign-library-loaded-p 'sdl-glue))
Luís Oliveira <luismbo <at> gmail.com> writes:
On Wed, Dec 23, 2009 at 1:11 AM, Luke J Crook <luke <at> balooga.com> wrote:
Is there a mechanism in CFFI to enable this if define-foreign-library
cannot be used?
(defparameter *glue-loaded-p* (foreign-library-loaded-p 'sdl-glue))
I'll use this.
Thanks. - Luke
On Tue, Dec 22, 2009 at 10:03 PM, Luís Oliveira luismbo@gmail.com wrote:
Or, perhaps even better:
(defparameter *glue-loaded-p* (foreign-library-loaded-p 'sdl-glue))
Is the proposal to add foreign-library-loaded-p to cffi?
- Luke
On Thu, Dec 24, 2009 at 3:18 AM, Luke Crook luke@balooga.com wrote:
(defparameter *glue-loaded-p* (foreign-library-loaded-p 'sdl-glue))
Is the proposal to add foreign-library-loaded-p to cffi?
Stelian added it to the repository some months ago. It's not yet in a release.
-
Luke Crook -
Luke J Crook
-
Luís Oliveira -
Stelian Ionescu