guile-sdl-devel Mailing List for guile-sdl

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

n his bo

Hi,

Sorry I have not been very active just recently. I have had some personal
health problems. I got a bug off a family member and have not been feeling
very well.

Its great that things are coming along with guile-sdl. I am certainly as
interested as ever. I will try and sort out access to sf for you.

Happy Hacking,

Joel.

Hi,

Haven't heard from anyone in a while.  Is there a lack of interest in
guile-sdl, or lack of time?  Since the wrappers have come quite a ways
from our initial projects, it would be good to make them available.
I'd prefer to do this on the sourceforge site, but I don't have
access.  If I don't hear from anyone soon I may just polish up the
documentation and make a 0.2.0 announcement pointing to my own site.

Hope all is well,
Alex Shinn

... is available at http://synthcode.com/code/guile-sdl/.

I've added SDL_gfxPrimitives back in, and all modules use the snarfer
for both defs and docs.  I've also done some cleanup, several
bugfixes, and am testing for libs and conditionally compiling with
autoconf again.  Almost all functions are documented.

At this point I think this merged branch has everything any of the
three initial releases had, plus much more.  I'm sure everyone's been
busy over the summer with travel and moving, but we should really make
this available on the sourceforge site, or people may get the idea
that development on guile-sdl has died off.

Let me know if you have any problems w/ building or testing.

-- 
Alex Shinn <fo...@sy...>

... now uses the snarfer defs to generate both the .x files for
function definitions, and the .texi files to be included in the
manual.

Available at http://synthcode.com/code/guile-sdl/

-- 
Alex Shinn <fo...@sy...>
http://synthcode.com/

Not a lot of changes, but until we're working off the same CVS I don't
want to make too many modifications without sending them out to
everyone.  I've added some general bug-fixes, split a lot of the huge
sdlvideo files into separate files (for surface/rect/color), and also
incorporated Joel's snarfer defs.  They're not being used yet, but
that will just be a few quick rules in the Makefile and then we can
generate both the texinfo docs (to be included by the main
guile-sdl.texi) and the .x files so we don't have the mess with all
the explicit scm_c_define_gsubr + export.

You can find the latest version at

  http://alexshinn.com/code/guile-sdl/

Please excuse the vanity site, it's just a place-holder until my new
domain propagates :)

-- 
Alex

>>>>> "Vikram" == Vikram Subramanian <vi...@ww...> writes:

    Vikram> Hi,
    Vikram> Alex Shinn wrote:

    >> Things are shaping up, I think the only outstanding issue was
    >> the constants... should they all be numbers, symbols, or mixed
    >> numbers and symbols?  Another option I hadn't mentioned is that
    >> they all return symbols, but accept either numbers or symbols
    >> on inputs (and that would be lists of symbols for flags).

    Vikram> MY vote is for mixed symbols and numbers.

OK, I've put up a 0.1.4 release at

  http://eyeofdog.org/foof/code/guile-sdl/

which takes a mixed symbols and numbers approach, and am now using the
same constant names as the original C.  I've also changed the
functions I had returning lists to return alists.  I think those are
all the big issues.  This will need a little clean-up, but once we do
that and fix the autoconf checks, and verify that everything works for
everyone (make check after building), we should make this the public
version.  Oh, and add a lot of documentation :)

-- 
Alex Shinn <fo...@de...>
Lisper, Smalltalker, and all around poor speaker

>>>>> "Joel" == Joel Smith <jo...@mo...> writes:

    Joel> Are we sure that we want to use the smob:member and
    Joel> smob:set-member!  convention? Its just that I have never
    Joel> seen it used before. Would it be better to use smob-member
    Joel> and smob-member-set! Vikram seemed to suggest that he had
    Joel> seen the use of smob:member somewhere though.

