Re: [grt-talk] GRT in the year 2004 (space and beyond!)

[Jason Dagit]

Nikodemus Siivola wrote (on Tue, 25 May 2004 at 18:20 +0300):

 > I just realized, some of that stuff may already be on the savannah
 > CVS on some branch.

I'm bad with CVS concepts, it maybe be there in a format I don't
really know how to find :)

 > Branch is fine with me.

Okay, I'll do that later today if I can figure how the commands (I
have a little CVS reference book that I've not tried yet).

 > Sure, though on my grt hacking todo-list they have moved waayys up
 > in priority since I realized how frustrated I was with wierd
 > bottlenecks.

I totally understand.  It's the reason I've been annoyed with my
"ropes" implementation.  Sometimes the abstraction offered by CL comes
at great cost.  But I was thinking I would rather have GRT do the
things I want, even if it means waiting.  Besides, if we had an
impressive feature set with good API, I'm sure some performance freaks
would make contributions :)  But, keep your priorities where you
want.  Performance is always a good thing.  I just think at least one
of us should increase the feature set.

 >  * These will then be bundled up as "GAL, Graphics Algebra for
 >    Lisp" (or some other name), and made a separate project, under a
 >    MIT style license. Licensewise this is clear and simple, since
 >    a) unless I'm horribly mistaken all the GRT math code is by my
 >    hand b) it'll be a rewrite anyways.

I have no problem with the MIT style license, GPL, and LGPL.
Separating things out is wonderful news.  One of my subgoals with
helping out on GRT was to gain enough knowledge (and borrow code) to
write a first person shooter in lisp.  Nothing extravagant, just
enough to have a simple playable Quake style game.

 >  * My tentative schedule for the above it "during the summer", but
 >    as I'm also working on some other projects it remains to be seen
 >    how this pans out.

Fine with me.  You're a busy student, don't feel like you have to make
contributions in real time because we're doing it.

 > individual libraries, whenever it makes sense. The degree to which
 > this stage can reuse old GRT code depends on the getting
 > permissions from copyright holders (and of course the applicability
 > of that code).

You have my permission.

 >  * Supporting both wavelength and RGB models. I have no idea how to
 >    do this yet, or what it involves.

That is an interesting idea.  Sometimes I'm glad I saved my physics
texts.  I'm sure I can find some useful equations or starting points
for modeling wavelengths.  Combining the two intelligently may become
(more) obvious after we know how to model wavelength.

 >  * Better scene introspection thru layered scene component
 >  representation:
 >    scene objects will be CLOS objects, making it easy to poke
 >    around a scene. They will be compiled into an efficient
 >    representation (similar to what is used now) for actual
 >    rendering. The compiled representation may or may not have a
 >    back-pointer to the original -- keeping it *might* make *some*
 >    fancy stuff easier, but is also less space-efficient.

I'd need to see your ideas on this one.  Sounds like an neat idea, but
I have no clue what it really implies.  I assume this is a solution to
needing access to state for shaders to use.

 >  0) Relicense under MIT and keep on savannah.
 > 
 >  1) Relicense under MIT and move to common-lisp.net.
 > 
 >  2) Fork. GPL body stays on savannah and MIT goes on
 >  common-lisp.net.
 >     (Note: I don't think this is necessarily a bad option *if*
 >     someone either wants to keep GRT under GPL, or is interested in
 >     a different development strategy then my current third-system
 >     syndrome. Witness CMUCL and SBCL cross-fertilization for
 >     example.)
 > 
 >  3) Same as above, but both under MIT.

  4) We use 2 or 3 different licenses for the code.  I'm not sure of
     all the pros/cons, but I've seen several projects do this.  Just
     an idea to consider.  That would allow the users of GRT to choose
     the license that fits their needs.  For example, if anyone wanted
     to create a GPL'd project using our code is able to wrap GRT in
     the GPL.  On the other had, if some commercial company wanted to
     use GRT they could use the MIT license.  The way I understand the
     MIT license is that GLP'd projects that borrow code have to get
     permission to GPL the borrowed code if they want to extend it and
     have it be covered under the GPL.  I think this approach
     circumvents the need for permission.

Keeping the 0.1 release at savannah under the GPL is the
least we can do to pay back the FSF for letting us use their system
to create GRT.  And it has little impact on the future of GRT.  It
would become a project in need of a new maintainer is all.

I have no problem hosting our code on common-lisp.net.  If you think
that would benefit the CL community more that would be justification
enough by itself (regardless of license issuse).  Using savannah or
not using savannah will have little impact on the Free Software and
Open Source communities.  I bet having an apt-able Debian package
probably gets our code out to the masses better than sourceforge or
savannah.  People like easy installations.

 > code. If you feel like hacking on GRT, please do so.

Good :)

 > Hum. This turned out a tad longer then I planned...

That's fine, you have good ideas, it was a pleasure to read.

Jason