Re: standardizing Error.stack or equivalent

On 3/27/14 12:31 PM, Mark Miller wrote: Mozillians, why did you add this extra information? Looks like it was added in https://bugzilla.mozilla.org/show_bug.cgi?id=332176 Before that, the stack claimed the url of the caller of eval() but a line number which was the sum of the line number of

Re: standardizing Error.stack or equivalent

On 3/27/14 12:31 PM, Mark Miller wrote: Mozillians, why did you add this extra information? Looks like it was added in https://bugzilla.mozilla.org/show_bug.cgi?id=332176 Before that, the stack claimed the url of the caller of eval() but a line number which was the sum of the line number of

Re: standardizing Error.stack or equivalent

On Thu, Mar 27, 2014 at 5:23 PM, Christian Plesner Hansen wrote: >> js> try { eval("eval('FAIL')"); } catch (x) { print(x.stack); } >> @typein line 2 > eval line 1 > eval:1:1 >> @typein line 2 > eval:1:1 >> @typein:2:7 > > I'm unclear on what the problem is with nested evals -- you

Re: standardizing Error.stack or equivalent

[+google-caja-discuss] Cool. I will fix the debug.js adaptor a) to fix the bug Boris reported, b) to map the FF nested format to the v8 nested format, and c) to preserve this information from the v8 API so that it appears correctly on v8 as well. This will require extending the Causeway stack trac

Re: standardizing Error.stack or equivalent

Yes: [1]https://code.google.com/p/v8/wiki/JavaScriptStackTraceApi c On Thu, Mar 27, 2014, at 03:06 PM, Mark Miller wrote: I wasn't aware that v8 does that. Is this format documented anywhere? On Thu, Mar 27, 2014 at 2:23 PM, Christian Plesner Hansen <[2]c...@p5r.org> wrote: > js> t

Re: standardizing Error.stack or equivalent

I wasn't aware that v8 does that. Is this format documented anywhere? On Thu, Mar 27, 2014 at 2:23 PM, Christian Plesner Hansen wrote: > > js> try { eval("eval('FAIL')"); } catch (x) { print(x.stack); } > > @typein line 2 > eval line 1 > eval:1:1 > > @typein line 2 > eval:1:1 > >

Re: Reserving `await` within modules?

> > > Could we reserve `await` inside the module grammar, so as to make it > possible for future modules to await promises at top-level, without an > IIAAFE? This would likely mean even web environments, with their very > stringent backward-compatibility constraints, would be able to use this > top

Re: standardizing Error.stack or equivalent

> js> try { eval("eval('FAIL')"); } catch (x) { print(x.stack); } > @typein line 2 > eval line 1 > eval:1:1 > @typein line 2 > eval:1:1 > @typein:2:7 I'm unclear on what the problem is with nested evals -- you get essentially the same information from v8: js> try { eval("eval('FAI

Reserving `await` within modules?

I could swear someone brought this up before, but all I found was a thread about reserving `await` within arrow functions... One of my great hopes for the ES7 `await`/`async` proposal would be that you could provide a top-level grammar wherein `await` was usable, without being inside of an `asy

Re: standardizing Error.stack or equivalent

On 3/27/14 2:36 PM, Mark Miller wrote: Is the FFEvalLineColPatterns at correct? No. It's missing the Function case and doesn't do what I think you want it to be doing in the nested eval/Function c

Re: standardizing Error.stack or equivalent

Is the FFEvalLineColPatterns at < https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#194> correct? On Thu, Mar 27, 2014 at 11:29 AM, Jason Orendorff wrote: > Not formally, but it's straightforward: > > At the time you call eval() or Function(), we capture

Re: standardizing Error.stack or equivalent

Not formally, but it's straightforward: At the time you call eval() or Function(), we capture the string fileName + " line " + lineNumber + " > eval" or "> Function" if you're calling Function. We use that string as the fileName for the dynamic eval or Function code. This affects both err.file

Re: standardizing Error.stack or equivalent

Is this extended format documented anywhere? On Thu, Mar 27, 2014 at 10:36 AM, Jason Orendorff wrote: > On Thu, Mar 27, 2014 at 12:31 PM, Mark Miller wrote: > > Mozillians, why did you add this extra information? > > Well... if the point of Error.stack is to provide diagnostic > information fo

Re: standardizing Error.stack or equivalent

On Thu, Mar 27, 2014 at 12:31 PM, Mark Miller wrote: > Mozillians, why did you add this extra information? Well... if the point of Error.stack is to provide diagnostic information for exceptions, for the purpose of debugging, this information is critical. Without this, eval() or Function() often

Re: [[Set]] and inherited readonly data properties

I know it won't get updated any time soon but unfortunately, and specially in some emerging market, [these kind of phones]( http://www.amazon.com/LG-Navigation-OPTIMUS-ME-BLK/dp/B005HEEBQI/ref=sr_1_62?s=electronics&ie=UTF8&qid=1395940823&sr=1-62&keywords=android+phone) are still quite common ... yo

Re: standardizing Error.stack or equivalent

On Thu, Mar 27, 2014 at 9:11 AM, Erik Arvidsson wrote: > To be clear. Changing .stack is not an option. We need to introduce a new > API. > > On Tue Mar 25 2014 at 4:40:20 PM, John Lenz wrote: > >> Interesting sourcemap usage. But is there any hope for standardization >> of the existing stack ha

Re: standardizing Error.stack or equivalent

Which existing API do you mean? What asymmetry? On Thu, Mar 27, 2014 at 9:38 AM, Anne van Kesteren wrote: > On Thu, Mar 27, 2014 at 4:31 PM, Mark Miller wrote: > > The stack should not be accessible given only the error object. Rather, > > there should be a getStack function > > < > https://

Re: standardizing Error.stack or equivalent

On Thu, Mar 27, 2014 at 4:31 PM, Mark Miller wrote: > The stack should not be accessible given only the error object. Rather, > there should be a getStack function > > which, given an error object, ret

Re: standardizing Error.stack or equivalent

On Thu, Mar 27, 2014 at 9:11 AM, Erik Arvidsson wrote: > To be clear. Changing .stack is not an option. We need to introduce a new > API. > > On Tue Mar 25 2014 at 4:40:20 PM, John Lenz wrote: > >> Interesting sourcemap usage. But is there any hope for standardization >> of the existing stack ha

Re: standardizing Error.stack or equivalent

To be clear. Changing .stack is not an option. We need to introduce a new API. On Tue Mar 25 2014 at 4:40:20 PM, John Lenz wrote: > Interesting sourcemap usage. But is there any hope for standardization of > the existing stack handling for ES7? It wasn't clear to me why it stalled > for ES6. T