There are two places you'll typically see `:' in scheme names: one is
as an alternate prefix separator, so our functions could be
sdl:create-rgb-surface, etc.  This matches the XML namespace syntax,
but apart from that is less common than using `-', and we all picked
sdl- so we should stick with that.

Where you'll also see `:' is in accessors.  If you look at some of the
POSIX functions, you'll see this in things like the filesystem stat
accessors, pwent fields, and the networking functions.  On the other
hand, these are only accessors, the :set-foo! is my invention.  Also,
this syntax isn't used in the other modules we're likely to want to
work with (gtk/opengl), so we might want to avoid it.  But there are a
few things I want to clean up before worrying about that.

Specifically, the enums/flags.  I'm in the middle of converting these
to two different conceptual types.  Any function expecting a
constant/enum as input will take either a symbol (and convert it
automatically) or the numerical value.  Any function expecting a
logior'ed flags fields will take either a list of the symbols for that
flag, or (if you need it for efficiency) the exact numerical value.
Functions return the symbol (or list of symbols) for these
values... this may seem like a lot of extra work for the lists, but
this is a fairly rare operation, and not something you're likely to
put in a loop.  Also, if we decide we need to optimize this, we can
add specific test functions.  So instead of

  (memq 'SDL_SRCALPHA (sdl-surface:flags surface))

to test if surface uses alpha blending (effectively expanding and
contracting the flags list), you could do

  (sdl-surface:flags-srcalpha? surface)

Also, to keep things simple and consistent with other modules, I think
we should just stick to the SDL_FOO style symbols for constants.

    Joel> Also the ./configure script does not seem to check for the
    Joel> SDL libraries.  The checking is commented out. I think we
    Joel> really need to put it in.

I had commented it our while getting everything else working on my
system, since I believe (last I checked), you'll get an error if you
uncomment those lines, and I didn't feel like mucking with autoconf
yet.

    Joel> If both of you want to offically join the sourceforge
    Joel> project then I can give you cvs access. Then we can upload
    Joel> the lastest version :)

Yes, please :)  I Hope to have the flags stuff done this evening, so we
should wait for that and put in proper autoconf checks for SDL and the
two separate modules before announcing a new release (would this be
0.2.0)?

-- 
Alex Shinn <fo...@de...>
Lisper, Smalltalker, and all around poor speaker

Hi,

I am back now from my holiday ;) Sorry I was away for so long. I only
planned a few days, but we decided to stay longer.

I think I have managed to catch up on all the disscussions so far. There
are just some things I would like to ask.

Are we sure that we want to use the smob:member and smob:set-member!
convention? Its just that I have never seen it used before. Would it be
better to use smob-member and smob-member-set! Vikram seemed to suggest
that he had seen the use of smob:member somewhere though.

Also the ./configure script does not seem to check for the SDL libraries.
The checking is commented out. I think we really need to put it in.

If both of you want to offically join the sourceforge project then I can
give you cvs access. Then we can upload the lastest version :)

Happy Hacking,

Joel.

probably you don't want to do this.  if you do actually want to do this,
warn people in the README; otherwise they will be surprised.

thi

________________________________________________
diff -c configure.in\~ configure.in
*** configure.in~	Mon Jun  4 17:04:01 2001
--- configure.in	Sun Jul  1 15:19:46 2001
***************
*** 2,8 ****

  AC_INIT(sdl.c)
  AM_INIT_AUTOMAKE("guile-sdl", "0.0.1")
! AC_PREFIX_DEFAULT(/usr)

  CFLAGS="-Wall -pedantic -ansi"

--- 2,8 ----

  AC_INIT(sdl.c)
  AM_INIT_AUTOMAKE("guile-sdl", "0.0.1")
! dnl AC_PREFIX_DEFAULT(/usr)

  CFLAGS="-Wall -pedantic -ansi"

Diff finished at Sun Jul  1 15:20:34

Hi,

Alex Shinn wrote:

> ... is up on my site, now including Vikram's SDL_rotozoom, with a test

> script and an example implementation of the painter language from

