[gambit-list] The future of Gambit

Christian Jaeger christian at pflanze.mine.nu
Mon Dec 29 10:27:51 EST 2008


Bradley Lucier wrote:
> I've had a draft e-mail sitting in an IMAP folder for about 8 months  
> with the subject line "The future of Gambit", but with an empty  
> body.  Today I still don't know precisely what to put into this body,  
> but at least I found a blog entry that explains a bit of my feelings.
>
> I'm not exactly thrilled about the level of "outside" participation  
> in (core) Gambit development.  In fact, graphing the Gambit git  
> commit log would be a parody of the argument in
>
> http://www.gnome.org/~michael/blog/ooo-commit-stats-2008.html
>
> that the lack of non-Sun developers working on OpenOffice.org is an  
> indicator that it is not a healthy project.

I'm not sure you can draw direct conclusions from observations in
broadly developed projects. I've come from using language
implementations being developed by like hundreds of participants to
Gambit and see it a more fertile ground for my work than any of those
others.

I wouldn't go as far as saying that too many cooks always spoil the
meal, but at the same time that some projects are having many
contributors, they also don't offer a lean, understandable nor bugfree
base either. Like, I'm understanding *much* more of Gambit's internals
than I do about Perl's, even if am [have been] using Perl much longer
than Gambit.

That said, I'd agree that a linear development history with commits by
only one person looks funny in the context of a distributed version
control system; but there may be a few points to say about this:

- many people may not yet know well enough how Git works; I'm happy
about the move to Git, especially for the git format-patch feature,
which retains user and commit info (and makes discussion easy), but so
far I've been the only one sending such patches to the list

- I've got one patch (the one about the .gambc_history permissions)
which has not been applied to the Gambit repo yet, and I don't know why,
but it doesn't bother me much (except for having to not forget about it)
-- what I can do is keep such patches in my personal branch, and if I
feel that this branch is of interest to others I can publish it (either
on repo.or.cz by using it's forking feature to clone the Gambit mirror
there, or by asking Marc to get me a branch or a couple on his server;
I'm not sure yet what's the better idea, I will discuss with him as soon
as I get to it). (Then merging can start to happen and the history will
stop looking linear.)

- I can observe that some of the heavy Gambit users are just happy
asking Marc when they need a feature, and so far he seems to have been
able to satisfy their needs; of course this way those users are getting
higher quality results faster than if they'd have to do it themselves.
Maybe we should find people (I'm hoping I won't be the only one) who can
take part of this job instead, so that Marc will have more time for
other new developments; but I'll see Marc within a few weeks time and
will be able to discuss with him how work sharing might work out best.

> I've studied the Gambit source code a bit, and even made some  
> contributions over the years, but Marc's programming style is  
> something I have not seen elsewhere---highly macroized and layered,  
> there are patterns in the coding techniques but not ones that I've  
> been able to unravel in general.    Perhaps one way to help new  
> developers get into Gambit would be fore Marc to take a subsystem and  
> write down an explanation of how the macros and layers of code for  
> types, exceptions, constructors, functions, ... of that subsystem  
> work.

I don't expect good contributors will automatically come if one provides
such info. But maybe you should point out the problems *you* are having
understanding the code for what you want to do (and/or what you want to
do), and then we'll answer each other's questions on the list, and maybe
write some wiki pages as the result? Also note that quite some
discussion during this year has taken place on IRC (on #gambit on
freenode.net, and I've also been queried quite heavily by some people
who preferred private chats); not much of it has made it to the wiki yet
though.

>   (Christian Jaeger seems to have had some success in doing  
> this, but it would be good to have an explanation of how Marc sees  
> the construction of subsystems of the runtime.)  Just to get an idea  
> of Marc's programming style would allow others to divine more easily  
> the structure of the code.
>   

A few things:

- most macros are accessors from type definitions; if you know which
types there are, you can understand many of those macros.

- I did complain to Marc about those macros quite some time ago, mainly
because it prevented me from accessing structures at runtime, but (maybe
as a result of the complaint?) now you can just (include
"~~lib/_gambit#.scm") to get them back at runtime. (And the fact that
just loading this file takes up a considerable amount of memory makes
for a good explanation why those accessors are macros in the first place
:).)

- you may want to take a look at my object-to-sexpr code if you want to
quickly find out what a data structure contains:

git clone http://scheme.ch/gambit/experimental/object-to-sexpr/.git

(There *might* be a bug in it currently, I've seen cases where it shows
part of it's own result as part of the result, but I can't explain that
from my code, I'll have to discuss this with Marc some time.)

- Dpeschel has done some work to index Gambit sources, see
http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/User:Dpeschel

- the JazzScheme IDE has nice cross indexing features; maybe I'll [help]
look into how those can be brought to Gambit source code (non-Jazz
Scheme code).

> And happy holidays to everyone!

Thanks, a happy new year to everyone and the project

Christian.




More information about the Gambit-list mailing list