SLAYER announcement and help request for preparing a GNU package

SLAYER announcement and help request for preparing a GNU package

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 3147 bytes --]

Hi everyone,
I've developed a piece of software that I named SLAYER, by combining the
letter 's' with the word "layer", or replacing the 'p' letter with 's' in
the word 'player'.

Either way, slayer can be thought of as a simpler alternative for wrapper
libraries such as guile-sdl and guile-opengl, or as a programming
environment that is in a way competetive to Adobe Flash (with standalone
player). But obviously, it is something completely different.

I made this program as a base for research in GUI design, but it also
contains a stub of a 3d game engine that I'm planning to implement -- which
explains native support for OpenGL. I recently thought that it also could
be a great platform for teaching kids to program games, because -- once
compiled and linked -- it could be distributed as a standalone package,
that requires no additional tools.

The program is available through mercurial on bitbucket:

hg clone https://bitbucket.org/panicz/slayer

The repository contains README file, which lists packages that are needed
to build. Except a little mess, there are two demos that show the
possibilities of the system. The first one with the command:

$ ./slayer -e3d

The -e3d option is needed to enable the "3d" extension, which is required
by the demo. It allows to move around in a 3d space using mouse and WSAD
keys. There's also a draggable icon and a simple text-console, which
accepts s-expressions (evaluated using f1 key). It is activated with a
click, but for some reason the cursor isn't always displayed. The source
file is slayer.scm.

The second demo is the classical arcade PONG game (for two players). It's
written in the raw guile+slayer, so it's pretty lengthy (~160 lines), but
it should be easily understandable. PONG can be run using
$ ./slayer -i pong.scm

Both demos use sound, which can be disabled by passing the --nosound option
in the command line. PONG can also receive the -e3d option, which would
force it to use opengl for display.

Other command line options are undocumented, but they can be easily found
in slayer.c. I admit that the lack of any documentation can now be the most
seriously discouraging factor, but I promise to respond to every question
eagerly.

The second most seriously discouraging factor would be the build process,
which could require manual editing of the Makefile, among others. It would
be lovely to use the GNU autotools, but they seem so complicated, and I
thought that since you might have more experience with those, you could
help me to prepare a decent release, and perhaps to reorganize the
structure of the source code.

Perhaps the third most seriously discouraging factor (except some random
crashes that still happen) would be the lack of certain features: I'm
trying to apply the 'lazy implementation' strategy and add SDL/OpenGL
features only as I need them, and also my priority is to keep interfaces
simple, even at the cost of programmer's freedom (so for instance, there's
no option for choosing color index mode in OpenGL, or some other SDL video
mode than the default).

Despite those factors, I'd be happy to hear some feedback from you.

Best regards,
M.

[-- Attachment #2: Type: text/html, Size: 4217 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 4782 bytes --]

It sounds like an interesting project.

The subject line of your post says it is a "GNU Package", but I don't see slayer in
the official list.  Perhaps you mean it is one that you want to submit to
GNU in the hope that they will adopt it as a package? Or did you mean something
else? Obviously how to it should be laid out will depend on that a lot.

Like you say, lack of documentation is will be a big factor in getting users.
How will people know how to use it, and perhaps more importantly WHY the should
use it?

Autotools can indeed be tricky - and a time consuming part of maintaining a
package - but they do make it a hell of a lot easier for the general public
to build, especially on wierd systems.

Lack of features is a concern - but if you have a dedicated user base, even a small
one, you will get requests for them.  However, if you don't have decent documentation,
and a reliable and portable build system, then you won't have any users ....


J'


On Sat, May 04, 2013 at 11:54:44PM +0200, Panicz Maciej Godek wrote:
     Hi everyone,
     I've developed a piece of software that I named SLAYER, by combining the
     letter 's' with the word "layer", or replacing the 'p' letter with 's' in
     the word 'player'.
     
     Either way, slayer can be thought of as a simpler alternative for wrapper
     libraries such as guile-sdl and guile-opengl, or as a programming
     environment that is in a way competetive to Adobe Flash (with standalone
     player). But obviously, it is something completely different.
     
     I made this program as a base for research in GUI design, but it also
     contains a stub of a 3d game engine that I'm planning to implement -- which
     explains native support for OpenGL. I recently thought that it also could
     be a great platform for teaching kids to program games, because -- once
     compiled and linked -- it could be distributed as a standalone package,
     that requires no additional tools.
     
     The program is available through mercurial on bitbucket:
     
     hg clone https://bitbucket.org/panicz/slayer
     
     The repository contains README file, which lists packages that are needed
     to build. Except a little mess, there are two demos that show the
     possibilities of the system. The first one with the command:
     
     $ ./slayer -e3d
     
     The -e3d option is needed to enable the "3d" extension, which is required
     by the demo. It allows to move around in a 3d space using mouse and WSAD
     keys. There's also a draggable icon and a simple text-console, which
     accepts s-expressions (evaluated using f1 key). It is activated with a
     click, but for some reason the cursor isn't always displayed. The source
     file is slayer.scm.
     
     The second demo is the classical arcade PONG game (for two players). It's
     written in the raw guile+slayer, so it's pretty lengthy (~160 lines), but
     it should be easily understandable. PONG can be run using
     $ ./slayer -i pong.scm
     
     Both demos use sound, which can be disabled by passing the --nosound option
     in the command line. PONG can also receive the -e3d option, which would
     force it to use opengl for display.
     
     Other command line options are undocumented, but they can be easily found
     in slayer.c. I admit that the lack of any documentation can now be the most
     seriously discouraging factor, but I promise to respond to every question
     eagerly.
     
     The second most seriously discouraging factor would be the build process,
     which could require manual editing of the Makefile, among others. It would
     be lovely to use the GNU autotools, but they seem so complicated, and I
     thought that since you might have more experience with those, you could
     help me to prepare a decent release, and perhaps to reorganize the
     structure of the source code.
     
     Perhaps the third most seriously discouraging factor (except some random
     crashes that still happen) would be the lack of certain features: I'm
     trying to apply the 'lazy implementation' strategy and add SDL/OpenGL
     features only as I need them, and also my priority is to keep interfaces
     simple, even at the cost of programmer's freedom (so for instance, there's
     no option for choosing color index mode in OpenGL, or some other SDL video
     mode than the default).
     
     Despite those factors, I'd be happy to hear some feedback from you.
     
     Best regards,
     M.

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://keys.gnupg.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Stjepan Horvat]