> SICP.  Whereas rotozoom is only two functions in a relatively small
> distribution, SDL_gfxPrimitives is a bit larger and depends on some
> third-party libraries, so I think it should be a separate module.

Will check it out today, in the little time I have. Am getting ready to
move to another city to start working from Monday!! I don't think I'll
have trouble getting hold of a computer but I might go missing for a few
days.

> Things are shaping up, I think the only outstanding issue was the
> constants... should they all be numbers, symbols, or mixed numbers and
> symbols?  Another option I hadn't mentioned is that they all return
> symbols, but accept either numbers or symbols on inputs (and that
> would be lists of symbols for flags).

MY vote is for mixed symbols and numbers.

... is up on my site, now including Vikram's SDL_rotozoom, with a test
script and an example implementation of the painter language from
SICP.  Whereas rotozoom is only two functions in a relatively small
distribution, SDL_gfxPrimitives is a bit larger and depends on some
third-party libraries, so I think it should be a separate module.

Not much, but it's now the weekend so I'll have time to get some more
done.  Joel, you should really incorporate this into CVS and give
Vikram and I access so we can all work together.

Things are shaping up, I think the only outstanding issue was the
constants... should they all be numbers, symbols, or mixed numbers and
symbols?  Another option I hadn't mentioned is that they all return
symbols, but accept either numbers or symbols on inputs (and that
would be lists of symbols for flags).

-- 
Alex Shinn <fo...@de...>
Lisper, Smalltalker, and all around poor speaker

OK, the last merged tarball I sent out was pretty unusable, I meant to
fix it up sooner but was out of town this weekend and thus lost most
of my hacking time.  I did manage to put up a better tarball up at my
site, though:

  http://eyeofdog.org/foof/code/guile-sdl/guile-sdl-0.1.2.tar.bz2

It removes all INUM references in favor of the general scm_num
functions, and cleans up the layout a little bit, creating separate
mixer and ttf modules (not yet detected by autoconf), and also
includes Vikram's joystick and cdrom bindings.  My local CVS has most
of the gfxPrimitives and rotozoom merged, but it's late and I'm
turning in for the night.  We should really get this into the central
sourceforge CVS as soon as possible.

-- 
Alex Shinn <fo...@de...>
Lisper, Smalltalker, and all around poor speaker

> OK, as I said I had already started working on this.  The code is at
> http://eyeofdog.org/foof/code/guile-sdl/guile-sdl-merged.tar.bz2.  I'm

Got it. I couldn't get to do anything today and he only thing I did was to
get the CVS vesrion of Guile up, which took some time since Guile had
problems with the broken gcc that comes with Redhat.
Tomorrow I'll be removing gh_ stuff from Joystick, CDROM and Mouse codes and
maybe even from the sdl-mixer. I'm not touching the video part since it's
mostly Alex's code.

BTW the stable vesrion SDL_ttf-2 that works with Freetype2 is out and at
http://www.libsdl.org/projects/SDL_ttf/

>>>>> "Vikram" == Vikram Subramanian <vi...@ww...> writes:

    Vikram> OOps, Got my mail filters wrong and this went into the SDL
    Vikram> folder and I didn't see the previous mail. I also thought
    Vikram> of init-ing as the module is loaded , but how do we handle
    Vikram> errors in initiliazation.

Good point... we could let them use wasInit() to be sure everything
went OK.  If they're being careful they have to check the status of
the init anyway.

    >> In these cases I was using simple lists.  The above example
    >> would return (2 20 10), which is a little faster.  I suppose
    >> the question is are we more concerned with speed or having the
    >> results make sense in other contexts?

    Vikram> I thought writing docs and explaining it to someone else
    Vikram> would be a much easier job with alists.

