Re: Re: ES6 iteration over object values
Returning just arrays will be inconsistent with the same name methods that sit on prototypes of Array, Map, etc. Yes, Object.keys(...) poisons the iterators idea, but I think these better to be iterators. Or, if Object.values and Object.entries will start returning simple arrays (which of cours is consistent with Object.keys), then probably the iterator method names are better to rename. (Object.keysIterator(), or something, don't know yet -- verbose, but does what it says) Anyhow, since it's ES7, there's a plenty of time to discuss. Dmitry On Sunday, September 28, 2014, Rick Waldron waldron.r...@gmail.com wrote: On Sun, Sep 28, 2014 at 11:28 AM, Mark Volkmann r.mark.volkm...@gmail.com javascript:_e(%7B%7D,'cvml','r.mark.volkm...@gmail.com'); wrote: What happened to adding the Object.values and Object.entries methods? There was some discussion that led me to believe these would be in ES6. Are they now targeted for ES7? Yes, proposed by me and always for ES7 https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-04/apr-9.md#51-objectentries-objectvalues I will complete the necessary tasks for Stage 1 at next meeting. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Strawman: Function.observe
On 28 September 2014 20:34, Michał Wadas michalwa...@gmail.com wrote: We have Object.observe (asynchronous callback whenever object properties changes), but do we need Function.observe (asynchronous callback whenever function is called)? Cons: - can prevent many optimizations (but Object.observe too) Pros: - allows easy debugging and profiling - allows extending libraries functionalities without modyfing their code (widgets?) What should be eventually received by callback code? Possible options: - arguments (can prevent certain optimizations; critical for debugging and profiling) - caller - callee - function's execution time - thisArg of observed function (critical for observing methods of prototype) Won't happen. This would be a _gigantic_ encapsulation leak, and is bound to cause security issues without end. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sat, Sep 27, 2014 at 10:53 PM, Filip Pizlo fpi...@apple.com wrote: I would also like to see this standardized. Comments inline. On Sep 27, 2014, at 10:15 PM, John Lenz concavel...@gmail.com wrote: I would like to get see stack traces standardized for ES7, to that end, I would like to define a minimal set of behaviors that would need to be defined: * the stack property (a string) * when the stack property is attached (at Error object creation or at throw) * what happens when Error object that has been thrown, is thrown again (nothing) * the stack trace in the face of tail recursion optimizations (skipped?) Is that really necessary? If so, can you say something about the motivation? You can do some tail recursion optimizations while preserving the stack trace. For example if you call yourself recursively and the JIT turns it into a loop, then all you need is the loop trip count to recover the original stack trace. I really have no idea what the behavior should be in the faces of optimized tail calls (which is must broader than simply self recursive methods that can be rewritten as a loop). I've seen various suggestions (a capped call history) but I'm curious how efficient functional languages deal with this. I haven't actually seen anything about tail recursion optimizations being implemented, have any of the VM actually tried or committed to implementing tail call optimizations? * the minimal information that a stack trace should contain (file, line, column) * the format of the minimal information * how additional information is added to the stack trace (named evals, etc) Does this sound like a reasonable minimal set? +1 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Strawman: Function.observe
It sounds like you want a standardized debugger and profiler API, rather than a language feature. Every engine is different enough internally that I don't think it makes sense to have a standardized debugger API. That said, the Mozilla Debugger API is quite impressive. It might make sense to look at standardizing a subset of that. On Mon, Sep 29, 2014 at 2:20 AM, Andreas Rossberg rossb...@google.com wrote: On 28 September 2014 20:34, Michał Wadas michalwa...@gmail.com wrote: We have Object.observe (asynchronous callback whenever object properties changes), but do we need Function.observe (asynchronous callback whenever function is called)? Cons: - can prevent many optimizations (but Object.observe too) Pros: - allows easy debugging and profiling - allows extending libraries functionalities without modyfing their code (widgets?) What should be eventually received by callback code? Possible options: - arguments (can prevent certain optimizations; critical for debugging and profiling) - caller - callee - function's execution time - thisArg of observed function (critical for observing methods of prototype) Won't happen. This would be a _gigantic_ encapsulation leak, and is bound to cause security issues without end. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jasper ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On 28 September 2014 17:01, Marius Gundersen gunder...@gmail.com wrote: The stacktrace should probably be an array of objects with the properties `filename`, `function`, `line` and `column`. Just to be clear, since you said array of objects: 'function' would still have to be string-valued, to avoid security leaks. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 7:55 AM, John Lenz concavel...@gmail.com wrote: On Sat, Sep 27, 2014 at 10:53 PM, Filip Pizlo fpi...@apple.com mailto:fpi...@apple.com wrote: I would also like to see this standardized. Comments inline. On Sep 27, 2014, at 10:15 PM, John Lenz concavel...@gmail.com mailto:concavel...@gmail.com wrote: I would like to get see stack traces standardized for ES7, to that end, I would like to define a minimal set of behaviors that would need to be defined: * the stack property (a string) * when the stack property is attached (at Error object creation or at throw) * what happens when Error object that has been thrown, is thrown again (nothing) * the stack trace in the face of tail recursion optimizations (skipped?) Is that really necessary? If so, can you say something about the motivation? You can do some tail recursion optimizations while preserving the stack trace. For example if you call yourself recursively and the JIT turns it into a loop, then all you need is the loop trip count to recover the original stack trace. I really have no idea what the behavior should be in the faces of optimized tail calls (which is must broader than simply self recursive methods that can be rewritten as a loop). I've seen various suggestions (a capped call history) but I'm curious how efficient functional languages deal with this. The last time I used ML, which was admittedly a long time ago, the two main implementations (MLton and SML/NJ) simply didn’t have stack traces. I haven't actually seen anything about tail recursion optimizations being implemented, have any of the VM actually tried or committed to implementing tail call optimizations? We (JSC) haven’t. And we don’t plan to, because: - We still need to be able to reconstruct the original stack for things like function.caller and function.arguments. We are trying to remove the latter but the former still lives. - Debugging. Our inspector UI promises stack traces for breakpoints and whenever exceptions are thrown. We could make tail call optimizations work only when the inspector is not attached, but this would be weird. Tail call optimizations end up being a kind of semantic guarantee, since if they work you can write loops using tail calls. It would be weird if attaching the inspector suddenly made all of your tail calls turn into stack overflows. It’s actually better if the risk of stack overflow is equal regardless of whether the inspector is attached. - JS is a great language; it actually lets you write an honest loop. You don’t *need* tail calls. -Filip * the minimal information that a stack trace should contain (file, line, column) * the format of the minimal information * how additional information is added to the stack trace (named evals, etc) Does this sound like a reasonable minimal set? +1 ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On 29 September 2014 18:06, Filip Pizlo fpi...@apple.com wrote: - JS is a great language; it actually lets you write an honest loop. You don’t *need* tail calls. Let me repeat what I just wrote in my previous mail: I think not enough people appreciate the (substantial) difference between general TCO and mere tail recursion. ;) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Mon, Sep 29, 2014 at 10:55 AM, John Lenz concavel...@gmail.com wrote: I really have no idea what the behavior should be in the faces of optimized tail calls (which is must broader than simply self recursive methods that can be rewritten as a loop). I've seen various suggestions (a capped call history) but I'm curious how efficient functional languages deal with this. Different functional languages do a variety of things here: - simply show the current stack, without the functions that made tail calls (this is probably the most common) - have a bounded buffer for stack traces - implement tail calls via a trampoline; this has the side-effect that the stack has recent tail calls in it already I'm sure there are other choices here that people have made. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On 29 September 2014 16:55, John Lenz concavel...@gmail.com wrote: On Sat, Sep 27, 2014 at 10:53 PM, Filip Pizlo fpi...@apple.com wrote: On Sep 27, 2014, at 10:15 PM, John Lenz concavel...@gmail.com wrote: I would like to get see stack traces standardized for ES7, to that end, I would like to define a minimal set of behaviors that would need to be defined: * the stack property (a string) * when the stack property is attached (at Error object creation or at throw) * what happens when Error object that has been thrown, is thrown again (nothing) * the stack trace in the face of tail recursion optimizations (skipped?) Is that really necessary? If so, can you say something about the motivation? You can do some tail recursion optimizations while preserving the stack trace. For example if you call yourself recursively and the JIT turns it into a loop, then all you need is the loop trip count to recover the original stack trace. I really have no idea what the behavior should be in the faces of optimized tail calls (which is must broader than simply self recursive methods that can be rewritten as a loop). I've seen various suggestions (a capped call history) but I'm curious how efficient functional languages deal with this. Indeed, I think not enough people appreciate the (substantial) difference between general TCO and tail recursion. If the language was required to be able to construct stack traces then that would effectively kill the benefit of TCO. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Mon, Sep 29, 2014 at 12:06 PM, Filip Pizlo fpi...@apple.com wrote: [...] I haven't actually seen anything about tail recursion optimizations being implemented, have any of the VM actually tried or committed to implementing tail call optimizations? We (JSC) haven’t. And we don’t plan to, because: - We still need to be able to reconstruct the original stack for things like function.caller and function.arguments. We are trying to remove the latter but the former still lives. First, kudos on trying to remove function.arguments. It would be awesome to see this gone, and I greatly appreciate that you/JSC are willing to test the waters. Although we would both like to see function.caller gone as well, we are also both much more skeptical that this is possible. Let's assume that it is not. The conclusion that follows is only that sloppy calls to sloppy functions can't be TCOed away. That is in any case what we've been assuming. That's why, IIRC (haven't checked lately), TCO is only specified for calls from non-sloppy functions. [...] -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Mark S. Miller wrote: That's why, IIRC (haven't checked lately), TCO is only specified for calls from non-sloppy functions. PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from what I know (corrections welcome0. To add to confusion, ES6 drafts say Tail Position Calls (TPC). Is this story reminidng anyone of the origin of the UTC acronym? Anyway, Mark: you recall correctly: see 14.6.1 step 2 under http://people.mozilla.org/~jorendorff/es6-draft.html#sec-tail-position-calls Fil, this is normative draft spec for ES6, observable asymptotic space performance. Not optional at implementor's discretion. :-P /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 10:25 AM, Brendan Eich bren...@mozilla.org wrote: Mark S. Miller wrote: That's why, IIRC (haven't checked lately), TCO is only specified for calls from non-sloppy functions. PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from what I know (corrections welcome0. To add to confusion, ES6 drafts say Tail Position Calls (TPC). Is this story reminidng anyone of the origin of the UTC acronym? Anyway, Mark: you recall correctly: see 14.6.1 step 2 under http://people.mozilla.org/~jorendorff/es6-draft.html#sec-tail-position-calls Fil, this is normative draft spec for ES6, observable asymptotic space performance. Not optional at implementor's discretion. :-P Bummer. -Filip /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 9:23 AM, Mark S. Miller erig...@google.com wrote: On Mon, Sep 29, 2014 at 12:06 PM, Filip Pizlo fpi...@apple.com wrote: [...] I haven't actually seen anything about tail recursion optimizations being implemented, have any of the VM actually tried or committed to implementing tail call optimizations? We (JSC) haven’t. And we don’t plan to, because: - We still need to be able to reconstruct the original stack for things like function.caller and function.arguments. We are trying to remove the latter but the former still lives. First, kudos on trying to remove function.arguments. It would be awesome to see this gone, and I greatly appreciate that you/JSC are willing to test the waters. Although we would both like to see function.caller gone as well, we are also both much more skeptical that this is possible. Let's assume that it is not. The conclusion that follows is only that sloppy calls to sloppy functions can't be TCOed away. That is in any case what we've been assuming. That's why, IIRC (haven't checked lately), TCO is only specified for calls from non-sloppy functions. I agree! Thanks for the explanation. :-) -Filip [...] -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 9:23 AM, Mark S. Miller wrote: Although we would both like to see function.caller gone as well, we are also both much more skeptical that this is possible. Let's assume that it is not. The conclusion that follows is only that sloppy calls to sloppy functions can't be TCOed away. That is in any case what we've been assuming. That's why, IIRC (haven't checked lately), TCO is only specified for calls from non-sloppy functions. Actually, TCO is only specified for calls from strict mode ECMAScript functions. The only place the distinction between strict and non-sloppy is really significant is WRT built-in functions. Standard built-ins are allowed to be implemented either as strict ECMAScript functions or in some implementation defined manner (ie, using some other programming language). If the latter is the case, we don't really have any say over their internal call semantics, etc. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Agreed. TCO or PTC specified only for strict mode functions, not for all non-sloppy functions. Would be nice to extend this at least to bound functions resulting from binding a strict function, but too late to consider for ES6. In any case, all such TCO extensions can compatibly happen later. On Mon, Sep 29, 2014 at 1:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 29, 2014, at 9:23 AM, Mark S. Miller wrote: Although we would both like to see function.caller gone as well, we are also both much more skeptical that this is possible. Let's assume that it is not. The conclusion that follows is only that sloppy calls to sloppy functions can't be TCOed away. That is in any case what we've been assuming. That's why, IIRC (haven't checked lately), TCO is only specified for calls from non-sloppy functions. Actually, TCO is only specified for calls from strict mode ECMAScript functions. The only place the distinction between strict and non-sloppy is really significant is WRT built-in functions. Standard built-ins are allowed to be implemented either as strict ECMAScript functions or in some implementation defined manner (ie, using some other programming language). If the latter is the case, we don't really have any say over their internal call semantics, etc. Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 11:00 AM, Mark S. Miller wrote: Agreed. TCO or PTC specified only for strict mode functions, not for all non-sloppy functions. Would be nice to extend this at least to bound functions resulting from binding a strict function, but too late to consider for ES6. In any case, all such TCO extensions can compatibly happen later. Bound functions don't have bodies, and hence don't directly make ECMAScript function calls. All they do is delegate their [[Call]] behavior to the target function's [[Call]]. No particular reason an implementation can't optimize through that if they want to. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Event loops in navigated-away-from windows
On Sat, 27 Sep 2014, Anne van Kesteren wrote: Well, I for one find it confusing that while HTML had a fairly worked out event loop concept, ECMAScript added another and now I somehow mentally need to integrate them. It would be way clearer if ECMAScript just queued tasks/jobs/microtasks to the Host so we'd keep a single concept of a loop. Allen and I discussed how they should be integrated, and the long and short of it is that there's only one event loop; HTML just interrupts the ES6 loop at NextJob step 4 (the implementation defined manner), and resumes the HTML event loop, and when the HTML event loop needs to resume running code, it resumes the NextJob algorithm. That and a few other hooks ensures that all the jobs end up as tasks and all the ordering semantics are preserved. The discussion was at: http://esdiscuss.org/topic/the-initialization-steps-for-web-browsers I haven't yet done this in HTML because I'm waiting for Allen to make the changes he talked about in that thread; this is being tracked here: https://bugs.ecmascript.org/show_bug.cgi?id=3138 Once that's done I can update HTML. (I don't want to update HTML before, because otherwise I'll have to do it twice.) The HTML bug for this is: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981 I certainly wouldn't object to the ES spec's event loop algorithms being turned inside out (search for RunCode on the esdiscuss thread above for an e-mail where I propose this) but that would be purely an editorial change, it wouldn't change the implementations. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Just wanted to add that CoffeeShop [https://github.com/carlsmith/coffeeshop] already uses stack traces the way JSFiddle and CodePen may do if they were standardised. This only works on V8 as it's the only engine that respects sourceURL 'directives' when listing eval'ed code in stack traces. Providing the trace as an array, instead of a string, would be nice, but nothing special. It's not difficult to parse the string into an array of hashes now. On the other hand, named eval'ed code is absolutely killer. We need named evals now. It's currently impossible to build a JavaScript shell in *any* browser. FF provides line and column numbers for compilation errors, but omits the actual name, so they may as well just not bother ~ it's impossible to build a traceback on Gecko runtime errors. V8 honours the given name, but doesn't do line and column numbers on compilation errors, so you'd better hope your users never make a syntax error. CoffeeShop uses CoffeeScript, who's compiler provides it's own line and column numbers on compilation errors, so it actually does work in Chrome, but the app can't support JS :/ We *need* (1) the name of the file (2) the line number and (3) the column number. The function's name could be useful, but everything else is just go-faster-stripes. Cheers -- carlsmith ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Sorry, this paragraph is a bit confusing... It's currently impossible to build a JavaScript shell in *any* browser. FF provides line and column numbers for compilation errors, but omits the actual name, so they may as well just not bother ~ it's impossible to build a traceback on Gecko runtime errors. V8 honours the given name, but doesn't do line and column numbers on compilation errors, so you'd better hope your users never make a syntax error. I meant to say that on Gecko, you can do compilation errors, but not runtime ones. On Chrome, it's the other way around. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Allen Wirfs-Brock wrote: No particular reason an implementation can't optimize through that if they want to. The question is whether it should be normative. PTC is about observable asymptotic space performance (I keep saying :-P). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Yes, I believe that we should consider some non-strict non-sloppy functions, such as .bind()ings of strict functions, to also normatively have some TCO/PTC requirements. However, it is too late to consider such for ES6 and we can always extend such TCO/PTC requirements to more cases later. On Mon, Sep 29, 2014 at 12:02 PM, Brendan Eich bren...@mozilla.org wrote: Allen Wirfs-Brock wrote: No particular reason an implementation can't optimize through that if they want to. The question is whether it should be normative. PTC is about observable asymptotic space performance (I keep saying :-P). -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On 09/29/2014 09:14 AM, Sam Tobin-Hochstadt wrote: On Mon, Sep 29, 2014 at 10:55 AM, John Lenz concavel...@gmail.com wrote: I really have no idea what the behavior should be in the faces of optimized tail calls (which is must broader than simply self recursive methods that can be rewritten as a loop). I've seen various suggestions (a capped call history) but I'm curious how efficient functional languages deal with this. Different functional languages do a variety of things here: - simply show the current stack, without the functions that made tail calls (this is probably the most common) - have a bounded buffer for stack traces - implement tail calls via a trampoline; this has the side-effect that the stack has recent tail calls in it already I'm sure there are other choices here that people have made. Stack traces are really an overload of (at least?) 3 different concepts: 1. A record of how execution reached the current state. What debuggers want, mostly. 2. The continuation from this point on - what function will be returned to when the current function returns normally, recursively up the call chain. 3. A description of the actual state of the stack. In all of these, the semantics of the youngest frame are different from all other frames in the stack trace. For #2, thrown exceptions make the implied continuation ordering a lie, or at least a little more nuanced. You sort of want to see what frames will catch exceptions. (But that's not a trivial determination if you have some native frames mixed in there, with arbitrary logic for determining whether to catch or propagate an exception. Even JS frames may re-throw.) Inlined functions may cause gaps in #1 and #2, unless the implementation takes pains to fill them in with dummy frames (in which case it's not really #3 anymore.) Unless the implementation plays games, tail calls can make #1 lie as well. You really called f(), but it doesn't appear because its frame was used for executing g() before pushing the remaining frames on your stack. Tail calls don't really muck with #2 afaict. All three meanings are legitimate things to want, and all of them require some implementation effort. Even #3 is tricky with a JIT involved. And I'm not even considering floating generator frames, which may not fit into a linear structure at all. Or when users want long stacks for callbacks, where the stack in effect when a callback was set is relevant. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: No particular reason an implementation can't optimize through that if they want to. The question is whether it should be normative. PTC is about observable asymptotic space performance (I keep saying :-P). /be What should be normative? You guys probably should probably review the actual spec. language and see if you have any issues with it. All the tail call action takes place in the spec. on the caller side. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-evaluatecall and http://people.mozilla.org/~jorendorff/es6-draft.html#sec-preparefortailcall The resources requirements of a function are represented by its execution context. PrepareForTailCall says the the caller's execution context is discarded before invoking the callee's [[call]] internal method. [[Call]] for bound functions does not create a new execution context so there is no associated specified resource consumption that needs to be optimized away. At least as far as the spec. is concerned, bound functions (whether strict or sloppy) have no impact on TCO. I can't imagine what you would want be to try to say about non-EMCAScript functions. Their internal call semantics is determined by the semantics of their implementation language. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
The issue is the asymptotic space consumption almost-contract. The reason I say almost is that conformance of an implementation is not testable. Currently, the spec says nothing about when an implementation might run out of storage. So we (at least I) mean normative only in the following sense: When someone writes an algorithm in ES6 using, say, bound functions in a loop, what claims may they validly make about the space complexity of their program? The specification should help answer such questions, sometimes. Note that I distinguish here between the space complexity of their program and the space usage growth when their program is run on an actual implementation. Again, conformance with any requirement on the latter is not testable. On Mon, Sep 29, 2014 at 1:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: No particular reason an implementation can't optimize through that if they want to. The question is whether it should be normative. PTC is about observable asymptotic space performance (I keep saying :-P). /be What should be normative? You guys probably should probably review the actual spec. language and see if you have any issues with it. All the tail call action takes place in the spec. on the caller side. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-evaluatecall and http://people.mozilla.org/~jorendorff/es6-draft.html#sec-preparefortailcall The resources requirements of a function are represented by its execution context. PrepareForTailCall says the the caller's execution context is discarded before invoking the callee's [[call]] internal method. [[Call]] for bound functions does not create a new execution context so there is no associated specified resource consumption that needs to be optimized away. At least as far as the spec. is concerned, bound functions (whether strict or sloppy) have no impact on TCO. I can't imagine what you would want be to try to say about non-EMCAScript functions. Their internal call semantics is determined by the semantics of their implementation language. Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com wrote:
The issue is the asymptotic space consumption almost-contract. The reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run out
of storage.
So we (at least I) mean normative only in the following sense: When someone
writes an algorithm in ES6 using, say, bound functions in a loop, what
claims may they validly make about the space complexity of their program?
The specification should help answer such questions, sometimes.
Note that I distinguish here between the space complexity of their program
and the space usage growth when their program is run on an actual
implementation. Again, conformance with any requirement on the latter is not
testable.
I think we can make it testable.
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
similarly, this program should never run out of space:
var i = 0;
function f() { i++; return f(); }
f();
If we write a test that checks counting to a specified number, I think
test262 can adequately test this behavior.
Sam
On Mon, Sep 29, 2014 at 1:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that if they
want to.
The question is whether it should be normative. PTC is about observable
asymptotic space performance (I keep saying :-P).
/be
What should be normative? You guys probably should probably review the
actual spec. language and see if you have any issues with it. All the tail
call action takes place in the spec. on the caller side. See
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-evaluatecall
and
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-preparefortailcall
The resources requirements of a function are represented by its execution
context. PrepareForTailCall says the the caller's execution context is
discarded before invoking the callee's [[call]] internal method. [[Call]]
for bound functions does not create a new execution context so there is no
associated specified resource consumption that needs to be optimized away.
At least as far as the spec. is concerned, bound functions (whether strict
or sloppy) have no impact on TCO.
I can't imagine what you would want be to try to say about non-EMCAScript
functions. Their internal call semantics is determined by the semantics of
their implementation language.
Allen
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Toplevel 'let' binding can be left permanently uninitialized after an error
SpiderMonkey hacker Jeff Walden noticed this. Consider a web page that loads and runs this script: throw 0; let x; This leaves the binding 'x' uninitialized. There's no way to get rid of a lexical binding or to initialize it later. The binding is just permanently hosed; any attempt to read or write it will throw. That by itself isn't necessarily a problem. I've never written a web page where I wanted to recover after a toplevel script threw an exception (or timed out). But I dunno, the impossibility of any kind of self-healing here gives me pause. No action required on my account; I'm posting this because we were all surprised and it seems vaguely unaesthetic. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Practically speaking, I agree.
On Mon, Sep 29, 2014 at 1:16 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com
wrote:
The issue is the asymptotic space consumption almost-contract. The
reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run
out
of storage.
So we (at least I) mean normative only in the following sense: When
someone
writes an algorithm in ES6 using, say, bound functions in a loop, what
claims may they validly make about the space complexity of their program?
The specification should help answer such questions, sometimes.
Note that I distinguish here between the space complexity of their
program
and the space usage growth when their program is run on an actual
implementation. Again, conformance with any requirement on the latter is
not
testable.
I think we can make it testable.
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
similarly, this program should never run out of space:
var i = 0;
function f() { i++; return f(); }
f();
If we write a test that checks counting to a specified number, I think
test262 can adequately test this behavior.
Sam
On Mon, Sep 29, 2014 at 1:02 PM, Allen Wirfs-Brock
al...@wirfs-brock.com
wrote:
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that if
they
want to.
The question is whether it should be normative. PTC is about observable
asymptotic space performance (I keep saying :-P).
/be
What should be normative? You guys probably should probably review the
actual spec. language and see if you have any issues with it. All the
tail
call action takes place in the spec. on the caller side. See
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-evaluatecall
and
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-preparefortailcall
The resources requirements of a function are represented by its
execution
context. PrepareForTailCall says the the caller's execution context
is
discarded before invoking the callee's [[call]] internal method.
[[Call]]
for bound functions does not create a new execution context so there
is no
associated specified resource consumption that needs to be optimized
away.
At least as far as the spec. is concerned, bound functions (whether
strict
or sloppy) have no impact on TCO.
I can't imagine what you would want be to try to say about
non-EMCAScript
functions. Their internal call semantics is determined by the
semantics of
their implementation language.
Allen
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Another way to make this (somewhat) testable is to require specific error.stack
behavior for TCO. For example, a call in tail position may require that the
caller does not show up in the stack trace.
-Filip
On Sep 29, 2014, at 1:16 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:
On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
The issue is the asymptotic space consumption almost-contract. The reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run out
of storage.
So we (at least I) mean normative only in the following sense: When someone
writes an algorithm in ES6 using, say, bound functions in a loop, what
claims may they validly make about the space complexity of their program?
The specification should help answer such questions, sometimes.
Note that I distinguish here between the space complexity of their program
and the space usage growth when their program is run on an actual
implementation. Again, conformance with any requirement on the latter is not
testable.
I think we can make it testable.
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
similarly, this program should never run out of space:
var i = 0;
function f() { i++; return f(); }
f();
If we write a test that checks counting to a specified number, I think
test262 can adequately test this behavior.
Sam
On Mon, Sep 29, 2014 at 1:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that if they
want to.
The question is whether it should be normative. PTC is about observable
asymptotic space performance (I keep saying :-P).
/be
What should be normative? You guys probably should probably review the
actual spec. language and see if you have any issues with it. All the tail
call action takes place in the spec. on the caller side. See
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-evaluatecall
and
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-preparefortailcall
The resources requirements of a function are represented by its execution
context. PrepareForTailCall says the the caller's execution context is
discarded before invoking the callee's [[call]] internal method. [[Call]]
for bound functions does not create a new execution context so there is no
associated specified resource consumption that needs to be optimized away.
At least as far as the spec. is concerned, bound functions (whether strict
or sloppy) have no impact on TCO.
I can't imagine what you would want be to try to say about non-EMCAScript
functions. Their internal call semantics is determined by the semantics of
their implementation language.
Allen
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
I think this would be a mistake -- as I mentioned, there are a number
of possible strategies for stack traces w/ proper tail calls, and as
Steve Fink mentioned, these also arise when considering inlining and
other optimizations. We shouldn't prevent implementations from trying
to experiment with what works best here.
Sam
On Mon, Sep 29, 2014 at 4:19 PM, Filip Pizlo fpi...@apple.com wrote:
Another way to make this (somewhat) testable is to require specific
error.stack behavior for TCO. For example, a call in tail position may
require that the caller does not show up in the stack trace.
-Filip
On Sep 29, 2014, at 1:16 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com wrote:
The issue is the asymptotic space consumption almost-contract. The reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run out
of storage.
So we (at least I) mean normative only in the following sense: When someone
writes an algorithm in ES6 using, say, bound functions in a loop, what
claims may they validly make about the space complexity of their program?
The specification should help answer such questions, sometimes.
Note that I distinguish here between the space complexity of their program
and the space usage growth when their program is run on an actual
implementation. Again, conformance with any requirement on the latter is not
testable.
I think we can make it testable.
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
similarly, this program should never run out of space:
var i = 0;
function f() { i++; return f(); }
f();
If we write a test that checks counting to a specified number, I think
test262 can adequately test this behavior.
Sam
On Mon, Sep 29, 2014 at 1:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that if they
want to.
The question is whether it should be normative. PTC is about observable
asymptotic space performance (I keep saying :-P).
/be
What should be normative? You guys probably should probably review the
actual spec. language and see if you have any issues with it. All the tail
call action takes place in the spec. on the caller side. See
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-evaluatecall
and
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-preparefortailcall
The resources requirements of a function are represented by its execution
context. PrepareForTailCall says the the caller's execution context is
discarded before invoking the callee's [[call]] internal method. [[Call]]
for bound functions does not create a new execution context so there is no
associated specified resource consumption that needs to be optimized away.
At least as far as the spec. is concerned, bound functions (whether strict
or sloppy) have no impact on TCO.
I can't imagine what you would want be to try to say about non-EMCAScript
functions. Their internal call semantics is determined by the semantics of
their implementation language.
Allen
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Mon, Sep 29, 2014 at 3:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: I can't imagine what you would want be to try to say about non-EMCAScript functions. Their internal call semantics is determined by the semantics of their implementation language. Function.prototype.apply, Function.prototype.call, and Reflect.apply currently call PrepareForTailCall. Is this a bug? I can see that the current language in 14.6.3 PrepareForTailCall only covers tail position calls and resources associated with the currently executing function execution context, but what's wrong with copying that sentence into 19.2.3.3 and changing it to refer to the internal method call in the last step of the above algorithm and resources associated with the current call to Function.prototype.call? The spec constrains the behavior of builtins in all kinds of ways, regardless of what language they're written in. I don't understand what is special about stack space usage that makes it off-limits. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 1:13 PM, Mark S. Miller wrote: The issue is the asymptotic space consumption almost-contract. The reason I say almost is that conformance of an implementation is not testable. Currently, the spec says nothing about when an implementation might run out of storage. So we (at least I) mean normative only in the following sense: When someone writes an algorithm in ES6 using, say, bound functions in a loop, what claims may they validly make about the space complexity of their program? The specification should help answer such questions, sometimes. Note that I distinguish here between the space complexity of their program and the space usage growth when their program is run on an actual implementation. Again, conformance with any requirement on the latter is not testable. So what would you like it to say that it doesn't already say? Here is what it currently says: 14.6.3 Runtime Semantics: PrepareForTailCall ( ) The abstract operation PrepareForTailCall performs the following steps: 1 Let leafContext be the running execution context. 2 Suspend leafContext. 3 Pop leafContext from the execution context context stack. The execution context now on the top of the stack becomes the running execution context. 4 Assert: leafContext has no further use. It will never be activated as the running execution context. A tail position call must either release any transient internal resources associated with the currently executing function execution context before invoking the target function or reuse those resources in support of the target function. NOTE For example, a tail position call should only grow an implementation’s activation record stack by the amount that the size of the target function’s activation record exceeds the size of the calling function’s activation record. If the target function’s activation record is smaller, then the total size of the stack should decrease. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 12:19 PM, Steve Fink sph...@gmail.com wrote: On 09/29/2014 09:14 AM, Sam Tobin-Hochstadt wrote: On Mon, Sep 29, 2014 at 10:55 AM, John Lenz concavel...@gmail.com wrote: I really have no idea what the behavior should be in the faces of optimized tail calls (which is must broader than simply self recursive methods that can be rewritten as a loop). I've seen various suggestions (a capped call history) but I'm curious how efficient functional languages deal with this. Different functional languages do a variety of things here: - simply show the current stack, without the functions that made tail calls (this is probably the most common) - have a bounded buffer for stack traces - implement tail calls via a trampoline; this has the side-effect that the stack has recent tail calls in it already I'm sure there are other choices here that people have made. Stack traces are really an overload of (at least?) 3 different concepts: 1. A record of how execution reached the current state. What debuggers want, mostly. 2. The continuation from this point on - what function will be returned to when the current function returns normally, recursively up the call chain. 3. A description of the actual state of the stack. In all of these, the semantics of the youngest frame are different from all other frames in the stack trace. For #2, thrown exceptions make the implied continuation ordering a lie, or at least a little more nuanced. You sort of want to see what frames will catch exceptions. (But that's not a trivial determination if you have some native frames mixed in there, with arbitrary logic for determining whether to catch or propagate an exception. Even JS frames may re-throw.) Inlined functions may cause gaps in #1 and #2, unless the implementation takes pains to fill them in with dummy frames (in which case it's not really #3 anymore.) AFAICT, production compilers already take pains to ensure that they leave behind sufficient meta-data for the runtime to fill in the missing stack frames whenever inlining has happened. This is certainly true in JSC. Crucially, the infrastructure to do this is also needed for other random stuff and it imposes zero overhead. So let's not compare this to inlining. -Filip Unless the implementation plays games, tail calls can make #1 lie as well. You really called f(), but it doesn't appear because its frame was used for executing g() before pushing the remaining frames on your stack. Tail calls don't really muck with #2 afaict. All three meanings are legitimate things to want, and all of them require some implementation effort. Even #3 is tricky with a JIT involved. And I'm not even considering floating generator frames, which may not fit into a linear structure at all. Or when users want long stacks for callbacks, where the stack in effect when a callback was set is relevant. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 1:26 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:
I think this would be a mistake -- as I mentioned, there are a number
of possible strategies for stack traces w/ proper tail calls,
But we should spec one of them, particularly if we want to move towards
returning the stack trace as structured data. I think it would be good for
implementations to be consistent and for the stack trace to not vary depending
on which optimization tier you ended up in.
and as
Steve Fink mentioned, these also arise when considering inlining and
other optimizations.
Nope. Inlining and other optimization a don't typically wreak the havoc on
stack traces that TCO does.
We shouldn't prevent implementations from trying
to experiment with what works best here.
Is there something concrete that it would prevent anyone from trying?
Sam
On Mon, Sep 29, 2014 at 4:19 PM, Filip Pizlo fpi...@apple.com wrote:
Another way to make this (somewhat) testable is to require specific
error.stack behavior for TCO. For example, a call in tail position may
require that the caller does not show up in the stack trace.
-Filip
On Sep 29, 2014, at 1:16 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com wrote:
The issue is the asymptotic space consumption almost-contract. The reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run out
of storage.
So we (at least I) mean normative only in the following sense: When someone
writes an algorithm in ES6 using, say, bound functions in a loop, what
claims may they validly make about the space complexity of their program?
The specification should help answer such questions, sometimes.
Note that I distinguish here between the space complexity of their program
and the space usage growth when their program is run on an actual
implementation. Again, conformance with any requirement on the latter is not
testable.
I think we can make it testable.
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
similarly, this program should never run out of space:
var i = 0;
function f() { i++; return f(); }
f();
If we write a test that checks counting to a specified number, I think
test262 can adequately test this behavior.
Sam
On Mon, Sep 29, 2014 at 1:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that if they
want to.
The question is whether it should be normative. PTC is about observable
asymptotic space performance (I keep saying :-P).
/be
What should be normative? You guys probably should probably review the
actual spec. language and see if you have any issues with it. All the tail
call action takes place in the spec. on the caller side. See
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-evaluatecall
and
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-preparefortailcall
The resources requirements of a function are represented by its execution
context. PrepareForTailCall says the the caller's execution context is
discarded before invoking the callee's [[call]] internal method. [[Call]]
for bound functions does not create a new execution context so there is no
associated specified resource consumption that needs to be optimized away.
At least as far as the spec. is concerned, bound functions (whether strict
or sloppy) have no impact on TCO.
I can't imagine what you would want be to try to say about non-EMCAScript
functions. Their internal call semantics is determined by the semantics of
their implementation language.
Allen
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Mon, Sep 29, 2014 at 4:57 PM, Filip Pizlo fpi...@apple.com wrote:
On Sep 29, 2014, at 1:26 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
I think this would be a mistake -- as I mentioned, there are a number
of possible strategies for stack traces w/ proper tail calls,
But we should spec one of them, particularly if we want to move towards
returning the stack trace as structured data. I think it would be good for
implementations to be consistent and for the stack trace to not vary
depending on which optimization tier you ended up in.
and as
Steve Fink mentioned, these also arise when considering inlining and
other optimizations.
Nope. Inlining and other optimization a don't typically wreak the havoc on
stack traces that TCO does.
A lot of time spent staring at C stack frames where calls have been
inlined away disagrees.
We shouldn't prevent implementations from trying
to experiment with what works best here.
Is there something concrete that it would prevent anyone from trying?
If we mandate that we get exactly the same stack frames from every
implementation, which is what you are suggesting, then that would
prevent (some forms of) experimentation. Especially experimentation
that would produce _better_ stack traces than what you suggest
mandating.
Sam
Sam
On Mon, Sep 29, 2014 at 4:19 PM, Filip Pizlo fpi...@apple.com wrote:
Another way to make this (somewhat) testable is to require specific
error.stack behavior for TCO. For example, a call in tail position may
require that the caller does not show up in the stack trace.
-Filip
On Sep 29, 2014, at 1:16 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com wrote:
The issue is the asymptotic space consumption almost-contract. The reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run out
of storage.
So we (at least I) mean normative only in the following sense: When someone
writes an algorithm in ES6 using, say, bound functions in a loop, what
claims may they validly make about the space complexity of their program?
The specification should help answer such questions, sometimes.
Note that I distinguish here between the space complexity of their program
and the space usage growth when their program is run on an actual
implementation. Again, conformance with any requirement on the latter is not
testable.
I think we can make it testable.
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
similarly, this program should never run out of space:
var i = 0;
function f() { i++; return f(); }
f();
If we write a test that checks counting to a specified number, I think
test262 can adequately test this behavior.
Sam
On Mon, Sep 29, 2014 at 1:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that if they
want to.
The question is whether it should be normative. PTC is about observable
asymptotic space performance (I keep saying :-P).
/be
What should be normative? You guys probably should probably review the
actual spec. language and see if you have any issues with it. All the tail
call action takes place in the spec. on the caller side. See
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-evaluatecall
and
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-preparefortailcall
The resources requirements of a function are represented by its execution
context. PrepareForTailCall says the the caller's execution context is
discarded before invoking the callee's [[call]] internal method. [[Call]]
for bound functions does not create a new execution context so there is no
associated specified resource consumption that needs to be optimized away.
At least as far as the spec. is concerned, bound functions (whether strict
or sloppy) have no impact on TCO.
I can't imagine what you would want be to try to say about non-EMCAScript
functions. Their internal call semantics is determined by the semantics of
their implementation language.
Allen
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 1:41 PM, Jason Orendorff wrote: On Mon, Sep 29, 2014 at 3:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: I can't imagine what you would want be to try to say about non-EMCAScript functions. Their internal call semantics is determined by the semantics of their implementation language. Function.prototype.apply, Function.prototype.call, and Reflect.apply currently call PrepareForTailCall. Is this a bug? No, I don't believe so. Built-ins (whether implemented in ES or native) are specified to have an execution context. The PrepareForTailCall release that execution context for before performing a [[Call]]. It's working in the above functions just like it works from any other call site. In other words, the spec. language says that these buil;t-ins functions explicitly end with an ECMAScript tail call. I can see that the current language in 14.6.3 PrepareForTailCall only covers tail position calls and resources associated with the currently executing function execution context, but what's wrong with copying that sentence into 19.2.3.3 and changing it to refer to the internal method call in the last step of the above algorithm and resources associated with the current call to Function.prototype.call? The spec constrains the behavior of builtins in all kinds of ways, regardless of what language they're written in. I don't understand what is special about stack space usage that makes it off-limits. I'm not sure what would be the point of duplicating the language. Since those functions use PrepareForTailCall, what is says applies to them. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Event loops in navigated-away-from windows
On Mon, Sep 29, 2014 at 8:18 PM, Ian Hickson i...@hixie.ch wrote: I certainly wouldn't object to the ES spec's event loop algorithms being turned inside out (search for RunCode on the esdiscuss thread above for an e-mail where I propose this) but that would be purely an editorial change, it wouldn't change the implementations. The proposed setup from Allen will start failing the moment ECMAScript wants something more complicated with its loop. At that point you'll have to propose another set of hacks to make the integration with HTML work again. And given this integration is so weird, I doubt implementations will match it as written. Seems more likely they'll implement the more straightforward alternative. (Also, the proposed setup does seem to require exactly that kind of mental integration I was worried about. With HTML hijacking the ES loop to do its bidding.) -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
On Mon, Sep 29, 2014 at 4:17 PM, Jason Orendorff jason.orendo...@gmail.com wrote: SpiderMonkey hacker Jeff Walden noticed this. Consider a web page that loads and runs this script: throw 0; let x; This leaves the binding 'x' uninitialized. There's no way to get rid of a lexical binding or to initialize it later. The binding is just permanently hosed; any attempt to read or write it will throw. Can you clarify write? Does this mean assignment? Why would assignment throw? Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
TDZ On Sep 29, 2014, at 2:14 PM, Rick Waldron wrote: On Mon, Sep 29, 2014 at 4:17 PM, Jason Orendorff jason.orendo...@gmail.com wrote: SpiderMonkey hacker Jeff Walden noticed this. Consider a web page that loads and runs this script: throw 0; let x; This leaves the binding 'x' uninitialized. There's no way to get rid of a lexical binding or to initialize it later. The binding is just permanently hosed; any attempt to read or write it will throw. Can you clarify write? Does this mean assignment? Why would assignment throw? Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Event loops in navigated-away-from windows
On Mon, 29 Sep 2014, Anne van Kesteren wrote: On Mon, Sep 29, 2014 at 8:18 PM, Ian Hickson i...@hixie.ch wrote: I certainly wouldn't object to the ES spec's event loop algorithms being turned inside out (search for RunCode on the esdiscuss thread above for an e-mail where I propose this) but that would be purely an editorial change, it wouldn't change the implementations. The proposed setup from Allen will start failing the moment ECMAScript wants something more complicated with its loop. At that point you'll have to propose another set of hacks to make the integration with HTML work again. And given this integration is so weird, I doubt implementations will match it as written. Seems more likely they'll implement the more straightforward alternative. (Also, the proposed setup does seem to require exactly that kind of mental integration I was worried about. With HTML hijacking the ES loop to do its bidding.) Certainly editorially I would much rather have the inside out version of the spec hooks that I mentioned in my earlier e-mail, yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 2:05 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:
On Mon, Sep 29, 2014 at 4:57 PM, Filip Pizlo fpi...@apple.com
mailto:fpi...@apple.com wrote:
On Sep 29, 2014, at 1:26 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
I think this would be a mistake -- as I mentioned, there are a number
of possible strategies for stack traces w/ proper tail calls,
But we should spec one of them, particularly if we want to move towards
returning the stack trace as structured data. I think it would be good for
implementations to be consistent and for the stack trace to not vary
depending on which optimization tier you ended up in.
and as
Steve Fink mentioned, these also arise when considering inlining and
other optimizations.
Nope. Inlining and other optimization a don't typically wreak the havoc on
stack traces that TCO does.
A lot of time spent staring at C stack frames where calls have been
inlined away disagrees.
Ugh, that’s so irrelevant! ;-)
C compilers internally know what they inlined and where, but have trouble
communicating this information to the debugger because the de facto standard
debug data formats are old and messy. I have vague memories of DWARF making
this particularly hard. Personally I’ve seen a stigma in the C compiler
community against having compilers produce high-fidelity debug data at any
optimization level other than -O0, so I suspect that the reason why this hasn’t
been fixed is just that nobody really wants to do it. For example the top
priority in LLVM’s debug support, last I checked, was to make it as compact as
possible because of the dangers of space explosion in the case of C++,
templates, and LTO. Seriously, the reasons for why C gets this wrong are
completely irrelevant to this discussion. So this is a red herring. An ES VM
can internally choose whatever format it wants for remembering inlining
metadata, it never has to worry about interoperating with zillions of versions
of gdb and lldb, and thankfully ES hasn’t own-goaled itself with anything like
C++ templates (yet? ;-)).
Let’s look at some examples of runtimes that are more relevant to ES. Java VMs
have for over a decade now performed aggressive inlining without ever
forgetting about any frames (in fact they are almost spec-required to remember
all frames because of how the runtime APIs work). The closest thing to
“forgetting” a frame was in the old IBM JVM (the one before J9); all they would
forget was the line numbers in functions that were inlined but the fact that
they inlined them was still remembered.
I’m not aware of a major JS implementation forgetting an inlined stack frame.
We shouldn't prevent implementations from trying
to experiment with what works best here.
Is there something concrete that it would prevent anyone from trying?
If we mandate that we get exactly the same stack frames from every
implementation, which is what you are suggesting, then that would
prevent (some forms of) experimentation. Especially experimentation
that would produce _better_ stack traces than what you suggest
mandating.
Such is life when you spec a language. You have to sometimes spec something in
a way that might in the future disagree with someone’s experiment.
-Filip
Sam
Sam
On Mon, Sep 29, 2014 at 4:19 PM, Filip Pizlo fpi...@apple.com wrote:
Another way to make this (somewhat) testable is to require specific
error.stack behavior for TCO. For example, a call in tail position may
require that the caller does not show up in the stack trace.
-Filip
On Sep 29, 2014, at 1:16 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com wrote:
The issue is the asymptotic space consumption almost-contract. The reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run out
of storage.
So we (at least I) mean normative only in the following sense: When someone
writes an algorithm in ES6 using, say, bound functions in a loop, what
claims may they validly make about the space complexity of their program?
The specification should help answer such questions, sometimes.
Note that I distinguish here between the space complexity of their
program
and the space usage growth when their program is run on an actual
implementation. Again, conformance with any requirement on the latter is
not
testable.
I think we can make it testable.
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
similarly, this program should never run out of space:
var i = 0;
function f() { i++; return f(); }
f();
If we write a test that checks counting to a specified number, I think
test262 can adequately test this behavior.
Sam
On Mon, Sep 29, 2014 at 1:02
Re: Maximally minimal stack trace standardization
The issues with sourceUrl and syntax errors is fixed in the latest Chrome dev channel and should be making its way to us in the near future. :-) On Mon, Sep 29, 2014 at 11:49 AM, Carl Smith carl.in...@gmail.com wrote: Just wanted to add that CoffeeShop [ https://github.com/carlsmith/coffeeshop] already uses stack traces the way JSFiddle and CodePen may do if they were standardised. This only works on V8 as it's the only engine that respects sourceURL 'directives' when listing eval'ed code in stack traces. Providing the trace as an array, instead of a string, would be nice, but nothing special. It's not difficult to parse the string into an array of hashes now. On the other hand, named eval'ed code is absolutely killer. We need named evals now. It's currently impossible to build a JavaScript shell in *any* browser. FF provides line and column numbers for compilation errors, but omits the actual name, so they may as well just not bother ~ it's impossible to build a traceback on Gecko runtime errors. V8 honours the given name, but doesn't do line and column numbers on compilation errors, so you'd better hope your users never make a syntax error. CoffeeShop uses CoffeeScript, who's compiler provides it's own line and column numbers on compilation errors, so it actually does work in Chrome, but the app can't support JS :/ We *need* (1) the name of the file (2) the line number and (3) the column number. The function's name could be useful, but everything else is just go-faster-stripes. Cheers -- carlsmith ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Mon, Sep 29, 2014 at 12:19 PM, Steve Fink sph...@gmail.com wrote: On 09/29/2014 09:14 AM, Sam Tobin-Hochstadt wrote: On Mon, Sep 29, 2014 at 10:55 AM, John Lenz concavel...@gmail.com wrote: I really have no idea what the behavior should be in the faces of optimized tail calls (which is must broader than simply self recursive methods that can be rewritten as a loop). I've seen various suggestions (a capped call history) but I'm curious how efficient functional languages deal with this. Different functional languages do a variety of things here: - simply show the current stack, without the functions that made tail calls (this is probably the most common) - have a bounded buffer for stack traces - implement tail calls via a trampoline; this has the side-effect that the stack has recent tail calls in it already I'm sure there are other choices here that people have made. Stack traces are really an overload of (at least?) 3 different concepts: 1. A record of how execution reached the current state. What debuggers want, mostly. This is also important for server side reporting of client side error, which while similar, is not the same as an optionally debugger activated. 2. The continuation from this point on - what function will be returned to when the current function returns normally, recursively up the call chain. 3. A description of the actual state of the stack. In all of these, the semantics of the youngest frame are different from all other frames in the stack trace. For #2, thrown exceptions make the implied continuation ordering a lie, or at least a little more nuanced. You sort of want to see what frames will catch exceptions. (But that's not a trivial determination if you have some native frames mixed in there, with arbitrary logic for determining whether to catch or propagate an exception. Even JS frames may re-throw.) Inlined functions may cause gaps in #1 and #2, unless the implementation takes pains to fill them in with dummy frames (in which case it's not really #3 anymore.) Unless the implementation plays games, tail calls can make #1 lie as well. You really called f(), but it doesn't appear because its frame was used for executing g() before pushing the remaining frames on your stack. Tail calls don't really muck with #2 afaict. All three meanings are legitimate things to want, and all of them require some implementation effort. Even #3 is tricky with a JIT involved. And I'm not even considering floating generator frames, which may not fit into a linear structure at all. Or when users want long stacks for callbacks, where the stack in effect when a callback was set is relevant. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
What does TC39 expect with regard to PTC and the standard-because-everyone-has-one stack property? Has any of the VMs actually tried to implement PTC for JS? On Mon, Sep 29, 2014 at 12:02 PM, Brendan Eich bren...@mozilla.org wrote: Allen Wirfs-Brock wrote: No particular reason an implementation can't optimize through that if they want to. The question is whether it should be normative. PTC is about observable asymptotic space performance (I keep saying :-P). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Mon, Sep 29, 2014 at 4:06 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 29, 2014, at 1:41 PM, Jason Orendorff wrote: Function.prototype.apply, Function.prototype.call, and Reflect.apply currently call PrepareForTailCall. Is this a bug? No, I don't believe so. Built-ins (whether implemented in ES or native) are specified to have an execution context. Oh, I see! Thanks. (This is specified in 9.3.1 [[Call]], for anyone following along.) But in this case, the spec already has some non-ECMAScript functions performing tail calls, so now I am at a loss as to what your earlier line to Brendan could mean: I can't imagine what you would want be to try to say about non-EMCAScript functions. Their internal call semantics is determined by the semantics of their implementation language. It seems like to the full extent that the current draft manages to constrain Function.prototype.call, it could constrain bound functions too. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On 29 September 2014 23:04, John Lenz concavel...@gmail.com wrote: The issues with sourceUrl and syntax errors is fixed in the latest Chrome dev channel and should be making its way to us in the near future. :-) Awesome. I can add JavaScript support to the shell :) I still think the omission of some method for naming eval'ed code in the ES6 spec is unacceptable. It's not a nice-to-have that can be bundled with nicer stack objects, which are relatively unimportant [easily fixed with a regex]. Cheers John -- carlsmith ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Sep 29, 2014, at 3:37 PM, Jason Orendorff wrote: On Mon, Sep 29, 2014 at 4:06 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 29, 2014, at 1:41 PM, Jason Orendorff wrote: Function.prototype.apply, Function.prototype.call, and Reflect.apply currently call PrepareForTailCall. Is this a bug? No, I don't believe so. Built-ins (whether implemented in ES or native) are specified to have an execution context. Oh, I see! Thanks. (This is specified in 9.3.1 [[Call]], for anyone following along.) But in this case, the spec already has some non-ECMAScript functions performing tail calls, so now I am at a loss as to what your earlier line to Brendan could mean: I guess we need to be a bit more careful about what kind of call we are talking about. The ECMAScript spec. execution model uses a stack of execution contexts to tracks [[Call]]'s to and returns from function objects. [[Call]]'s to built-in functions are specified as creating an execution context so that, from a spec. perspective, both self-hosted and native implementations of built-ins can be treated uniformly within the spec. The ES tail call resource rules are expressed in terms of manipulating the execution context stack, immediately prior to performing a [[Call]]. Or to put it another way, ES tail calls rules are only about [[Call]] operations. So, ES tail calls can occur in a built-in's that invoke [[Call]]. Generally this is possible if the built-in is specified to immediately return the [[Call]] result. When I said we couldn't specify tail call behavior for non-ECMAScript functions, I think about the actual call semantics used by the implementation language. For example, if F.p.apply is implemented in C++ and if the last thing it does is a C++ call to another C++ function that is the [[Call]] implementation. I can't say anything about how C++ implements that C++ call. However, from the ES perspective all the C++ execution state that is using to represent such an implementation of F.p.apply is just part of the ES execution context for the [[Call]] to F.p.apply. The C++ code could call thousands of levels deep before it performs its [[Call]] back to an ES function and from the ES perspective all of that C++ stack space is just part of the single F.p.apply execution context. When we perform PrepareForTailCall in F.p.apply we are saying that the current ES execution context (the one that potentially includes that deep C++ call stack) must be discard (or mae available for reuse) before performing the the subsequent ES [[Call]]. How that is actually accomplished is an implementation detail. I strongly support full employment opportunities for language implementations hacker. I can't imagine what you would want be to try to say about non-EMCAScript functions. Their internal call semantics is determined by the semantics of their implementation language. It seems like to the full extent that the current draft manages to constrain Function.prototype.call, it could constrain bound functions too. It does. The spec doesn't introduce an additional execution context between the [[Call]] of a bound function and the [[Call]] to the bound functions target. If the [[Call]] to the bound function is in tail position then the caller's execution context is discarded before the [[Call]] to the bound function. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Allen Wirfs-Brock wrote: On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: No particular reason an implementation can't optimize through that if they want to. The question is whether it should be normative. PTC is about observable asymptotic space performance (I keep saying :-P). /be What should be normative? Something observable. I was picking on your optimize. Looks like Jason and others covered the rest of what I was gonna write here, except: You guys probably should probably review the actual spec. language and see if you have any issues with it. I've read it, earlier today. You're hearing issues now. :-D /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Carl Smith wrote: I still think the omission of some method for naming eval'ed code in the ES6 spec is unacceptable. It's not a nice-to-have that can be bundled with nicer stack objects, which are relatively unimportant [easily fixed with a regex]. See http://esdiscuss.org/topic/dynamic-compilation-including-eval-and-script-tag-insertion-was-re-clean-scope and possibly other old threads. JJB and I discussed, I forgot whether he implemented. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On 30 September 2014 00:33, Brendan Eich bren...@mozilla.org wrote: Carl Smith wrote: I still think the omission of some method for naming eval'ed code in the ES6 spec is unacceptable. It's not a nice-to-have that can be bundled with nicer stack objects, which are relatively unimportant [easily fixed with a regex]. See http://esdiscuss.org/topic/dynamic-compilation-including- eval-and-script-tag-insertion-was-re-clean-scope and possibly other old threads. JJB and I discussed, I forgot whether he implemented. Thanks Brendan [and for JavaScript]. That discussion, though interesting, seems to deal more with the implementation details, which went over my head a bit to be honest. Chrome currently supports named evals by concatenating `\n//# sourceURL=filename` to the string before passing it to `eval`. There's a longstanding ticket on FF for the pretty much the same thing [ https://bugzilla.mozilla.org/show_bug.cgi?id=583083]. The script tag workaround feels nasty in a shell, with lots of small inputs, and doesn't work for me ~ we use CoffeeScript. If the source URL hack, or some cleaner wrapper for it, was standardised, it'd make all the difference. Thanks again -- carlsmith ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Carl Smith wrote: If the source URL hack, or some cleaner wrapper for it, was standardised, it'd make all the difference. Why don't we just make the source URL hack a de-facto standard? That's how evolution happens, in the best case. Cc'ing @fitzgen. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On 9/29/14, 4:16 PM, Sam Tobin-Hochstadt wrote:
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
How would you know whether it does? You can't tell whether your program
is terminated because it runs out of space or because the browser has
decided it's hung and killed it
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
It is a defacto standard. On Sep 29, 2014 6:36 PM, Brendan Eich bren...@mozilla.org wrote: Carl Smith wrote: If the source URL hack, or some cleaner wrapper for it, was standardised, it'd make all the difference. Why don't we just make the source URL hack a de-facto standard? That's how evolution happens, in the best case. Cc'ing @fitzgen. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Put it in a worker or node.js. The point Sam was making was based on Ecma-262,
no browser watchdog required.
/be
On Sep 29, 2014, at 6:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/29/14, 4:16 PM, Sam Tobin-Hochstadt wrote:
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
How would you know whether it does? You can't tell whether your program is
terminated because it runs out of space or because the browser has decided
it's hung and killed it
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
