That's a great point. I definitely agree that erring on the side of modules is better. I just worry about times when the purpose of a module is not clearly defined at the outset (e.g. when it only contains one function that is only used in one other module). I have often seen that devolve into the "helper" module, where random functions collect.
I'm also not sure I buy the assertion that all code you would want to test is code you would want to export publicly. Do you have any reasoning to support that idea?
Good find! I can't seem to find a comment that indicates what the new limit is though. Experimentally, we were seeing processes dying at around the 1.7GB to 2GB range.
Did you find anything indicating what the expected new limit is?
sagichmal, could you elaborate on "we were able to map a fan-in-on-read stream product to a data model that could be implemented with a specific type of CRDT"? The post (which is awesome btw) glosses over exactly how Roshi is used to solve the problem presented in the first half of the post - or at least it seems that way to me as I am unfamiliar with CRDTs.
Yeah, that's a good point, but if you got all the CoffeeScripters' attention and then showed them that CoffeeScript is just one possible improved syntax...
> Sweet.js doesn't have the ability to make whitespace significant
Feature, not a bug? But yeah, I guess that would be an impediment to implementing CoffeeScript. I'd like to see some of the CoffeeScript syntax implemented but without whitespace dependency (so it would have to be a modified version of the syntax).
Awesome stuff. John Resig, if you're in here, can you give any details on the challenges of instantly updating the Processing sketch? I can just wait for the blog post, but I'm really curious.
Also, what components exactly are you planning to release open source? The other work in this area that I've been able to find is very tightly coupled to the rendering library (d3 or PJS). Is the Khan Academy system open to alternate rendering libraries?