Since these are basically convenience functions, and a normal tight
event loop would use the accessors for the event smob, we don't need
to be especially efficient here so the alists sound better.

    Vikram> Then I'll start the work??.Tomorrow (21st) I'll take your
    Vikram> sources put them in a layout similar to mine (change
    Vikram> filenames if needed) and then add my extra functions and
    Vikram> stuff and maybe have one source file using snarfing.  Then
    Vikram> we better put it up in the CVS(or I'll tarball it) and
    Vikram> continue with conversion to a snarfable version by
    Vikram> dividing the work.

OK, as I said I had already started working on this.  The code is at
http://eyeofdog.org/foof/code/guile-sdl/guile-sdl-merged.tar.bz2.  I'm
using your layout and file names, but most of my code, with almost all
gh_ functions renamed, and SCM_INUMP replaced with scm_exact_p.  I
started converting SCM_INUM and gh_scm2long with scm_num2long, but was
careless reading the prototype... where I have

  scm_num2long (s_num)

I should have used

  scm_num2long (s_num, (char*) SCM_ARGN, "function-name")

I won't have time to help tonight, but will have time tomorrow.

-- 
Alex Shinn <fo...@de...>
Lisper, Smalltalker, and all around poor speaker

> Mentioned in my previous email... being able to choose which
> subsystem[s] you want with (use-modules (sdl subsystem)).  This also
> has the advantage that we could theoretically handle SDL
> initialization transparently according to what modules they use, so
> there would be no need to call (sdl-init subsystems).  The only trick
> to this is handling the init flags, noparachute, threads, and opengl.
> These could possibly perform a re-initialization.

OOps,
    Got my mail filters wrong and this went into the SDL folder and I didn't
see the previous mail. I also thought of init-ing as the module is loaded ,
but how do we handle errors in initiliazation.

> This was just an idea... I feel weird using uppercase in scheme code,
> but then people have to learn the translation mechanism.  Does guileGL
> provide both?  We could certainly do that.

Taken as Accepted.

> You'll see both in Scheme code.  I kind of like the : notation because
> it's shorter and makes the function stand out as an accessor.

Shorter notation is fine with me.

>     Vikram> 3) I have some xtra bindings for Joystick, Mouse, Cdroms,
>     Vikram> SDL_gfxPromitives and rotozoom which can be put in
>
> Nice.  Especially rotozoom, I hadn't seen this before and was looking
> for a good scaling/rotation lib.

> It's not meant for realtime rot and zooming though, but may work for some
> cases.It is aimed more at pre-rendering - Like creating rotated versions
> of a sprite at the start of the game.

> In these cases I was using simple lists.  The above example would
> return (2 20 10), which is a little faster.  I suppose the question is
> are we more concerned with speed or having the results make sense in
> other contexts?

I thought writing docs and explaining it to someone else would be a much
easier job with alists.

> Yes, I was already making SDL_ttf optional.  I don't think anyone uses
> SDL without SDL_image, we don't need to special case for that.

>

> If "around the corner" means available and soon to be dubbed stable,
> then yes :)

The source is currently at http://www.libsdl.org/cvs/SDL_ttf-2.0.3.tar.gz

> Ah, and you come up with the opposite decision on the direction of the
> merge :) But after starting the other way last night, you may be
> right.  I'm just not very good with autoconf, so I wanted to use your
> layout, but if you can make SDL_mixer and SDL_ttf optional in my
> source tree, that's great.

