Re: [Guile-sdl-devel] Merging guile-SDL-s [Was - Announcing Projector - Guile bindings for SDL]

[Alex S. <fo...@de...>]

>>>>> "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