[-- Attachment #1: Type: text/plain, Size: 5655 bytes --]

It sounds fun although i'm guile newb..i'm just starting to learn how
recursion works and have written few simple functions reading
The_Little_Schemer..It would be cool to have a binary gui for programs
writen in c and has guile as extension language..

On Sun, May 5, 2013 at 7:15 AM, John Darrington <
john@darrington.wattle.id.au> wrote:

> It sounds like an interesting project.
>
> The subject line of your post says it is a "GNU Package", but I don't see
> slayer in
> the official list.  Perhaps you mean it is one that you want to submit to
> GNU in the hope that they will adopt it as a package? Or did you mean
> something
> else? Obviously how to it should be laid out will depend on that a lot.
>
> Like you say, lack of documentation is will be a big factor in getting
> users.
> How will people know how to use it, and perhaps more importantly WHY the
> should
> use it?
>
> Autotools can indeed be tricky - and a time consuming part of maintaining a
> package - but they do make it a hell of a lot easier for the general public
> to build, especially on wierd systems.
>
> Lack of features is a concern - but if you have a dedicated user base,
> even a small
> one, you will get requests for them.  However, if you don't have decent
> documentation,
> and a reliable and portable build system, then you won't have any users
> ....
>
>
> J'
>
>
> On Sat, May 04, 2013 at 11:54:44PM +0200, Panicz Maciej Godek wrote:
>      Hi everyone,
>      I've developed a piece of software that I named SLAYER, by combining
> the
>      letter 's' with the word "layer", or replacing the 'p' letter with
> 's' in
>      the word 'player'.
>
>      Either way, slayer can be thought of as a simpler alternative for
> wrapper
>      libraries such as guile-sdl and guile-opengl, or as a programming
>      environment that is in a way competetive to Adobe Flash (with
> standalone
>      player). But obviously, it is something completely different.
>
>      I made this program as a base for research in GUI design, but it also
>      contains a stub of a 3d game engine that I'm planning to implement --
> which
>      explains native support for OpenGL. I recently thought that it also
> could
>      be a great platform for teaching kids to program games, because --
> once
>      compiled and linked -- it could be distributed as a standalone
> package,
>      that requires no additional tools.
>
>      The program is available through mercurial on bitbucket:
>
>      hg clone https://bitbucket.org/panicz/slayer
>
>      The repository contains README file, which lists packages that are
> needed
>      to build. Except a little mess, there are two demos that show the
>      possibilities of the system. The first one with the command:
>
>      $ ./slayer -e3d
>
>      The -e3d option is needed to enable the "3d" extension, which is
> required
>      by the demo. It allows to move around in a 3d space using mouse and
> WSAD
>      keys. There's also a draggable icon and a simple text-console, which
>      accepts s-expressions (evaluated using f1 key). It is activated with a
>      click, but for some reason the cursor isn't always displayed. The
> source
>      file is slayer.scm.
>
>      The second demo is the classical arcade PONG game (for two players).
> It's
>      written in the raw guile+slayer, so it's pretty lengthy (~160 lines),
> but
>      it should be easily understandable. PONG can be run using
>      $ ./slayer -i pong.scm
>
>      Both demos use sound, which can be disabled by passing the --nosound
> option
>      in the command line. PONG can also receive the -e3d option, which
> would
>      force it to use opengl for display.
>
>      Other command line options are undocumented, but they can be easily
> found
>      in slayer.c. I admit that the lack of any documentation can now be
> the most
>      seriously discouraging factor, but I promise to respond to every
> question
>      eagerly.
>
>      The second most seriously discouraging factor would be the build
> process,
>      which could require manual editing of the Makefile, among others. It
> would
>      be lovely to use the GNU autotools, but they seem so complicated, and
> I
>      thought that since you might have more experience with those, you
> could
>      help me to prepare a decent release, and perhaps to reorganize the
>      structure of the source code.
>
>      Perhaps the third most seriously discouraging factor (except some
> random
>      crashes that still happen) would be the lack of certain features: I'm
>      trying to apply the 'lazy implementation' strategy and add SDL/OpenGL
>      features only as I need them, and also my priority is to keep
> interfaces
>      simple, even at the cost of programmer's freedom (so for instance,
> there's
>      no option for choosing color index mode in OpenGL, or some other SDL
> video
>      mode than the default).
>
>      Despite those factors, I'd be happy to hear some feedback from you.
>
>      Best regards,
>      M.
>
> --
> PGP Public key ID: 1024D/2DE827B3
> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
> See http://keys.gnupg.net or any PGP keyserver for public key.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlGF6wkACgkQimdxnC3oJ7Pd5ACeOqfjo33M2YA+e7sEbvpR9g82
> 7mMAmgNMwztNlpQHBg5OMwzjDgvaMmqE
> =L1uC
> -----END PGP SIGNATURE-----
>
>


-- 
*Nesmotren govori kao da mačem probada, a jezik je mudrih iscjeljenje.
Izreke 12:18*

[-- Attachment #2: Type: text/html, Size: 6619 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]

Hello!

It sounds like an interesting project.
>
> The subject line of your post says it is a "GNU Package", but I don't see
> slayer in
> the official list.  Perhaps you mean it is one that you want to submit to
> GNU in the hope that they will adopt it as a package? Or did you mean
> something
> else? Obviously how to it should be laid out will depend on that a lot.
>

Well, I mostly meant a package that is compatibile with GNU system -- so
that it would conform to the GNU standards. Whether is should be made an
official GNU package is not that important to me, and I think it's still
too early to decide


> Like you say, lack of documentation is will be a big factor in getting
> users.
> How will people know how to use it, and perhaps more importantly WHY the
> should
> use it?
>

As for now, there are two demos which should help them get around, but I
agree that in the longer run the documentation has to appear, especially as
the system gets more complex, and as some parts of it become steady.
If it comes to the second question, I think that the simplicity could
convince some people to employ slayer to their multimedia projects --
because it requires no additional setup and works out of the box, so for
instance it could be quite easily employed to implement the picture
language from SICP

Autotools can indeed be tricky - and a time consuming part of maintaining a
> package - but they do make it a hell of a lot easier for the general public
> to build, especially on wierd systems.
>

If it comes to weird systems, I also thought that having a build from mingw
could also earn some popularity (if it is possible)

Lack of features is a concern - but if you have a dedicated user base, even
> a small
> one, you will get requests for them.  However, if you don't have decent
> documentation,
> and a reliable and portable build system, then you won't have any users
> ....
>

I know. For now slayer is a byproduct of my other strivings, but I just
thought that someone else could find it useful -- and the feedback could
boost the development. Yet at this stage my main target is the community of
hackers who could review the code and possibly find their own applications.
I think that if someone sees the demos and wants to find out more, then it
would make sense to run a documentation wiki or work on the info pages (or
-- initially -- to answer the questions via e-mail). This is also why I
need someone with more experience, to help me conceive the documentation
process.

I'm thinking of slayer as of environment rather than a program, and I think
that it could evolve (among others) towards a development environment, so
it would make sense if the documentation was available from there as well.

Thanks! :)
M.