Then I'll start the work??.Tomorrow (21st) I'll take your sources put them
in a layout similar to mine (change filenames if needed) and then add my
extra functions and stuff and maybe have one source file using snarfing.
Then we better put it up in the CVS(or I'll tarball it) and continue with
conversion to a snarfable version by dividing the work.

I'll wait for one more mail from you, and tell me if you have started on
something.

>>>>> "Vikram" == Vikram Subramanian <vi...@ww...> writes:

    >> None of the projects are using separate Guile modules, (which I
    >> think we should be), so there's some discussion to be done on
    >> that front.

    Vikram> I don't get you. What do you mean by seperate Guile
    Vikram> modules??

Mentioned in my previous email... being able to choose which
subsystem[s] you want with (use-modules (sdl subsystem)).  This also
has the advantage that we could theoretically handle SDL
initialization transparently according to what modules they use, so
there would be no need to call (sdl-init subsystems).  The only trick
to this is handling the init flags, noparachute, threads, and opengl.
These could possibly perform a re-initialization.

    Vikram> To start off, these are the issues that struck me first as
    Vikram> I went thro' Alex's source.

    Vikram> 0) All gh_ stuff(from anything that's taken from mine) to
    Vikram> be replaced by SCM_.

Very easy, mostly query-replace.

    Vikram> 1) How should the enums/constants be named - Mine is like
    Vikram> SDL_INIT_VIDEO while Alex's is like sdl-init/video. Could
    Vikram> we provide both?? (As in guileGL)

This was just an idea... I feel weird using uppercase in scheme code,
but then people have to learn the translation mechanism.  Does guileGL
provide both?  We could certainly do that.

    Vikram> Setters and getters for SMOBS - Mine is like
    Vikram> "sdl-color-get-r" "sdl-color-set-r!"(BTW I don't have a
    Vikram> SMOB for SDL_Color) .Alex's is like "sdl-color:r"
    Vikram> "sdl-color:set-r!".  I think we will stick with Alex's
    Vikram> convention for this (I just checked out the doc for host
    Vikram> database in Guile networking)

You'll see both in Scheme code.  I kind of like the : notation because
it's shorter and makes the function stand out as an accessor.

    Vikram> Related stuff - I had problems using SCM_INUMP with Uint32
    Vikram> numbers.gh_exact_p seemed to work with it.Similarly I had
    Vikram> to use gh_scm2ulong since gh_scm2long simply choked and
    Vikram> said it was beyond the range. Alex is using only SCM_INUMP
    Vikram> for everything while Joel seems to be using SCM_NUMBERP
    Vikram> for Uint32 things.I think INUMP doesn't work with Uint32-s
    Vikram> and should be converted with SCM_NUM2ULONG.

Right, SCM_INUMP is definitely wrong :) It should probably be the
equivalent to the gh_ functions you're using, scm_exact_p and
scm_num2long.

    Vikram> 2) Handling the SDL_Event structure. I return a simple
    Vikram> alist.This was used simply because it was easier to write
    Vikram> that way.Alex is using a SMOB. The only argument I have is
    Vikram> that it might reduce programmer error. He can't request a
    Vikram> field that does not mean anything for that event
    Vikram> type. Obviously SMOB-s are faster.

If we're worried about programmer error we can do type checking in the
smob functions... probably a good idea.

    Vikram> 3) I have some xtra bindings for Joystick, Mouse, Cdroms,
    Vikram> SDL_gfxPromitives and rotozoom which can be put in

Nice.  Especially rotozoom, I hadn't seen this before and was looking
for a good scaling/rotation lib.

    Vikram> 4) I have used alists generously.For example for getting
    Vikram> the current mouse state - It returns the state of the
    Vikram> mosue like ((state . 2) (x . 20) (y.  10)). Basically I
    Vikram> have used it in places where things are read only and
    Vikram> retuned back by functions or in places where more than one
    Vikram> value is returned by a function thro' pointers. I don't
    Vikram> think it's much of a performance hit and avoids
    Vikram> unneccessary SMOBs.

In these cases I was using simple lists.  The above example would
return (2 20 10), which is a little faster.  I suppose the question is
are we more concerned with speed or having the results make sense in
other contexts?

    Vikram> 5) As for package requirements - I feel SDL and SDL_image
    Vikram> can be made compulsory while SDL_mixer, SDL_ttf can be
    Vikram> made optional. Or do we make SDL_image as also optional??

