There's no preplanned development schedule. When there's an essay I want to write, I write it; when I want to work on Arc, I work on it-- and when there's a significant amount of new stuff, I make a new release.
You don't have to work on it but we still would like some direction from you, like thoughts on anarki and the new editions that are added by the community.
The main thing I wish someone would write is a profiler that (a) had sufficiently low overhead that it could run in production code and (b) could be installed without huge changes to ac.scm and/or the underlying MzScheme.
Oof. Tough. I and raymyers did some work back on a profiler when we were optimizing treeparse, but it didn't quite work well in my use-case.
Certainly it seems to involve deeper hackery skills than I seem to have right now ^^.
As an aside, it might be slightly easier to actually insert profiling code in arc2c. Each function has its own ID number in arc2c and all we need is some sort of index from ID number to original function name (given that a function in arc2c may be split by CPS conversion, so a function with a name may end up being split into several functions),
> You don't have to work on it but we still would like some direction from you, like thoughts on anarki and the new editions that are added by the community.
I had been under the impression that it was supposed to last for one hundred years, not languish for one hundred years, but I suppose I might have misread something :/