[-- Attachment #2: Type: text/html, Size: 3662 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

() Panicz Maciej Godek <godek.maciek@gmail.com>
() Sun, 5 May 2013 08:59:18 +0200

   I think that the simplicity could convince some people to employ
   slayer to their multimedia projects -- because it requires no
   additional setup and works out of the box, so for instance it could
   be quite easily employed to implement the picture language from SICP

Probably the valuation of simplicity depends largely on point of view.

As the author, for you it is simple and transparent.

For the newcomer, it is opaque, and its simplicity is to be determined.

As Guile-SDL maintainer, i wonder what i can do to attract the same
audience, whether or not it is worth expending the energy to do so, in
what ways have i failed to encourage organic additive (as opposed to
parallel) hacking, and how wonderful/terrible it is for GNU to be so
loosely coupled.

Anyway, should you wish to rebase SLAYER onto Guile-SDL (which has
surmounted the documentation, autotools, and certain libguile churn
issues), i, too, am happy to help out.  (Maybe we can work together.)

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Popularity (was Re: SLAYER announcement ...)

[Mike Gran]

> From: Thien-Thi Nguyen <ttn@gnu.org>

> As Guile-SDL maintainer, i wonder what i can do to attract the same
> audience, whether or not it is worth expending the energy to do so, in
> what ways have i failed to encourage organic additive (as opposed to
> parallel) hacking, and how wonderful/terrible it is for GNU to be so
> loosely coupled.

Working on a library or framework is always a thankless task, since
so few programmers want to use the unproven.  Gtk would not be where
it is if it weren't for the co-development of Gimp, an end-user
program.

Getting someone to try an end-user program is easier than getting
a programmer to try out a library.  But that is difficult as well.
Since every essential end-user program has been written -- all new
work just re-mixes the old ideas in either shinier or deeper ways --
few people are in "need" of new software.

But there is always space for new diversions: there still seems to
be a market for something short, easy to run, and entertaining.
The Flash or HTML5 games model, essentially.

One might consider writing an end-user program first,
and then note how it is built upon libraries that can
easily be reused.

(And speaking of libraries that will never be used... guile-ncurses
v1.4 dropped last week.  That'll never have any users because the
intersection in that Venn diagram is too small, consisting mostly of
me.  So, I write it for myself.  Maybe I should follow my own
advice above.)

-Mike

Re: Popularity

[Frank Terbeck]

Mike Gran wrote:
> (And speaking of libraries that will never be used... guile-ncurses
> v1.4 dropped last week.  That'll never have any users because the
> intersection in that Venn diagram is too small, consisting mostly of
> me.  So, I write it for myself.  Maybe I should follow my own
> advice above.)

Heh. I have had a project that uses guile-ncurses in the back of my mind
for a while now. I was quite happy to see that someone wrote guile
bindings for that. I don't know if I ever get to really get that project
running, but know that your work is appreciated! :-)

Regards, Frank

Re: Popularity (was Re: SLAYER announcement ...)

[Chris Vine]

On Sun, 5 May 2013 12:42:34 -0700 (PDT)
Mike Gran <spk121@yahoo.com> wrote:
> (And speaking of libraries that will never be used... guile-ncurses
> v1.4 dropped last week.  That'll never have any users because the
> intersection in that Venn diagram is too small, consisting mostly of
> me.  So, I write it for myself.  Maybe I should follow my own
> advice above.)

I don't agree with that.  I have used guile-ncurses for my own purposes
quite successfully.  To be honest, I would never write a non-trivial
program using guile-gnome, which seems to be the only offering if you
want a GUI using guile-2.0: it has too many oddities (in particular, it
seems trivially easy to jam up the glib main loop and is sluggishly
maintained). At least guile-ncurses works as well as ncurses does, and
without any particular oddities.  OK, it provides a terminal/console
interface, but once you get over that it is fine.

Chris

Re: Popularity (was Re: SLAYER announcement ...)

[Nala Ginrut]

On Sun, 2013-05-05 at 12:42 -0700, Mike Gran wrote:
> > From: Thien-Thi Nguyen <ttn@gnu.org>
> 
> > As Guile-SDL maintainer, i wonder what i can do to attract the same
> > audience, whether or not it is worth expending the energy to do so, in
> > what ways have i failed to encourage organic additive (as opposed to
> > parallel) hacking, and how wonderful/terrible it is for GNU to be so
> > loosely coupled.
> 
> Working on a library or framework is always a thankless task, since
> so few programmers want to use the unproven.  Gtk would not be where
> it is if it weren't for the co-development of Gimp, an end-user
> program.
> 
> Getting someone to try an end-user program is easier than getting
> a programmer to try out a library.  But that is difficult as well.
> Since every essential end-user program has been written -- all new
> work just re-mixes the old ideas in either shinier or deeper ways --
> few people are in "need" of new software.
> 
> But there is always space for new diversions: there still seems to
> be a market for something short, easy to run, and entertaining.
> The Flash or HTML5 games model, essentially.
> 
> One might consider writing an end-user program first,
> and then note how it is built upon libraries that can
> easily be reused.
> 
> (And speaking of libraries that will never be used... guile-ncurses
> v1.4 dropped last week.  That'll never have any users because the
> intersection in that Venn diagram is too small, consisting mostly of
> me.  So, I write it for myself.  Maybe I should follow my own
> advice above.)
> 

No Mike, I use guile-ncurses for a little thing to peek stock
market. ;-P
And TTN, your work is nice.
We just don't have a web community yet, so many folks and projects are
unrevealed. 

> -Mike
> 

Re: Popularity (was Re: SLAYER announcement ...)

[Ludovic Courtès]

Mike Gran <spk121@yahoo.com> skribis:

> (And speaking of libraries that will never be used... guile-ncurses
> v1.4 dropped last week.  That'll never have any users

I have plans to use it to make a GUI for Guix (sic), and would even
welcome patches in that direction.  Hint, hint!  :-)

Ludo’.

Re: SLAYER announcement and help request for preparing a GNU package

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 5201 bytes --]

2013/5/5 Thien-Thi Nguyen <ttn@gnu.org>