Yes, I was already making SDL_ttf optional.  I don't think anyone uses
SDL without SDL_image, we don't need to special case for that.

    Vikram> There is a relase of SDL_ttf2 around the corner that uses
    Vikram> Freetype2. Should we use that instead of the current
    Vikram> SDL_ttf??

If "around the corner" means available and soon to be dubbed stable,
then yes :)

    Vikram> So I think, it would be easier to merge mine into Alex's
    Vikram> and maybe introduce snarfing on the way and reorganise

Ah, and you come up with the opposite decision on the direction of the
merge :) But after starting the other way last night, you may be
right.  I'm just not very good with autoconf, so I wanted to use your
layout, but if you can make SDL_mixer and SDL_ttf optional in my
source tree, that's great.

    Vikram> source files, Makefiles etc. I haven't used snarfing
    Vikram> before. Finally, what's the form of the documentation.

I started some texinfo documentation.  This would ideally make use of
the snarfer, which I haven't played with yet.  I wrote several test
scripts, but we should have some more complicated examples.

-- 
Alex Shinn <fo...@de...>
Lisper, Smalltalker, and all around poor speaker

Hi,

Alex Shinn wrote:

> Things that should be obvious:
>
> 1) by a vote of 2-1, the name of the project should be guile-sdl.

I support that too. Actuall I wanted Projector to be a higher level game
library, but ended out to be a wrapper for SDL.

> 2) we have a lot of interest already, and a lot of discussion to do.
>    Since there's already a sourceforge project set up, we should take
>    advantage of that and use the web/cvs and mailing lists provided
>    there.

I see all 3 of us on the list.

<Snip>

> None of the projects are using separate Guile modules, (which I think
> we should be), so there's some discussion to be done on that front.

I don't get you. What do you mean by seperate Guile modules??

> I'd be curious as to each of your experience in C, Scheme and game
> programming.  I feel most comfortable in Scheme, but am a strong C
> programmer and already have experience creating Python bindings for
> the PowerPak library (built on top of SDL).  I've been playing with
> game programming for years now, but am not up on low-level graphics
> algorithms (I'm learning though).

I am more of a C programmer.I am newbie as far as Lisp, Scheme or Guile is
concerned.

To start off, these are the issues that struck me first as I went thro'
Alex's source.

0) All gh_ stuff(from anything that's taken from mine) to be replaced by
SCM_.

1) How should the enums/constants be named - Mine is like SDL_INIT_VIDEO
while Alex's is like sdl-init/video. Could we provide both?? (As in guileGL)

Setters and getters for SMOBS - Mine is like  "sdl-color-get-r"
"sdl-color-set-r!"(BTW I don't have a SMOB for SDL_Color) .Alex's is like
"sdl-color:r" "sdl-color:set-r!".
I think we will stick with Alex's convention for this (I just checked out
the doc for host database in Guile networking)

Related stuff - I had problems using SCM_INUMP with Uint32
numbers.gh_exact_p seemed to work with it.Similarly I had to use
gh_scm2ulong since gh_scm2long simply choked and said it was beyond the
range. Alex is using only SCM_INUMP for everything while Joel seems to be
using SCM_NUMBERP for Uint32 things.I think INUMP doesn't work with Uint32-s
and should be converted with SCM_NUM2ULONG.

2)  Handling the SDL_Event structure. I return a simple alist.This was used
simply because it was easier to write that way.Alex is using a SMOB. The
only argument I have is that it might reduce programmer error. He can't
request a field that does not mean anything for that event type. Obviously
SMOB-s are faster.

3) I have some xtra bindings for Joystick, Mouse, Cdroms, SDL_gfxPromitives
and rotozoom which can be put in

4) I have used alists generously.For example for getting the current mouse
state - It returns the state of the mosue like ((state . 2) (x . 20) (y.
10)). Basically I have used it in places where things are read only and
retuned back by functions or in places where more than one value is returned
by a function thro' pointers. I don't think it's much of a performance hit
and avoids unneccessary SMOBs.

