Sam Deane

Don't feel bad, it's fine. I did some stuff for Drew & Alex on Agenda once that took about nine months to see the light of day so this is...

On the subject of call-rate limiting: You might be able to work around the limit using ETags, which allow you to poll for changes and only get "charged" if something...

Off the top of my I can't recall whether the ETag mechanism even works with all of the API, or if it's just for some things. I am using it...

Sorry, I just caught up and saw the responses. Sounds like 1.9 will fix my immediate problem, but yell if you want me to try to diagnose the other thing...

What's the state of play with this branch? It seems to be somewhat behind the master, and I'm wondering if it would be safe to pull the latest master changes...

For what it's worth, this is the current solution I've ended up with. After generation of the output, I strip out **all** blank lines. As you can imagine, this leaves...

From Cocoascript, something even simpler will kill it: ``` for (var n = 0; n < 10000; n++) { var test = [NSString stringWithString:"1"]; print(n + ": " + test);...

The problem seems to be centred around Javascript Core's memory management, and its interaction with MOBox. MOBox basically exists to associate a JS object with a Cocoa object, and hold...

It's tempting to blame it all on JSC, and it is certainly possible that it's a bug, but that feels a little too convenient to me. My suspicion lies with...

One other bit of evidence. If we deliberately "leak" the JS object - by calling JSValueProtect on it when we make the MOBox - then we don't see the crash....