>    I think that the simplicity could convince some people to employ
>    slayer to their multimedia projects -- because it requires no
>    additional setup and works out of the box, so for instance it could
>    be quite easily employed to implement the picture language from SICP
>
> Probably the valuation of simplicity depends largely on point of view.
>
> As the author, for you it is simple and transparent.
>
> For the newcomer, it is opaque, and its simplicity is to be determined.
>
>
I can't say that my judgements are unbiased, but I claim that the interface
of slayer is objectively simpler than the one of SDL (and consequently --
Guile-SDL) -- obiously to the extent to which the comparison makes sense.
Slayer is an event-driven abstraction layer over SDL (and OpenGL). Thus,
the whole application that, for instance, plays a certain sound when a key
is pressed, would look like that in slayer:

(use-modules (slayer))
(define sound (load-sound "sound.wav"))
(keydn 'esc quit)
(keydn 'm (lambda()(play-sound! sound)))

I dare to say that this is much simpler than in raw SDL, where one needs to
write his own loop to handle the input, not to mention the fairly
complicated initialization routines. Working with images would require
employing the widget framework (I admit that the interface is a little
unintuitive at the moment, but it can be improved easily)

(use-modules (slayer) (slayer image) (widgets base) (widgets bitmap))
(keydn 'esc quit)
(define image (load-image "image.png"))
(add-child! *stage* (make-image image 70 20))

The above code creates an image that can be dragged around the screen. I
agree that it's counterintuitive (because nothing in the code suggests that
the image is draggable) and could be done better -- and that without this
example it would be difficult to figure out how to do that. But still I
dare to claim that it's simpler than if one had to do it in pure SDL (and
he would probably end up reimplementing slayer)

Things get more complicated when one wants to manually draw the stage,
because then he needs to set-display-procedure! (the way it's done in the
pong.scm demo). But as I reckon from my experience with SDL and OpenGL,
it's still simpler than figuring out the setup for double buffered mode and
making things in the right order (and remembering to glFinish()).

Also, doing some more sophisticated timing requires creating a new thread,
which -- fortunately -- is quite simple in guile. (I admit, however, that
because of that reason, the included demos may be non-thread-safe)

As Guile-SDL maintainer, i wonder what i can do to attract the same
> audience, whether or not it is worth expending the energy to do so, in
> what ways have i failed to encourage organic additive (as opposed to
> parallel) hacking, and how wonderful/terrible it is for GNU to be so
> loosely coupled.
>

My project transformed and evolved from a C++ OpenGL engine that I've been
working on a couple of years ago, and then abandoned it. Years later, the
input system that I implemented (array of approx. SDLK_LAST SCM thunks,
supported by a few arrays of C function pointers and a loop) turned out to
be still useful.

Anyway, should you wish to rebase SLAYER onto Guile-SDL (which has
> surmounted the documentation, autotools, and certain libguile churn
> issues), i, too, am happy to help out.  (Maybe we can work together.)
>

I'd really love to work together! However, there would be very little point
in rebasing slayer onto Guile-SDL because of the project's goal, which is
to supply a standalone executable that embeds (rather than extends) guile,
and can therefore be thought of as a separate environment.
I remember Ludovic reprimending me for embedding guile instead of extending
it, but I believe that slayer is a humble exception from that otherwise
notable rule. Perhaps the difference is psychological rather than
technical, and perhaps one day someone decides to transform slayer into a
loadable guile module, as it should be a truly trivial task, but for now I
think that it will be easier for people to understand that they get
"something similar to flash player" (it is for me :D)

Besides, I really don't think that we would gain anything by taking the
code that works and rewriting it to something else. If you are willing to
help, I will appreciate it, and I believe that the experience that you got
working on Guile-SDL would then be utilized properly (especially that you
plainly put a lot of labour into that project, and your programming style
seems more mature than mine).
It would be a brand new experience for me to cooperate on an open source
project with some other person.

When it comes to the line of development, my main motivation for adding new
features is the game that I'm trying to create, and -- as I wrote -- slayer
is a byproduct, and it's meant to be useful for the set of its users (which
is currently a singleton consisting of its author) rather than complete.
However, I do have certain ideas of how the slayer environment could be
enriched with some useful features (making a scheme editor widget, to begin
with)

I hope we can make our way somehow
Best regards!

[-- Attachment #2: Type: text/html, Size: 6523 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Javier Sancho]

Congratulations!!

I've been working a little on something similar during the last four
years, but I am looking for a kind of fluxus
(http://www.pawfal.org/fluxus/) for games. You can see my code at
http://savannah.nongnu.org/projects/gacela

First versions were developed with GNU Common Lisp and C bindings for
OpenGL and SDL but last year I discovered GNU Guile and Dynamic FFI.
Actually, Gacela is a Guile module which uses Figl
(http://gitorious.org/guile-figl); I am removing dependencies with
SDL.

But most of my efforts are spent on my eternal search betwwen
simplicity, reusable code, proper functional style, i.e., a lot of
programming design and procrastination. I'm trying to mix FRP
techniques, entity systems, fluxus, yampas and more ideas in a maybe
useless library but a very funny project for me.

I tryed to port Gacela to the web too, and I developed an uncompleted
Lisp-Javascript translator that uses canvas and SVG for displaying
graphics. Very funny and instructive, too.

In summary, a lot of work but few results. But I've had fun and learned a lot.

--
Javier Sancho Fernández - http://www.jsancho.org/
Associate Member of the Free Software Foundation - http://www.fsf.org/
Contra el DRM - http://www.defectivebydesign.org/what_is_drm

Re: SLAYER announcement and help request for preparing a GNU package

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

2013/5/6 Javier Sancho <jsf@jsancho.org>

> Congratulations!!
>
> I've been working a little on something similar during the last four
> years, but I am looking for a kind of fluxus
> (http://www.pawfal.org/fluxus/) for games.


Thanks :) I see that there are a few persons with similar ideas, and I
wonder how powerful we'd become if we managed to orchestrate our powers
somehow, as TTN suggested


> You can see my code at
> http://savannah.nongnu.org/projects/gacela


I even managed to build it, but for some reasons the demos won't run. I get
the following error:
gacela/video.scm:175:2: In procedure init-gl:
gacela/video.scm:175:2: In procedure module-lookup: Unbound variable:
set-gl-hint

It was also a little surprising that I had to copy the guile modules
manually, in spite of make install

If it comes to code, I see that you have a more polling-style approach for
processing input. My desire is to get a system that never stops being
reconfigurable -- to truly separate the user interface from program logics.
I don't know if it's achievable, but I have a feeling that such direction
is worth exploring

First versions were developed with GNU Common Lisp and C bindings for
> OpenGL and SDL but last year I discovered GNU Guile and Dynamic FFI.
> Actually, Gacela is a Guile module which uses Figl
> (http://gitorious.org/guile-figl); I am removing dependencies with
> SDL.
>
> But most of my efforts are spent on my eternal search betwwen
> simplicity, reusable code, proper functional style, i.e., a lot of
> programming design and procrastination. I'm trying to mix FRP
> techniques, entity systems, fluxus, yampas and more ideas in a maybe
> useless library but a very funny project for me.
>

All these concepts sound very interesting, but I'm curious whether they are
reflected the code somewhere. I, on the other hand, put a lot of trust in
Scheme -- I believe that whatever I do, will eventually be able to find a
concise representation for that, that will be surrounded by many
parentheses ;] and so I'm not so much worried with the design, believing,
that I will just be doing, and everything will design itself :)

I tryed to port Gacela to the web too, and I developed an uncompleted
> Lisp-Javascript translator that uses canvas and SVG for displaying
> graphics. Very funny and instructive, too.
>

:) I have also been thinking about something similar, but I decided to
leave that idea for unspecified future that might never come

Best regards,
M.

[-- Attachment #2: Type: text/html, Size: 3988 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 3283 bytes --]

() Panicz Maciej Godek <godek.maciek@gmail.com>
() Mon, 6 May 2013 21:36:33 +0200

   Thanks :) I see that there are a few persons with similar ideas, and
   I wonder how powerful we'd become if we managed to orchestrate our
   powers somehow, as TTN suggested

Orchestration is a nice concept.  It is the marshalling of separate
efforts in a parallel direction (towards the audience), moderated
individually, but w/ group awareness, by precise changes in timing and
pitch.  Cool.

For this, i strongly urge everyone who wants to jam[0] to provide
documentation.  That is the minimal requirement, the tuning of your
instrument so that it does not burn the ears of others seated beside
you.  So what if you don't have (the autotools) rhythm?  That can (and
must!) be cyclically attained.  To start, you gotta have the right Hz.