5)  As for package requirements - I feel SDL and SDL_image can be made
compulsory while SDL_mixer, SDL_ttf can be made optional. Or do we make
SDL_image as also optional??
There is a relase of SDL_ttf2 around the corner that uses Freetype2. Should
we use that instead of the current SDL_ttf??

So I think, it would be easier to merge mine into Alex's and maybe introduce
snarfing on the way and reorganise source files, Makefiles etc. I haven't
used snarfing before. Finally, what's the form of the  documentation.

Introducing docs within the code is going to take some work and patience.
As Alex said I woul like to get over with this as soon as possible and do
some programming with it.

>>>>> "Joel" == Joel Smith <jo...@mo...> writes:

    Joel> I agree that it would be best to use the guile-sdl name and
    Joel> the sourceforge site. Of course I would be willing to give
    Joel> admin status to anybody who wanted it.

You've already taken the initiative and set things up, I see no reason
you shouldn't remain the admin.  But you should add Vikram and I as
developers, or joint admins if that's allowed.

    Joel> As Alex said my guile-sdl project has far less of the SDL
    Joel> API covered so I think it would be best to use one of the
    Joel> other two as a starting point for the merging. Which one I
    Joel> personally don't know.

I think Vikram has a cleaner directory/file structure, and better
autoconf checking, so I've started merging my own code into his
project, using his files but preferring all of my actual functions
where they're duplicated, since we should probably move away from the
gh_ interface.  Then we can grab Joel's doc strings and start using
the snarfer.

I'm using the latest guile from cvs (to be released as guile 1.6 RSN),
and I'd suggest we move to this.  It means moving to the latest
autoconf/automake/libtool to build it, though.

Other conflicts:

Colors: Joel and I are using a smob, Vikram is using straight numbers.
I think it's cleaner to use a smob, so you can set individual r/g/b
components, and use the same color object on different bpp surfaces.

Constants: The technique used by other guile modules (like guile-gtk)
is to treat these as symbols, and translate them coming in and out as
parameters.  logior-ed flags are passed as a list of symbols.  I took
a hybrid approach, where most constants were just numbers, but event
types and keysyms are symbols, so you can use them in case statements.
The intent was to change this so that everything but flags would be
symbols, holding off on flags since it's a lot of overhead to
translate a symbol list to a logior-ed value on primitive functions.
I'm certainly open to ideas here, though.

Modules: As it is now, (sdl mixer) is a separate module, and I'm
changing (sdl ttf) to be separate as well.  The real question is
whether subsystems should be separate, so if you only need video for a
program you can just (use-modules (sdl video)) without having to
initialize all the other functions and constants (including many
keysyms).

Apart from that we seem to be spot on in code agreement.  Let me know
what you think.

-- 
Alex Shinn <fo...@de...>
Lisper, Smalltalker, and all around poor speaker

Hi,

The problem seems specific to 2.96.x. When I compiled it with 2.95.x it
was fine.

I am trying to get cvs up at the moment but I am having a little trouble.

Happy Hacking,

Joel.

Have you descided yet as to what you are going to do re: the problems GCC
2.96 seems to have compiling the macros used in the current version of the
code, you could just releace it and say it doesn't work fully with GCC 2.96,
at least in the first releace, at least once we get some code publicly
available then there's a chance of getting more people on the project.

GCC 2.96 is still considered to be a development releace at this point, and
has several known bugs, so it might be worth testing the code on the latest
stable releace of gcc, 2.95.3, since the code compiled and functioned
correctly on the version of GCC distributed with the previous edition of the
mandrake distribution.

=======================================================
SPI Europe Ltd
10 Parkgate
Little Germany
Bradford BD1 5BS
Tel: 01274 701150
Fax: 01274 701160
=======================================================

2001	Jan	Feb	Mar	Apr	May	Jun (11)	Jul (6)	Aug (3)	Sep	Oct	Nov	Dec
2014	Jan	Feb	Mar (2)	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec