The Common Lisp Application Builder project now has its own domain:
http://www.lispbuilder.org/
The CLISP patch for Windows is updated to the latest version 2.38 and with
the help of Surendra Singhi for the SWIG module and Justin Heyes-Jones for
the SDL mapping, now we have our first SDL test program on Windows, which
is end-user friendly (no console window, only 2 files to install).
Next steps will be finishing the SDL Lisp bindings, porting of some games
and creating a simple to use gaming package. If you want to help with the
project in general or discuss how the gaming package should look like, feel
free to subscribe to the mailing list.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Fri, 27 Jan 2006 05:38:28 +0100, Frank Buss <··@frank-buss.de> tried
to confuse everyone with this message:
>The Common Lisp Application Builder project now has its own domain:
>
>http://www.lispbuilder.org/
>
>The CLISP patch for Windows is updated to the latest version 2.38 and with
>the help of Surendra Singhi for the SWIG module and Justin Heyes-Jones for
>the SDL mapping, now we have our first SDL test program on Windows, which
>is end-user friendly (no console window, only 2 files to install).
>
>Next steps will be finishing the SDL Lisp bindings, porting of some games
>and creating a simple to use gaming package. If you want to help with the
>project in general or discuss how the gaming package should look like, feel
>free to subscribe to the mailing list.
>
Hmm... when I try to compile sdl.lisp it says:
FFI::FOREIGN-LIBRARY-FUNCTION: no dynamic object named "SDL_Init" in
library :DEFAULT
sdl1.exe doesn't work for me as well (no output at all). I'm on Windows
98 with the latest CLISP.
--
|WAR HAS NEVER SOLVED ANYTHING|,----- Timofei Shatrov aka Grue---------.
|(except for ending slavery, ||mail: grue at mail.ru ================ |
| fascism and communism) ||============= http://grue3.tripod.com |
|...and Saddam's dictatorship |`----------------------------------[4*72]
Timofei Shatrov wrote:
> Hmm... when I try to compile sdl.lisp it says:
>
> FFI::FOREIGN-LIBRARY-FUNCTION: no dynamic object named "SDL_Init" in
> library :DEFAULT
>
> sdl1.exe doesn't work for me as well (no output at all). I'm on Windows
> 98 with the latest CLISP.
This is a known problem, see
http://www.lispniks.com/pipermail/application-builder/2006-January/000016.html
My main system is Windows XP, where it works, perhaps someone in this
newsgroup can find the reason for the bug. I think it has something to do
with CFFI.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Timofei Shatrov wrote:
>
> > Hmm... when I try to compile sdl.lisp it says:
> >
> > FFI::FOREIGN-LIBRARY-FUNCTION: no dynamic object named "SDL_Init" in
> > library :DEFAULT
> >
> > sdl1.exe doesn't work for me as well (no output at all). I'm on Windows
> > 98 with the latest CLISP.
>
> This is a known problem, see
> http://www.lispniks.com/pipermail/application-builder/2006-January/000016.html
> My main system is Windows XP, where it works, perhaps someone in this
> newsgroup can find the reason for the bug. I think it has something to do
> with CFFI.
>
> --
> Frank Buss, ··@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de
I would look into it but I don't know anybody running Windows 98 any
more.
Justin
justinhj wrote:
> I would look into it but I don't know anybody running Windows 98 any
> more.
at least Timofei Shatrov uses it :-) But you are right, there are not many
people using it anymore. My web access log says that from the 1425097 hits
of the last few months to all my webpages there are 34221 hits from a
Windows 98 machine, which is 2.4 percent. But I have it installed in a
Microsoft Virtual PC environment and I'll try to find the reason for the
problem.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> But I have it installed in a
> Microsoft Virtual PC environment and I'll try to find the reason for the
> problem.
I think I've found the problem: CFFI uses foreign-library-function without
specifying a library, which caues CLISP to use EnumProcessModules from the
psapi.dll, which is not available in Windows 98. For these systems
CreateToolhelp32Snapshot can be used. I'll try it and I'll send a patch
proposal to the CLISP mailing list, if it works.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> I think I've found the problem: CFFI uses foreign-library-function without
> specifying a library, which caues CLISP to use EnumProcessModules from the
> psapi.dll, which is not available in Windows 98. For these systems
> CreateToolhelp32Snapshot can be used. I'll try it and I'll send a patch
> proposal to the CLISP mailing list, if it works.
Wouldn't the better idea to suggest to the CFFI mailing list to add
support for explicit modules, like CL-SDL does, like UFFI does?
Modules in CFFI has already been discussed a few times, but I forgot
what the implementation state is.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle wrote:
> Wouldn't the better idea to suggest to the CFFI mailing list to add
> support for explicit modules, like CL-SDL does, like UFFI does?
yes, this would be a good idea, but it is idependant of the bug in CLISP
for Windows 98.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Timofei Shatrov wrote:
> Hmm... when I try to compile sdl.lisp it says:
>
> FFI::FOREIGN-LIBRARY-FUNCTION: no dynamic object named "SDL_Init" in
> library :DEFAULT
>
> sdl1.exe doesn't work for me as well (no output at all). I'm on Windows
> 98 with the latest CLISP.
It was a bug in CLISP, I've updated the CLISP patch and the SDL test
project at lispbuilder.org, now it works on Windows 98, too.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> The Common Lisp Application Builder project now has its own domain:
> http://www.lispbuilder.org/
> the SDL mapping, now we have our first SDL test program on Windows,
It's my understanding that you're building upon CL-SDL.
Why? Why duplicate work? (Note that I've never tested whether CL-SDL
works on MS-Windows).
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle wrote:
> Why? Why duplicate work? (Note that I've never tested whether CL-SDL
> works on MS-Windows).
It uses UFFI, but I would like to use CFFI. And looks like the CFFI version
works good, at least in LispWorks and CLISP on Windows. CLISP is not
mentioned in the README of CL-SDL (maybe because CL-SDL is some years old
and UFFI CLISP support was not so good).
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Joerg Hoehle wrote:
>
> > Why? Why duplicate work? (Note that I've never tested whether CL-SDL
> > works on MS-Windows).
>
> It uses UFFI, but I would like to use CFFI. And looks like the CFFI version
> works good, at least in LispWorks and CLISP on Windows. CLISP is not
> mentioned in the README of CL-SDL (maybe because CL-SDL is some years old
> and UFFI CLISP support was not so good).
>
> --
> Frank Buss, ··@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de
Yes the goal of the project at least from my point of view is to
maintain a nice working SDL wrapper that runs on all CFFI and ASDF
friendly implementations. In addition it should be easy to regenerate
the headers when SDL releases a new version (since it uses an interface
file for SWIG).
Justin
Frank Buss <··@frank-buss.de> writes:
> > Why? Why duplicate work?
> It uses UFFI, but I would like to use CFFI.
CFFI has had a package uffi-compat since day 1 or so.
You could use that. Or rewrite the little that CL-SDL needs from UFFI
by providing an alternate file cl-sdl/ffi/xyz.lisp. CL-SDL has its
own FFI abstraction, not using UFFI directly.
IMHO, that's not good enough reason to reinvent the wheel.
I see too many reinvent the wheel in CL these days, and I believe such
efforts should better be spent building on top of something, not
reinventing the existing.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle wrote:
> Frank Buss <··@frank-buss.de> writes:
> > > Why? Why duplicate work?
> > It uses UFFI, but I would like to use CFFI.
>
> CFFI has had a package uffi-compat since day 1 or so.
>
> You could use that. Or rewrite the little that CL-SDL needs from UFFI
> by providing an alternate file cl-sdl/ffi/xyz.lisp. CL-SDL has its
> own FFI abstraction, not using UFFI directly.
>
> IMHO, that's not good enough reason to reinvent the wheel.
>
> I see too many reinvent the wheel in CL these days, and I believe such
> efforts should better be spent building on top of something, not
> reinventing the existing.
>
> Regards,
> Jorg Hohle
> Telekom/T-Systems Technology Center
There are a few reasons why I've reinvented the wheel
1) lispbuilder-sdl is part of the lispbuilder project and from that
point of view it's useful for us to own all the code and not have to
worry about making changes to cl-sdl which the authors don't like, nor
having to track the down if we have a question
2) cl-sdl has not been actively maintained since 2002, substantial
changes to opengl and sdl have no doubt occured in that time
3) We can build on a purely CFFI wrapper right from the start, and
don't have to worry about having CFFI built on UFFI built on FFI. There
are bound to be inefficiencies and clarity issues if we did that.
Building an interface that is purely CFFI from the start is a lot
cleaner.
4) By using Swig and it's CFFI output we can quickly adapt to new
versions of SDL as they are released.
Justin
justinhj wrote:
>
> 4) By using Swig and it's CFFI output we can quickly adapt to new
> versions of SDL as they are released.
Does the app builder distro include the steps/code required to
regenerate the bindings? I would like to see how that works.
kenny
Kenny Tilton wrote:
> justinhj wrote:
>
> >
> > 4) By using Swig and it's CFFI output we can quickly adapt to new
> > versions of SDL as they are released.
>
> Does the app builder distro include the steps/code required to
> regenerate the bindings? I would like to see how that works.
>
> kenny
Yes it does.
The README should have the steps but all that is required is to run
swig -cffi sdlswig.i
The sdlswig.i is the swig interface file for sdl, it details which sdl
include files to use and a bunch of conversions and lisp code that is
needed to make it all work.
Although swig and cffi still have some wrinkles and it's necessary to
go in and edit the SDL files right now to make some things work
correctly, the cffi/swig keeps moving forward and I expect pretty soon
the process will be entirely automatic.
Justin
justinhj wrote:
> Although swig and cffi still have some wrinkles and it's necessary to
> go in and edit the SDL files right now to make some things work
> correctly, the cffi/swig keeps moving forward and I expect pretty soon
> the process will be entirely automatic.
I don't think that this will be possible with SWIG for every C header file,
because for an automatic translation of macros like
"#define foo(x) (1<<(x))" you need to translate C code to Lisp code, not
only C header files. But it may be possible to automate the translation of
SDL with some SDL specific declarations in the SWIG interface file.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> justinhj wrote:
>
> > Although swig and cffi still have some wrinkles and it's necessary to
> > go in and edit the SDL files right now to make some things work
> > correctly, the cffi/swig keeps moving forward and I expect pretty soon
> > the process will be entirely automatic.
>
> I don't think that this will be possible with SWIG for every C header file,
> because for an automatic translation of macros like
> "#define foo(x) (1<<(x))" you need to translate C code to Lisp code, not
> only C header files. But it may be possible to automate the translation of
> SDL with some SDL specific declarations in the SWIG interface file.
>
> --
> Frank Buss, ··@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de
So far I've found that a lot of the stuff that doesn't automatically
work is not that useful anyway and I illiminate it from the SDL headers
using #ifndef SWIG statements.
One thing I could do is automate the process of patching the SDL
headers so that other users can take the interface file and make their
own sdl.lisp wrapper.
Is there a linux tool that calculates the differences between two sets
of files and produces a way of automatically patching between them?
Justin
justinhj wrote:
> Is there a linux tool that calculates the differences between two sets
> of files and produces a way of automatically patching between them?
yes, it's called "diff" and "patch". But this won't work with later
revisions of SDL, because the positions to patch might be different.
@Kenny: what about your C-to-Lisp translator? Does it understand all of C
and preprocessor directives?
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> justinhj wrote:
>
> > Is there a linux tool that calculates the differences between two sets
> > of files and produces a way of automatically patching between them?
>
> yes, it's called "diff" and "patch". But this won't work with later
> revisions of SDL, because the positions to patch might be different.
Of course, but I would just release a new patch when there is a new
release of sdl.
Frank Buss wrote:
> justinhj wrote:
>
>
>>Is there a linux tool that calculates the differences between two sets
>>of files and produces a way of automatically patching between them?
>
>
> yes, it's called "diff" and "patch". But this won't work with later
> revisions of SDL, because the positions to patch might be different.
>
> @Kenny: what about your C-to-Lisp translator? Does it understand all of C
> and preprocessor directives?
>
No, it is a total one-off with every failing that did not cost me much
effort to overcome. :)
But it worked off preprocessor output, so I did not have to worry about
that. The downside is that I used hundreds of macros to hide the gory
details of accessing "the wingy of the thingy of the dinghy", and I
liked the interface/readability of the macros, so I actually hid those
from the preprocessor and planned to translate manually.
Then I decided I coulkd rewrite the thing from scratch faster even with
the c2lisp translator and have been playing with Cells and LTk since
then (for the new GUI I would have been writing anyway).
But! You make a good point. It did occur to me that c2lisp could write
bindings as well, and even possibly figure out when a pointer was being
used as a null-terminated string (by looking beyond the header and into
the code.
btw, Verrazano/Fetter seems to have been abandoned by its developer.
Have not been able to get confirmation on that, though.
kenny
> btw, Verrazano/Fetter seems to have been abandoned by its developer.
> Have not been able to get confirmation on that, though.
>
Say it ain't so!! Is there anything that CLL and CL Gardiners
can/should do to keep Verrazano alive?
Brad
bradb wrote:
>>btw, Verrazano/Fetter seems to have been abandoned by its developer.
>>Have not been able to get confirmation on that, though.
>>
>
> Say it ain't so!!
It might not be. But messages to the vzn list are not responded to by
Rayiner, nor are my emails to him. Google tells me he is alive and well
and doing other things using the email address I have. But maybe I am
being sidetracked to a junk folder... well, there is still the vzn list
he should have seen.
> Is there anything that CLL and CL Gardiners
> can/should do to keep Verrazano alive?
I might know more after I try swigging a library. Perhaps that is
sufficient. I do not know if Vzn offers any advantage (or potential for
advantage) that Swig lacks. That is what the Gardeners should consider.
kenny
"justinhj" <········@gmail.com> writes:
[Note that I don't want to criticize you. I want to point at different
solution path.]
> 4) By using Swig and it's CFFI output we can quickly adapt to new
> versions of SDL as they are released.
That counters my experience. I find little values in thin bindings
compared to thick bindings (this is Ada terminology). Thin bindings is
what you get by direct translation. IMHO it tends to produce hundreds
of slightly inadequate and untested interface functions.
Inadequate because most API's reflect C idioms, whereas Lisp idioms
are very different.
E.g.
o error signaling (instead of weird -1|-2 return values)
o argument passing (:out pointer arguments etc.)
o agglutinating two functions (e.g. regexp length)
Thick bindings make you feel like programming in Lisp (or Ada), not in
C and makes the C API disappear.
E.g., I'd be happy to see a POSIX Lisp binding as a portable and
useable specification, rather than cffi-callable POSIX functions (or
CMUCL's UNIX package, or CLISP's POSIX package).
Take posix:execv as an example. I'd be happy to see it as either
(defun execv (pathname arguments)
"let arguments be some sequence of strings"
or
(defun execv (pathname &rest arguments)
I haven't seen an automated .h file parser which would produce that.
Summary of my position: automated translation gives you little on the
way of providing a good Lisp API.
> There are a few reasons why I've reinvented the wheel
> 1) [...] it's useful for us to own all the code and not [...]
Hmm.. CPAN users, Pythonists etc. seem very happy with not owning all
the code and using libraries. Why do they rely on each other, whereas
"own the code" to me rhymes with "distrust of other people's work"?
> 2) cl-sdl has not been actively maintained since 2002, substantial
> changes to opengl and sdl have no doubt occured in that time
Alternative: take over a promising project.
> 3) We can build on a purely CFFI wrapper right from the start, and
> don't have to worry about having CFFI built on UFFI built on FFI. There
> are bound to be inefficiencies and clarity issues if we did that.
IMHO no more than by choosing to use CFFI instead of the
implementations native's FFI. Where's the performance guarantee?
A priori, one would expect worse performance from every additional
macro layer. Exceptions to the rule are possible.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
From: Alexander Schmolck
Subject: Re: Common Lisp Application Builder news
Date:
Message-ID: <yfsslqnuisg.fsf@oc.ex.ac.uk>
Joerg Hoehle <······@users.sourceforge.net> writes:
> "justinhj" <········@gmail.com> writes:
> [Note that I don't want to criticize you. I want to point at different
> solution path.]
>
> > 4) By using Swig and it's CFFI output we can quickly adapt to new
> > versions of SDL as they are released.
>
> That counters my experience. I find little values in thin bindings
> compared to thick bindings (this is Ada terminology).
Why not go for a hybrid approach: provide some low-level interface (say
cl-raw-sld), which closely mirrors the C-API and is mostly auto-generated and
hence can be easily kept up to date and then build some more labor intensive
high-level bindings (say cl-sdl) on top of that.
If someone needs some cutting edge functionality they might have to put up
with using the unpleasant low-level bindings for that till someone finds the
time to add that functionality to the high-level interface. That still beats
not being able to use it all. Also, if the functionality is already there,
albeit in yucky form, and all that is needed for a nicer interface is some
lisp programming, there is a higher chance that users contribute to missing
high-level bindings than if they'd also had to muck around with FFI.
> E.g., I'd be happy to see a POSIX Lisp binding as a portable and
> useable specification, rather than cffi-callable POSIX functions (or
> CMUCL's UNIX package, or CLISP's POSIX package).
>
> Take posix:execv as an example. I'd be happy to see it as either
> (defun execv (pathname arguments)
> "let arguments be some sequence of strings"
> or
> (defun execv (pathname &rest arguments)
>
> I haven't seen an automated .h file parser which would produce that.
I really care much more about having some widely available and reasonably
complete set of posix bindings sooner rather than later. IMO a nice interface
can follow. I'd certainly be much more motiviated to contribute to the latter
than to the former.
> Summary of my position: automated translation gives you little on the
> way of providing a good Lisp API.
I think it does by lowering the threshold for contribution.
'as
Alexander Schmolck wrote:
> Why not go for a hybrid approach: provide some low-level interface (say
> cl-raw-sld), which closely mirrors the C-API and is mostly auto-generated and
> hence can be easily kept up to date and then build some more labor intensive
> high-level bindings (say cl-sdl) on top of that.
Some ideas for a higher-level package were discussed on the mailing list at
http://www.lispniks.com/mailman/listinfo/application-builder
If you provide a "thick" binding it may be the wrong binding, but with a
"thin" binding you have access to every single library function and on top
of this more Lisp-like bindings can be built.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Joerg Hoehle wrote:
> "justinhj" <········@gmail.com> writes:
> [Note that I don't want to criticize you. I want to point at different
> solution path.]
Yep, and all your comments are appreciated
> Summary of my position: automated translation gives you little on the
> way of providing a good Lisp API.
The way the project is shaping up I have sdl.lisp which is the thin
layer (which is semi-automatic right now until swig and cffi become
omnipotent and can produce perfect bindings).
There is a little lisp that gets output from swig which I put in the
interface file. This contains some very basic lisp code to load the
foreign library.
Then I have util.lisp which is a thicker layer bindings with functions
and macros for common lisp, which give you an interface to SDL which
looks like lisp but is thin enough that you can intermingle direct SDL
function calls and referecce SDL variables.
This is quite a good starting point, I feel, for further development.
You can look at a piece of C code that works with SDL directly and see
a direct analog in the lisp port.
What we will be building with this library is going to be far more
lispy and thick, but anything you want to do that uses SDL should be
possible with the bare library.
> > There are a few reasons why I've reinvented the wheel
> > 1) [...] it's useful for us to own all the code and not [...]
> Hmm.. CPAN users, Pythonists etc. seem very happy with not owning all
> the code and using libraries. Why do they rely on each other, whereas
> "own the code" to me rhymes with "distrust of other people's work"?
>
> > 2) cl-sdl has not been actively maintained since 2002, substantial
> > changes to opengl and sdl have no doubt occured in that time
> Alternative: take over a promising project.
>
> > 3) We can build on a purely CFFI wrapper right from the start, and
> > don't have to worry about having CFFI built on UFFI built on FFI. There
> > are bound to be inefficiencies and clarity issues if we did that.
> IMHO no more than by choosing to use CFFI instead of the
> implementations native's FFI. Where's the performance guarantee?
> A priori, one would expect worse performance from every additional
> macro layer. Exceptions to the rule are possible.
I accept all your points as being valid, but generating the thin layer
is done already. I'll be using cl-sdl as a guide as I add things that
they already have, but I don't see significant overlap.
Justin
"justinhj" <········@gmail.com> writes:
> The way the project is shaping up I have sdl.lisp which is the thin
> layer [...] Then I have util.lisp which is a thicker layer bindings
Another gripe of mine is unnecessary bloat and confusion.
Suppose there's C-READLINK which takes pointers etc. as specified by
the readlink(2) manpage.
Then there's READLINK which has a nice Lisp API
(defun readlink (path) -> path or signal posix-error
My point is: nobody ever wants to use C-READLINK. Its mere presence is
detracting users from the right function.
Furthermore, the thin function is superfluous in several implementations:
o E.g. cmucl:
(defun readlink (path)
(with-alien "readlink" (...))
cmucl does not need a top-level foreign-function definition. Years
ago, I found embedded definitions a cleaner way to interface to C
stuff (and I got fewer warnings about conversions and did not fear
somebody calling directly the low-level and crashing the application).
o E.g. clisp:
clisp has so many ready-made FFI conversion operators that starting
again from opaque pointers and rewriting everything from there is akin to
Greenspun's 10th law. CFFI is slowly reintroducing some of them (e.g. string).
A foreign function defined to take a :c-string as argument expects a
Lisp string and will barf when given an opaque pointer.
Possibly my concerns are those of and old player who's still looking
at memory consumption and a clean list of packages. ASDF screws up.
Past times? My current laptop has 200 times the RAM of the Amiga where
my first CLISP ran in 1992.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle wrote:
> "justinhj" <········@gmail.com> writes:
> Possibly my concerns are those of and old player who's still looking
> at memory consumption and a clean list of packages. ASDF screws up.
> Past times? My current laptop has 200 times the RAM of the Amiga where
> my first CLISP ran in 1992.
>
I think what is distracting to a C programmer who wants to try and use
SDL from lisp is not having a few functions wrapped that he will never
use, but having to learn a thick layer of lisp that he may not even
understand right away, to port over his C SDL code.
If you thought running CLISP was fun in 1992 on the Amiga you can
imagine the fun I had running SBProlog on the same machine a few years
before that :-)
As for bloat, when I started writing video games assembler was the only
option. Then I watched as C came in, and many old assembler hacks
thought C would never be fast enough. Then C++, same arguments. We'll
be using C# in a few years no doubt, because I'm already starting to
hear people say that it's too slow for games.
Justin
justinhj wrote:
> Joerg Hoehle wrote:
>
>>"justinhj" <········@gmail.com> writes:
>>Possibly my concerns are those of and old player who's still looking
>>at memory consumption and a clean list of packages. ASDF screws up.
>>Past times? My current laptop has 200 times the RAM of the Amiga where
>>my first CLISP ran in 1992.
>>
>
>
> I think what is distracting to a C programmer who wants to try and use
> SDL from lisp is not having a few functions wrapped that he will never
> use, but having to learn a thick layer of lisp that he may not even
> understand right away, to port over his C SDL code.
Why do you think the layer will be either thick or hard to understand? I
do not know this particular wrapper package, but I am willing to bet
you are wrong on both scores.
My opengl code would be recognizable to any C opengl programmer. Same
API: same functions, same arguments (of course). Just the occasional
Lisp nicety, a macro sparing the developer needless effort because the
macro can take care of repetitive housekeeping. And no agonizing over
datatypes. etc, etc.
kenny
Kenny Tilton wrote:
> Why do you think the layer will be either thick or hard to understand? I
> do not know this particular wrapper package, but I am willing to bet
> you are wrong on both scores.
>
> My opengl code would be recognizable to any C opengl programmer. Same
> API: same functions, same arguments (of course). Just the occasional
> Lisp nicety, a macro sparing the developer needless effort because the
> macro can take care of repetitive housekeeping. And no agonizing over
> datatypes. etc, etc.
>
> kenny
I'm not sure what you're arguing against. We've got working wrappers
around the SDL library that sound exactly like your opengl ones your'e
describing.
I'd invite people with an opinion to come along to the application
builder mailing list and share them there.
Justin
Kenny Tilton wrote:
> Why do you think the layer will be either thick or hard to understand? I
> do not know this particular wrapper package, but I am willing to bet
> you are wrong on both scores.
>
> My opengl code would be recognizable to any C opengl programmer. Same
> API: same functions, same arguments (of course). Just the occasional
> Lisp nicety, a macro sparing the developer needless effort because the
> macro can take care of repetitive housekeeping. And no agonizing over
> datatypes. etc, etc.
>
> kenny
I'm not sure what you're arguing against. We've got working wrappers
around the SDL library that sound exactly like your opengl ones you're
describing.
I'd invite people with an opinion to come along to the application
builder mailing list and share them there.
Justin
justinhj wrote:
> Kenny Tilton wrote:
>
>>Why do you think the layer will be either thick or hard to understand? I
>> do not know this particular wrapper package, but I am willing to bet
>>you are wrong on both scores.
>>
>>My opengl code would be recognizable to any C opengl programmer. Same
>>API: same functions, same arguments (of course). Just the occasional
>>Lisp nicety, a macro sparing the developer needless effort because the
>>macro can take care of repetitive housekeeping. And no agonizing over
>>datatypes. etc, etc.
>>
>>kenny
>
>
> I'm not sure what you're arguing against. We've got working wrappers
> around the SDL library that sound exactly like your opengl ones you're
> describing.
Oh. Sorry, I did not look at who wrote it, I just read what you wrote:
> I think what is distracting to a C programmer who wants to try and use
> SDL from lisp is not having a few functions wrapped that he will never
> use, but having to learn a thick layer of lisp that he may not even
> understand right away, to port over his C SDL code.
That (without the context of you being the SDL author) sounds like
"[with] SDL [one has to] learn a thick layer...".
Now I can parse it as: "What would have been disconcerting (had we done
it, which we did not)..."
:)
kenny
Kenny Tilton wrote:
> Now I can parse it as: "What would have been disconcerting (had we done
> it, which we did not)..."
>
Heh. sorry for the confusion ;)
I have looked on the zipped files with message example on the pages,
and seing two small files recalled my recent experiments with bat/cmd
files with lisp inside - it appears that windows conventiently ignore ;
at the beginning of line, so you can have content below in bat/cmd file
and it works. It may be sometimes convenient replacement of long
escaped -x parameter, and it is also quite trivial to have the lisp
part compiled there.
Not that I would have anything against your version, I just thought
this is not so widely known and maybe worthy mentioning.
Anybody knows whether ignoring ; is documented feature on all versions
of windows or just something obscure?
To the original topic, I like the patch. :)
Regards,
Tomas
Sample .cmd file:
; lisp -M lispinit.mem -i %0
; exit
(use-package "FFI")
(def-call-out messagebox
(:name "MessageBoxA") (:library "user32.dll")
(:arguments (hwnd int) (text c-string) (capt c-string)
(type uint))
(:return-type int)
(:language :stdc))
(defun main()
(messagebox 0 "Hello World!" "Message" 0)
(quit))
(ext:saveinitmem "message" :init-function #'main :executable t :norc t)
> Anybody knows whether ignoring ; is documented feature on all versions
> of windows or just something obscure?
';' is just a sequencing operator like in most Unix shells: "cmd1;
cmd2"
will execute `cmd1' and then `cmd2', sequentially.