Currently he's working on implementing various techniques in Smalltalk that most regard as "only for pure functional programming languages" - partial continuations, zippers, monads and other such fun things. Also tricks from logic programming like unification.
"Parameterise" Browser, letting it call out to something that manipulates classes (adding them, removing them, renaming methods, etc.). This something will come in two flavours: a mock will record what happened (class Foo added, method #bar removed from Foo, etc.) while the real implementation will affect Smalltalk and the actual classes. If this approach works cleanly, maybe we can copy the approach for Monticello and OmniBrowser.
Work towards allowing nested classes.
Figure out interoperability between Monticello and git: first, a commit to Monticello should result in a commit to an arbitrary git repository. Second, we should be able to point to a git repository and have Monticello tools use it like they would a normal git repository.
Write an IntelliJ plugin that will talk to a running Smalltalk image through a WebDAV filesystem (piggybacking on Craig Latta's work).
Scratchpad:
BFAV notes from Daniel Vainsencher:
2. Hard to find things in the BFAV - I think you're absolutely right.
Some ideas (for anyone that wants to improve the process), in order of
increasing madness:
- Make the BFAV order the posts according to simple criteria: dont show
topics I'm last poster on, show at top subjects I posted on at some
point, and am not last poster on...
- Use the Bayesian text classifier in Celeste to order the rest of the
posts in order of "likely to be interesting to specific user".
- Do something server side that annotates/autocloses fixes that are now
identical to the code in the image (because another fix got there first,
for example).
- Use BWT algorithm to detect code duplication between different
proposed patches and notify authors so they can merge/review/complete
one anothers posts, preventing some of the duplication, and turning it
into mutual aid.
- Use some sort of classifier (Bayes, SVM...) to detect patches that
are "unlikely to be approved", and notify the author. If people start to
classify why they don't want to approve a patch ("dont see what it
fixes", "don't understand the code", "not documented enough, what the
heck is it"...) then patch authors could even get a predicted cause for
failure in some cases.Category Home Page>http://c2.com/cgi/wiki?CategoryHomePage
