SDL, UFFI and converting header files
Frank Buss
for Lispworks on Windows, but would be nice to port it later to Mac and
X11 on Unix as well, so I've installed UFFI. Then I've tried CL-SDL (
http://cl-sdl.sourceforge.net/ ) but it didn't compile, because it needs
some stub libraries and I don't have setup the C-compiler for ASDF in
Windows.
So I've tried AH2CL ( http://hocwp.free.fr/ah2cl/ ). The author writes:
"Ah2cl is a (very (very)) simple and naive C header parser" and he is
right :-) but with some manual bugfixing of the output I managed to write
a first test program, which uses SDL:
http://www.frank-buss.de/tmp/sdl-test.lisp.txt
With Lispworks I can compile it to an 1.1 MB standalone file, the SDL DLL
included:
http://www.mynetcologne.de/~nc-buszfr/sdl-test.zip
But I don't want to manual fix every second function generated by AH2CL
and I don't want stub libraries like CL-SDL uses, because it can be done
all in Lisp itself. It should be possible to include the headers and some
macros creates all the UFFI functions on-the-fly at read-time:
;; I just want to write this:
(include "sdl.h" "sdl.dll")
;; and then all functions and defines should be available:
(SDL_Init SDL_INIT_VIDEO)
I think I can write this, but I need a C-header-to-S-expression
converter, first. This converter should do the C-preprocessing as well. I
can write this, too, but I wonder if someone has already written
something like this.
--
Frank Buß, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Edi Weitz
> I want to use SDL ( http://www.libsdl.org ) from Lisp. First I need
> it for Lispworks on Windows, but would be nice to port it later to
> Mac and X11 on Unix as well, so I've installed UFFI. Then I've tried
> CL-SDL ( http://cl-sdl.sourceforge.net/ ) but it didn't compile,
> because it needs some stub libraries and I don't have setup the
> C-compiler for ASDF in Windows.
The CL-SDL download section on Sourceforge seems to offer pre-compiled
DLLs for Win32.
> But I don't want to manual fix every second function generated by
> AH2CL and I don't want stub libraries like CL-SDL uses, because it
> can be done all in Lisp itself.
According to the CL-SDL docs these stub files were introduced for
portability reasons. Have you read that?
> It should be possible to include the headers and some macros creates
> all the UFFI functions on-the-fly at read-time:
>
> ;; I just want to write this:
> (include "sdl.h" "sdl.dll")
> ;; and then all functions and defines should be available:
> (SDL_Init SDL_INIT_VIDEO)
>
> I think I can write this, but I need a C-header-to-S-expression
> converter, first. This converter should do the C-preprocessing as
> well. I can write this, too, but I wonder if someone has already
> written something like this.
If you don't care about portability (but why are you using UFFI then?)
there's the Lispworks foreign parser, there's a foreign parser that
comes with Corman Lisp, there's AllegroCL integration into SWIG,
there's Tim Moore's cparse for CMUCL, and there's probably more. None
of these fits the bill?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Marc Battyani
"Frank Buss" <f...@frank-buss.de> wrote
[...]
> So I've tried AH2CL ( http://hocwp.free.fr/ah2cl/ ). The author writes:
> "Ah2cl is a (very (very)) simple and naive C header parser" and he is
> right :-) but with some manual bugfixing of the output I managed to write
> a first test program, which uses SDL:
>
> http://www.frank-buss.de/tmp/sdl-test.lisp.txt
> I think I can write this, but I need a C-header-to-S-expression
> converter, first. This converter should do the C-preprocessing as well. I
> can write this, too, but I wonder if someone has already written
> something like this.
There is a C parser in Lispworks:
"The Foreign Parser automates the generation of Foreign Language Interface
defining forms, given files containing C declarations. "
Look at the FLI ref manual.
Marc
Frank Buss
> According to the CL-SDL docs these stub files were introduced for
> portability reasons. Have you read that?
yes. According to the STYLE-file one reason was draw-pixel, because it is
not possible to do a c-cast in UFFI. But at least with UFFI 1.4.31 you
can use with-cast-pointer. I didn't found any other portability issues,
but I didn't read all the sources.
The other reason was speed, but this is not important for my application
and I can optimize it later, after profiling where it is too slow.
> If you don't care about portability (but why are you using UFFI then?)
> there's the Lispworks foreign parser, there's a foreign parser that
> comes with Corman Lisp, there's AllegroCL integration into SWIG,
> there's Tim Moore's cparse for CMUCL, and there's probably more. None
> of these fits the bill?
I want a portable FFI. cparse looks interesting (the project page says
not, but the CVS repository README says, it supports UFFI), I'll try it.
Frank Buss
> There is a C parser in Lispworks:
> "The Foreign Parser automates the generation of Foreign Language
> Interface defining forms, given files containing C declarations. "
thanks, I've tried it, but it is not what I want, because it needs an
external preprocessor (on Windows it tries to call "cl /nologo /E /Tc
file.h") and it looks like it creates an external file instead of just
creating the functions on-the-fly and it doesn't generate UFFI.
Edi Weitz
> According to the STYLE-file one reason was draw-pixel, because it is
> not possible to do a c-cast in UFFI. But at least with UFFI 1.4.31
> you can use with-cast-pointer. I didn't found any other portability
> issues, but I didn't read all the sources.
That one was introduced by me for CL-GD, but only for LW, AllegroCL,
CMUCL, and SBCL. As far as I know it hasn't been ported to other UFFI
platforms like OpenMCL yet. The same applies to DEF-FOREIGN-VAR.
Andras Simon
There's also BINGE: http://wcp.sdf-eu.org/software/index.html
I haven't tried it (but I like the picture on the top of the page).
Andras
Matthew Danish
> Edi Weitz <spam...@agharta.de> wrote:
>
> > According to the CL-SDL docs these stub files were introduced for
> > portability reasons. Have you read that?
>
> yes. According to the STYLE-file one reason was draw-pixel, because it is
> not possible to do a c-cast in UFFI. But at least with UFFI 1.4.31 you
> can use with-cast-pointer. I didn't found any other portability issues,
> but I didn't read all the sources.
I haven't checked on the recent UFFI stuff. I do recall issues with
casting cross-platform, maybe that is fixed nowadays.
> The other reason was speed, but this is not important for my application
> and I can optimize it later, after profiling where it is too slow.
You can't get around the speed of draw-pixel if it was implemented in
CL and run in CLISP. That's just ridiculously slow for such a crucial
function. CMUCL did a decent job though, as good as gcc. The
definition should still be in there, but I doubt it'll be efficient on
anything else.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
David Steuber
OpenGL on OS X. I've used ffigen based on gcc 3.4.1 to parse header
files. I have written some Lisp code that takes that output and
generates Lisp files based on UFFI.
It doesn't work yet, but I think I'm getting somewhere.
OpenMCL's FFI does some clever things, but I am trying to be portable.
I also have a function to lispify the various function names. I was
hoping to be API compatible with CL-SDL's OpenGL stuff. I haven't hit
100% though. For example, I translate glRotatef into gl:rotatef.
CL-SDL uses gl:rotate-f. There are a few other names that don't match
up, but most do.
Another issue is that ffigen does not get the formal names for the
function arguments out of the header files. I think gcc-xml has the
same problem. It's something to do with the optional nature of arg
names in function prototypes I think. I may end up having to fix my
generated code by hand. I've got nearly 5000 lines of generated code.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Andy Cristina
very simple method from a very simple class.
<Method id="_13" name="setX" returns="_5" context="_4"
mangled="_ZN6simple4setXEi" location="f0:9" file="f0" line="9"
endline="11">
<Argument name="x" type="_6" />
</Method>
David Steuber
> Actually, gcc-xml does keep the argument names. Here is an example of
> a very simple method from a very simple class.
>
> <Method id="_13" name="setX" returns="_5" context="_4"
> mangled="_ZN6simple4setXEi" location="f0:9" file="f0" line="9"
> endline="11">
> <Argument name="x" type="_6" />
> </Method>
Cool. I wish I knew about gcc-xml sooner. I've been going through a
lot of pain trying to translate Apple's header files into Lisp code.
Andy Cristina
have to be surrounded in an extern C block. But its probably pretty
easy to add them.