On Thu, Mar 27, 2014 at 3:28 PM, Mark S. Miller erig...@google.com wrote:
[+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
Hey guys,
I wanted to chime in on the discussion about Error.stack standardization.
For my lil' game engine (http://lycheejs.org) I tried a couple things
out how a custom Debugger (for a binary WebSocket protocol) can be
implemented properly. I need to write an own debugger, because I'm using
I agree the loader provides a new place to inject this information.
On Mar 31, 2014 8:59 AM, John Barton johnjbar...@google.com wrote:
My goal is more modest: to ensure that Loader/System function(s) that
accept strings defining JS allow name parameters.
We should also work out how to include
John did you want to propose an alternative? Maybe:
A name parameter for inline scripts and eval? This might work for
sourceUrl but might be limiting for soureMappingUrl.
On Sun, Mar 30, 2014 at 6:25 PM, John Barton johnjbar...@google.com wrote:
Hi Mark. I implemented the first sourceURL
My goal is more modest: to ensure that Loader/System function(s) that
accept strings defining JS allow name parameters.
We should also work out how to include source-maps. The loader has the
right position to obtain the sourcemap from the server or from transcoders.
If we have API on the loader
sourceUrl works in chrome, with eval at least. Is displayName for function
naming?
On Mar 28, 2014 11:56 AM, Sebastian Zartner sebastianzart...@gmail.com
wrote:
Hi John, supposedly
https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript
Hi Mark. I implemented the first sourceURL support, for Firebug back in
the day. It's a kludge we worked out because there was no alternative. It
forces debuggers seek the ends of buffers even if they are millions of
bytes and even if the the name does not turn out to be the one the dev was
Hi John, supposedly
https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript
and
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/#toc-sourceurl
document the emerging de facto std for providing this name to the existing
API.
Notice that the eval stack trace is not very useful in the common case that
the buffer is more complex than a single line and the eval is called more
than once. For eval, new Function(), document.write(script),
document.appendChild(script), and System.module() successful debugging --
and thus
Hi John, supposedly
https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript
and
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/#toc-sourceurl
document the emerging de facto std for providing this name to the existing
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 concavel...@gmail.com 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
On Thu, Mar 27, 2014 at 9:11 AM, Erik Arvidsson erik.arvids...@gmail.comwrote:
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 concavel...@gmail.com wrote:
Interesting sourcemap usage. But is there any hope for
On Thu, Mar 27, 2014 at 4:31 PM, Mark Miller erig...@gmail.com wrote:
The stack should not be accessible given only the error object. Rather,
there should be a getStack function
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#300
which, given an error
Which existing API do you mean?
What asymmetry?
On Thu, Mar 27, 2014 at 9:38 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Mar 27, 2014 at 4:31 PM, Mark Miller erig...@gmail.com wrote:
The stack should not be accessible given only the error object. Rather,
there should be a
On Thu, Mar 27, 2014 at 9:11 AM, Erik Arvidsson erik.arvids...@gmail.comwrote:
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 concavel...@gmail.com wrote:
Interesting sourcemap usage. But is there any hope for
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 jason.orendo...@gmail.com
wrote:
Not formally, but it's straightforward:
At the time you call eval() or
On 3/27/14 2:36 PM, Mark Miller wrote:
Is the FFEvalLineColPatterns at
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#194
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
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('FAIL')); }
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 c...@p5r.orgwrote:
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
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 try
[+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
On Thu, Mar 27, 2014 at 5:23 PM, Christian Plesner Hansen c...@p5r.org 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
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
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
Just curious: do you have any particular parts of #1 in mind that could
be simplified?
c
On Tue, Mar 25, 2014, at 01:49 PM, Mark S. Miller wrote:
Not only would I hope for all of this in ES7, I would add
5) sourcemaps
6) sourcemap extension to template strings, as in that old email
7)
I was recently modifying some code to be strict mode compliant and it
reminded me that the primary use of the Function caller property and
arguments.caller is to build stack traces. Now the latest Internet
Explorer releases have support for stack traces, as of course do Chrome,
FF, and Safari
Hi John, see also my message at
https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html which
cites some of your work on sourcemaps.
On Tue, Mar 25, 2014 at 11:25 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, Mar 25, 2014 at 1:38 PM, John Lenz concavel...@gmail.com
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. There a few things I would like to see:
1) standardization V8's Error.captureStackTrace API
2) standardization of the stack format
3)
Not only would I hope for all of this in ES7, I would add
5) sourcemaps
6) sourcemap extension to template strings, as in that old email
7) The sourceURL as explained at
https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript
or something
29 matches
Mail list logo