"But ttn, documentation is a pain to create and maintain!"

Well, yes.  For creation, i offer as riposte Guile-BAUX[1], which helps
me painlessly convert:

--8<---------------cut here---------------start------------->8---
  PRIMPROC
  (mix_allocate_channels, "allocated-channels", 1, 0, 0,
   (SCM numchans),
   doc: /***********
  Dynamically change the number of channels managed by
  the mixer to @var{numchans}.  If decreasing the number
  of channels, the upper channels are stopped.  Return the
  new number of allocated channels.  */)
  {
  #define FUNC_NAME s_mix_allocate_channels
    ASSERT_INTEGER (numchans, 1);
  
    RETURN_INT (Mix_AllocateChannels (C_LONG (numchans)));
  #undef FUNC_NAME
  }
--8<---------------cut here---------------end--------------->8---

and

--8<---------------cut here---------------start------------->8---
  ;; Return the exact truncation (rounding to zero) of @var{number}.
  ;; This is ``safer'' than simply @code{inexact->exact}
  ;; for some Guile versions.
  ;;
  ;; @example
  ;; (define scale 0.180281690140845)
  ;; (inexact->exact scale)
  ;;   @result{} 3247666210160131/18014398509481984 ; Guile 1.8.7
  ;;   @result{} 0                                  ; Guile 1.4.x
  ;; (exact-truncate scale)
  ;;   @result{} 0
  ;; @end example
  ;;
  (define (exact-truncate number)
    (inexact->exact (truncate number)))
--8<---------------cut here---------------end--------------->8---

into:
<http://www.gnu.org/software/guile-sdl/manual/html_node/Audio.html#index-allocated_002dchannels>
and
<http://www.gnu.org/software/guile-sdl/manual/html_node/Miscellaneous-Utilities.html#index-exact_002dtruncate>
respectively.

The nice thing (IMNSHO) is that Guile-BAUX is itself a nontrivial chunk
of Guile Scheme, nothing more, and furthermore takes pains to rise above
the cacaphony of Guile version-specific quirks.

Documentation maintenance, on the other hand, is a charge laid squarely
on the Author and the Author's discipline and astuteness.  You know what
to do; you know how to do it; what must be dredged from the void is the
will and the practice, the mind and the motion.  I wish you fortitude.

_________________________________________________________
[0] http://www.merriam-webster.com/dictionary/jam
    (as in "jam session")

[1] http://www.gnuvola.org/software/guile-baux/

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]

2013/5/6 Thien-Thi Nguyen <ttn@gnu.org>

> () Panicz Maciej Godek <godek.maciek@gmail.com>
> () Mon, 6 May 2013 21:36:33 +0200
>
>    Thanks :) I see that there are a few persons with similar ideas, and
>    I wonder how powerful we'd become if we managed to orchestrate our
>    powers somehow, as TTN suggested
>
> Orchestration is a nice concept.  It is the marshalling of separate
> efforts in a parallel direction (towards the audience), moderated
> individually, but w/ group awareness, by precise changes in timing and
> pitch.  Cool.
>
> For this, i strongly urge everyone who wants to jam[0] to provide
> documentation.  That is the minimal requirement, the tuning of your
> instrument so that it does not burn the ears of others seated beside
> you.  So what if you don't have (the autotools) rhythm?  That can (and
> must!) be cyclically attained.  To start, you gotta have the right Hz.
>
> "But ttn, documentation is a pain to create and maintain!"
>
> Well, yes.  For creation, i offer as riposte Guile-BAUX[1],
>
[...]

This looks truly awesome!
However, I'm only getting acquainted with autotools, and there are many
secrets to me. I see that both guile-sdl and guile-figl copy the scm
modules to $(prefix)/share/guile/site...,
but apparently they both do that in a different way (which means there's no
standard way), and none of them allows to 'fine tune' that directory with
an optarg to ./configure

And the whole thing makes me wonder about the status of guile
documentation. The guide is really great (although sometimes it remains
silent about certain features that can be found in header files), but I've
observed that doc-strings for built-in functions are no longer available,
even though they are specified.

And besides, how do the aforementioned modules (those are, as I reckon,
tsar and c-tsar) refer to guile-snarf-docs that is shipped with guile
source?

The nice thing (IMNSHO) is that Guile-BAUX is itself a nontrivial chunk
> of Guile Scheme, nothing more, and furthermore takes pains to rise above
> the cacaphony of Guile version-specific quirks.
>
> Documentation maintenance, on the other hand, is a charge laid squarely
> on the Author and the Author's discipline and astuteness.  You know what
> to do; you know how to do it; what must be dredged from the void is the
> will and the practice, the mind and the motion.  I wish you fortitude.
>

Well, thanks, I'll do my best :)

