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.