Stéphane Épardaud
Stéphane Épardaud
Moving to 1.3
See http://www.nurkiewicz.com/2014/04/hashmap-performance-improvements-in.html also, which discusses perf in case of high hash collisions and usage of trees rather than lists of buckets in the case. Perhaps related? No idea. IMO the...
This sounds like @vietj is using tuples of size proportional to the number of promises? Surely that's wrong.
The http://www.json.org standard does not seem to bless this. IMO quotes are required. But note that there's a difference between JSON and JS values. JSON is a subset of JS...
Yes that's related: `javax.transaction` (from JDK) and `javax.transaction.api` contain the same packages and classes (except the latter is a superset of the former).
So I think the JS backend does not actually produce JSON, it produces JS code. And it's consistent with not being named `foo-1-model.json` but `foo-1-model.js`. Now, sure we could add...
No, not cool. The opposite of cool in fact.
I have moved the issue to 1.3 because it's a nightmare to fix and may require us to suppose split packages in the compiler.
Well, again, I don't think our model is JSON at all. In particular, it may contain JS expressions, I've no idea, but it would not surprise me. Which means `JSON.parse`...