[-- Attachment #2: Type: text/html, Size: 3267 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

() Panicz Maciej Godek <godek.maciek@gmail.com>
() Wed, 8 May 2013 00:50:32 +0200

   both guile-sdl and guile-figl copy the scm modules to
   $(prefix)/share/guile/site..., but apparently they both do that in a
   different way (which means there's no standard way), and none of them
   allows to 'fine tune' that directory with an optarg to ./configure

I like how guile-ncurses does it.  Maybe Guile-BAUX (and SNUGGLE[0],
which i forgot to mention previously) will follow its lead.

   And the whole thing makes me wonder about the status of guile
   documentation.

Back in time, Guile inherited the documentation maintenance mindset of
Emacs, i.e., "docstrings are for interactive (repl) consumption, full
descriptions belong in the manual".  This makes for a lot of work, which
Emacs can easily demand of its large hacker population, but Guile cannot
(its hackers being relatively few and somewhat prone to solipsism).  So
naturally, as w/ any situation where todo exceeds doers, some stuff does
not get done or gets done w/ less attention than deserved.

At present, there is a protocol between the repl and the database of
docstrings (guile-procedures.txt) only, and only for libguile(?).  And
those laboriously maintained docstrings do not make it into the manual,
either, by dint of the mindset.  If that were to change, i think it
would be a SMOP to arrange to significantly improve the status of Guile
documentation.  (Maybe that has already happened, but i missed it?)

Personally, i think the ideal model is to define a protocol between the
repl and the manual-viewing program, such that full documentation is the
only thing that needs to be maintained.  IMHO, the best layout for that
is intro, concept and expository text in .texi, and proc/var/etc details
in .h/.c/.scm comments.  That's what Guile-BAUX supports, no surpise.

   The guide is really great (although sometimes it remains silent about
   certain features that can be found in header files), but I've
   observed that doc-strings for built-in functions are no longer
   available, even though they are specified.

Could you give some examples?

   And besides, how do the aforementioned modules (those are, as I
   reckon, tsar and c-tsar) refer to guile-snarf-docs that is shipped
   with guile source?

They don't.  The script guile-snarf-docs is not installed, and thus not
available to third parties (like SLAYER or Guile-SDL).  But even if it
were, its method has changed over the years; it might give bad results
if used w/ a different Guile version than its original distribution.
Believe me, i [pw]ondered the same thing.  That's what led to Guile
1.4.x hacking and doc fu[1], and eventually, Guile-BAUX (and SNUGGLE).

___________________________________________________
[0] http://www.gnuvola.org/software/snuggle/

[1] http://www.gnuvola.org/software/guile/
    http://www.gnuvola.org/software/guile/doc/Doc-Maintenance.html

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 5426 bytes --]

2013/5/8 Thien-Thi Nguyen <ttn@gnu.org>

> () Panicz Maciej Godek <godek.maciek@gmail.com>
> () Wed, 8 May 2013 00:50:32 +0200
>
>    both guile-sdl and guile-figl copy the scm modules to
>    $(prefix)/share/guile/site..., but apparently they both do that in a
>    different way (which means there's no standard way), and none of them
>    allows to 'fine tune' that directory with an optarg to ./configure
>
> I like how guile-ncurses does it.  Maybe Guile-BAUX (and SNUGGLE[0],
> which i forgot to mention previously) will follow its lead.
>
>
I think that it might be misleading. I see that autotools are already
complicated, and there's no need to complicate them more, especially if
guile is an official extension language of the GNU project.
When you ./configure --help, you get a section "Fine tuning of the
installation directories", where you get such directives, as --bindir,
--datadir and so on. However, if you want to install the guile modules, you
need to use --with-guilesitedir, which is documented in 'Optional Packages'
section, as if the installation directory was a package.
The Right Thing would be to place --guilesitedir flag in the former
section, although I see that there's currently no official way to do it.
(And I see that there's been a few discussions about that, like this one:
http://lists.gnu.org/archive/html/autoconf/2006-09/msg00009.html, which
says that it's allegedly incompatible with GNU Coding Standards, or that
one:
http://stackoverflow.com/questions/3538705/adding-a-custom-installation-directory-option-to-autoconf-generated-configure-sc.
Terribly frustrating!)

    And the whole thing makes me wonder about the status of guile
>    documentation.
>
> Back in time, Guile inherited the documentation maintenance mindset of
> Emacs, i.e., "docstrings are for interactive (repl) consumption, full
> descriptions belong in the manual".  This makes for a lot of work, which
> Emacs can easily demand of its large hacker population, but Guile cannot
> (its hackers being relatively few and somewhat prone to solipsism).  So
> naturally, as w/ any situation where todo exceeds doers, some stuff does
> not get done or gets done w/ less attention than deserved.
>
>
The actual state of the documentation is a secondary issue. I find the
question whether we have a framework that allows to extend documentation
easily somewhat more important.

At present, there is a protocol between the repl and the database of
> docstrings (guile-procedures.txt) only, and only for libguile(?).  And
> those laboriously maintained docstrings do not make it into the manual,
> either, by dint of the mindset.  If that were to change, i think it
> would be a SMOP to arrange to significantly improve the status of Guile
> documentation.  (Maybe that has already happened, but i missed it?)
>

Even not minding the manual (although it would be best if the maintainer
could decide whether or not she wishes to export the docstring to the
manual), as I understand -- there is no straigtforward C interface to
provide docstrings to the functions exported by external modules?
The other problem is that with the introduction of guile-vm, the builtin
procedures' argument names disappeared, while they're quite helpful when
used with geiser's autodoc mode.

Personally, i think the ideal model is to define a protocol between the
> repl and the manual-viewing program, such that full documentation is the
> only thing that needs to be maintained.  IMHO, the best layout for that
> is intro, concept and expository text in .texi, and proc/var/etc details
> in .h/.c/.scm comments.  That's what Guile-BAUX supports, no surpise.
>
>
I agree that it's a fairly clean approach, and I will try to employ it ASAP

   The guide is really great (although sometimes it remains silent about
>    certain features that can be found in header files), but I've
>    observed that doc-strings for built-in functions are no longer
>    available, even though they are specified.
>
> Could you give some examples?
>
>
I see now that I might have gotten something wrong, but e.g. in
libguile/alst.c there was a definition:
SCM_DEFINE (scm_acons, "acons", 3, 0, 0,
           (SCM key, SCM value, SCM alist),
            "Add a new key-value pair to @var{alist}.  A new pair is\n"
            "created whose car is @var{key} and whose cdr is @var{value},
and the\n"
            "pair is consed onto @var{alist}, and the new list is returned.
 This\n"
            "function is @emph{not} destructive; @var{alist} is not
modified.")
#define FUNC_NAME s_scm_acons
{
  return scm_cons (scm_cons (key, value), alist);
}
#undef FUNC_NAME

and (procedure-documentation acons) returns #f. Now I see that it's meant
rather to generate the manual than to provide a docstring.

   And besides, how do the aforementioned modules (those are, as I
>    reckon, tsar and c-tsar) refer to guile-snarf-docs that is shipped
>    with guile source?
>
> They don't.  The script guile-snarf-docs is not installed, and thus not
> available to third parties (like SLAYER or Guile-SDL).  But even if it
> were, its method has changed over the years; it might give bad results
> if used w/ a different Guile version than its original distribution.
> Believe me, i [pw]ondered the same thing.  That's what led to Guile
> 1.4.x hacking and doc fu[1], and eventually, Guile-BAUX (and SNUGGLE).
>

 I see you've done a lot of good things :)
I'm grateful!

[-- Attachment #2: Type: text/html, Size: 7843 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Mark H Weaver]

Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> I see now that I might have gotten something wrong, but e.g. in
> libguile/alst.c there was a definition:
> SCM_DEFINE (scm_acons, "acons", 3, 0, 0,
> (SCM key, SCM value, SCM alist),
> "Add a new key-value pair to @var{alist}. A new pair is\n"
> "created whose car is @var{key} and whose cdr is @var{value}, and
> the\n"
> "pair is consed onto @var{alist}, and the new list is returned.
> This\n"
> "function is @emph{not} destructive; @var{alist} is not modified.")
> #define FUNC_NAME s_scm_acons
> {
> return scm_cons (scm_cons (key, value), alist);
> }
> #undef FUNC_NAME
>
> and (procedure-documentation acons) returns #f.

Interesting.  I notice that ",d acons" at the REPL still works.  The
REPL command uses 'object-documentation' from (ice-9 documentation).

> Now I see that it's
> meant rather to generate the manual than to provide a docstring.

No, it's not used to generate the manual.  It's used to generate
guile-procedures.txt, which is consulted by 'object-documentation'.

I agree that the current state of docstring handling leaves much to be
desired.  Maybe we should start a discussion on guile-devel about how
the improve things.

     Regards,
       Mark

Re: SLAYER announcement and help request for preparing a GNU package

[Mike Gran]

> No, it's not used to generate the manual.  It's used to generate
> guile-procedures.txt, which is consulted by 'object-documentation'.
> 
> I agree that the current state of docstring handling leaves much to be
> desired.  Maybe we should start a discussion on guile-devel about how
> the improve things.

I once asked the question if it would be possible to create a version
of scm_c_define_gsubr that took a docstring.  The opinion at the time
was that it would be difficult.

-Mike

Re: SLAYER announcement and help request for preparing a GNU package

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

2013/5/8 Mike Gran <spk121@yahoo.com>

>
> > No, it's not used to generate the manual.  It's used to generate
> > guile-procedures.txt, which is consulted by 'object-documentation'.
> >
> > I agree that the current state of docstring handling leaves much to be
> > desired.  Maybe we should start a discussion on guile-devel about how
> > the improve things.
>
> I once asked the question if it would be possible to create a version
> of scm_c_define_gsubr that took a docstring.  The opinion at the time
> was that it would be difficult.
>

Well, after a moment of thought I concluded that it's not that difficult,
at least with the current version of guile, using
scm_set_procedure_property_x:

scm_c_define_gsubr("proc", 0, 0, 0 ,(scm_t_subr) proc);
scm_c_export("proc" ,NULL);

scm_set_procedure_property_x(scm_variable_ref(scm_c_lookup("proc")),

 scm_from_utf8_symbol("documentation"),
                                             scm_from_utf8_string("Does
something"));

Although it may not be particularly efficient, I think it is sufficient
(and it seems to work just fine), unless there are any other
contraindications

[-- Attachment #2: Type: text/html, Size: 1852 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

() Panicz Maciej Godek <godek.maciek@gmail.com>
() Wed, 8 May 2013 14:51:47 +0200

   2013/5/8 Thien-Thi Nguyen <ttn@gnu.org>

   >    [choosing installation dir for scheme code]
   >
   > I like how guile-ncurses does it.

   I think that it might be misleading.
   [infelicities w/ autotools, both "on" and "through"]

Yes, it's messy.

   The actual state of the documentation is a secondary issue. I find
   the question whether we have a framework that allows to extend
   documentation easily somewhat more important.

Agreed.  The refined artifact comes from the refined action.

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: SLAYER announcement and help request for preparing a GNU package

[Ludovic Courtès]

Thien-Thi Nguyen <ttn@gnu.org> skribis:

> At present, there is a protocol between the repl and the database of
> docstrings (guile-procedures.txt) only, and only for libguile(?).  And
> those laboriously maintained docstrings do not make it into the manual,
> either, by dint of the mindset.  If that were to change, i think it
> would be a SMOP to arrange to significantly improve the status of Guile
> documentation.  (Maybe that has already happened, but i missed it?)

For the record, AFAIK, docstrings from libguile are in sync with the
manual currently.  By that I mean that they are identical most of the
time (I agree there are good reasons why they would/should differ in
some cases, though.)

[...]

>    And besides, how do the aforementioned modules (those are, as I
>    reckon, tsar and c-tsar) refer to guile-snarf-docs that is shipped
>    with guile source?
>
> They don't.  The script guile-snarf-docs is not installed, and thus not
> available to third parties

I used a different approach in GnuTLS and other projects: it had a doc
snarfer comparable to guile-snarf-docs, but written in Scheme (see
<https://gitorious.org/gnutls/gnutls/trees/master/guile/modules/system/documentation>
and related files.)

That said, one of the benefits of using the FFI is that docstrings are
no problem...

Thanks,
Ludo’.

Re: SLAYER announcement and help request for preparing a GNU package

[Javier Sancho]

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

Panicz Maciej Godek wrote:
> I even managed to build it, but for some reasons the demos won't run. I get
> the following error:
> gacela/video.scm:175:2: In procedure init-gl:
> gacela/video.scm:175:2: In procedure module-lookup: Unbound variable:
> set-gl-hint

The reason is, oh my god, you are the first who test my code.

When I started this project, I made demos and some documentation, but
I stopped maintaining them because nobody was interested. Makefiles
compile OpenGL and SDL bindings, but now I use Figl and compilation is
not needed. The error with set-gl-hint comes because I have a figl
version with some improvements. I've sent patches to figl maintainers.

Currently, Gacela is in a very unstable state. Demos, for example, use
an old version with a more OOP style, because when I wrote them I was
beginning to understand Lisp and functional programming. But actually
I'm reestructuring all the code looking for a more elegant, beatiful,
functional style.

> If it comes to code, I see that you have a more polling-style approach for
> processing input. My desire is to get a system that never stops being
> reconfigurable -- to truly separate the user interface from program logics.
> I don't know if it's achievable, but I have a feeling that such direction is
> worth exploring

Yes, your style is more callback style. I personally prefer polling
because then I can read the code sequentially. But it's a personal
consideration.

> All these concepts sound very interesting, but I'm curious whether they are
> reflected the code somewhere.

For the moment, no. But I have a lot of papers :-)

Cheers.

--
Javier Sancho Fernández - http://www.jsancho.org/
Associate Member of the Free Software Foundation - http://www.fsf.org/
Contra el DRM - http://www.defectivebydesign.org/what_is_drm

[-- Attachment #2: 20130501-glhint-gllookat.patch --]
[-- Type: application/octet-stream, Size: 577 bytes --]

diff --git a/figl/gl.scm b/figl/gl.scm
index 090f9ff..0098525 100644
--- a/figl/gl.scm
+++ b/figl/gl.scm
@@ -378,6 +378,12 @@
            (%glCopyPixels . gl-copy-pixels))
 
 ;;;
+;;; 5.6 Hints
+;;;
+
+(re-export (%glHint . set-gl-hint))
+
+;;;
 ;;; 6.1 Querying GL State
 ;;;
 
diff --git a/figl/glu.scm b/figl/glu.scm
index e5af05e..df63fb9 100644
--- a/figl/glu.scm
+++ b/figl/glu.scm
@@ -42,4 +42,5 @@
 ;;; 4 Matrix Manipulation
 ;;;
 
-(re-export (%gluPerspective . glu-perspective))
+(re-export (%gluLookAt . glu-look-at)
+           (%gluPerspective . glu-perspective))

[-- Attachment #3: 20130501-textures.patch --]
[-- Type: application/octet-stream, Size: 1286 bytes --]

diff --git a/figl/gl.scm b/figl/gl.scm
index 0098525..36a1eb7 100644
--- a/figl/gl.scm
+++ b/figl/gl.scm
@@ -296,7 +296,44 @@
 
 (re-export (%glShadeModel . set-gl-shade-model))
 
-\f
+;;;
+;;; 3.8.4 Texture Parameters
+;;;
+
+(define (set-gl-texture-parameter target pname . param)
+  (let ((n (length param)))
+    (cond ((= n 1) (%glTexParameterf target pname (car param)))
+	  ((> n 1) (%glTexParameterfv target pname (list->f32vector param))))))
+
+(export set-gl-texture-parameter)
+
+;;;
+;;; 3.8.11 Texture Image Specification
+;;;
+
+(define* (set-gl-texture-image target level internalFormat border format type data width #:optional (height #f) (depth #f))
+  (cond ((and height depth)
+	 (%glTexImage3D target level internalFormat width height depth border format type data))
+	(height
+	 (%glTexImage2D target level internalFormat width height border format type data))
+	(else
+	 (%glTexImage1D target level internalFormat width border format type data))))
+
+(export set-gl-texture-image)
+
+;;;
+;;; 3.8.12 Texture Objects
+;;;
+
+(define (gl-generate-texture)
+  (let ((tv (u32vector 0)))
+    (%glGenTextures 1 tv)
+    (u32vector-ref tv 0)))
+
+(export gl-generate-texture)
+
+(re-export (%glBindTexture . gl-bind-texture))
+
 ;;;
 ;;; 4.1 Per-Fragment Operations
 ;;;

[-- Attachment #4: 20130501-with-gl-push-matrix.patch --]
[-- Type: application/octet-stream, Size: 500 bytes --]

diff --git a/figl/gl.scm b/figl/gl.scm
index edbd7c8..090f9ff 100644
--- a/figl/gl.scm
+++ b/figl/gl.scm
@@ -273,10 +273,13 @@
 (define-syntax with-gl-push-matrix
   (syntax-rules ()
     ((_ body ...)
-     (begin
-       (%glPushMatrix)
-       body ...
-       (%glPopMatrix)))))
+     (call-with-values
+         (lambda ()
+           (%glPushMatrix)
+           body ...)
+       (lambda vals
+         (%glPopMatrix)
+         (apply values vals))))))
 
 (export-syntax with-gl-push-matrix)
 

Re: SLAYER announcement and help request for preparing a GNU package

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]

2013/5/7 Javier Sancho <jsf@jsancho.org>

> Panicz Maciej Godek wrote:
> > I even managed to build it, but for some reasons the demos won't run. I
> get
> > the following error:
> > gacela/video.scm:175:2: In procedure init-gl:
> > gacela/video.scm:175:2: In procedure module-lookup: Unbound variable:
> > set-gl-hint
>
> The reason is, oh my god, you are the first who test my code.
>

:) I guess that's how it begins.
I'm trying to build a portable package for slayer, and I must say that in a
way it's much more difficult than programming (which is actually a great
pleasure) -- there's a lot of reading and figuring out how to 'get it right'

When I started this project, I made demos and some documentation, but
> I stopped maintaining them because nobody was interested. Makefiles
> compile OpenGL and SDL bindings, but now I use Figl and compilation is
> not needed. The error with set-gl-hint comes because I have a figl
> version with some improvements. I've sent patches to figl maintainers.
>

I've applied all three patches, and I got a new error:
gacela/games/guybrush$ ./guybrush.scm
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not
been called
[xcb] Aborting, sorry about that.
guile: ../../src/xcb_io.c:178: dequeue_pending_request: Assertion
`!xcb_xlib_unknown_req_in_deq' failed.
Abort (core dumped)

gacela/games/tetris$ ./tetris.scm
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server
":0.0"
      after 129 requests (128 known processed) with 18 events remaining.

Currently, Gacela is in a very unstable state. Demos, for example, use
> an old version with a more OOP style, because when I wrote them I was
> beginning to understand Lisp and functional programming. But actually
> I'm reestructuring all the code looking for a more elegant, beatiful,
> functional style.
>
>
I don't think those two paradigms rule each other out. I believe that games
and user interfaces are the cases where OOP feels at home, but it seems a
good practice to avoid mutable variables wherever they're unnecessary. I
think John Carmack is quite just in this regard:
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/


> > If it comes to code, I see that you have a more polling-style approach
> for
> > processing input. My desire is to get a system that never stops being
> > reconfigurable -- to truly separate the user interface from program
> logics.
> > I don't know if it's achievable, but I have a feeling that such
> direction is
> > worth exploring
>
> Yes, your style is more callback style. I personally prefer polling
> because then I can read the code sequentially. But it's a personal
> consideration.
>
> > All these concepts sound very interesting, but I'm curious whether they
> are
> > reflected the code somewhere.
>
> For the moment, no. But I have a lot of papers :-)
>

I'm curious where will it go :)

regards

[-- Attachment #2: Type: text/html, Size: 4559 bytes --]