On Tue, Jan 19, 2016 at 6:35 PM, Jonathan Kingston <[email protected]>
wrote:
> Hi Mark,
>
> Sorry for the delay, thank you for that response it was very useful.
>
> Do you think it would make sense to open an API for Error stack that would
> be purely based upon user agent implementation? I'm not familiar with the
> internals of the traces but I have seen comments mentioning performance
> issues of complete parity across browsers due to their implementation
> differences.
>
> It would however still be useful to standardise: lineNumber, columnNumber
> and fileName.
>
> Perhaps that would be a simpler first step?
>
I think I was too discouraging in my earlier email. I actually meant to be
encouraging, though as always including weaknesses, cautions, requirements,
and caveats. I did not mean to scare anyone off. The downside of starting
with too small a part of the problem in isolation is that we are likely to
paint ourselves into a corner that we cannot fix later. I think the useful
thing to do is to standardize the extended Causeway stack trace format:
stacktrace ::= {calls: [frame*]};
frame ::= {name: functionName,
source: source,
span: [[startLine, startCol?], [endLine, endCol?]?]};
functionName ::= STRING;
startLine, startCol, endLine, endCol ::= INTEGER
source ::= STRING | frame;
that I showed in the previous message, as well as the APIs derived from <
https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js
>:
System.getStack(error) -> extended-causeway-stack | undefined
Reflect.stackString(extended-causeway-stack) -> stacktrace-string
System.getStackString = error =>
Reflect.stackString(System.getStack(error));
This places the privilege-bearing operations on System, as do other
proposals such as
System.global
System.defaultLoader
System.WeakRef
The only operation above that's fundamental is System.getStack, which,
given an error object encapsulating stack trace info, returns that stack
trace info in extended Causeway stacktrace format. debug.js shows how to
polyfill a decent approximation of this by scraping this info from the
divergent stack traces provided by today's major platforms.
Reflect.stackString renders an extended Causeway stack into a multiline
string, one per stackframe. It is fully non-privileged and polyfillable,
but I propose that the std provide it, in order to harmonize the current
crazy divergence of these formats between platforms. The one provided by
debug.js uses a vaguely v8-like concrete syntax, but that is merely a
starting point of discussion. Anything we can all agree on, that reliably
represents all the information from the extended Causeway stacktrace info,
would be great. We put stackString on Reflect because by itself it provides
no privilege.
System.getStackString is a mere convenience, composing together stackString
with getStack. I expect that most callers will just call this and ignore
the two lower level ones.
The hard part will be the escaping conventions needed in stackString, as
this goes beyond any precedent set by current platforms. The scraping that
the polyfill in debug.js does is grossly unreliable because it relies on
characters such as "(" and "@" to recognize what part of the existing
stackframe strings are filenames and function-or-method names. However,
these characters can be present in filenames, function names, and method
names, in which case this scraping will fail. Neither the current scraping
nor rendering code in debug.js does anything yet about this need to escape
significant characters.
Fortunately, once a reliable getStack is provided directly (instead of a
polyfill scraping non-escaped strings), consumers of the extended Causeway
format it returns will have reliable access to this structured data,
without any more need to do their own scraping.
The other hard but necessary part is that any such standard should be
coordinated -- ideally co-proposed -- with a proposed standard sourcemap <
https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?hl=en_US&pli=1&pli=1>,
which also needs to codify the meaning of at least filename and start/end
line/col.
A transpiler translating esN+1 to esN, producing an esN to esN+1 sourcemap,
should also provide to the esN+1 code a virtualized System.getStack and
System.getStackString that maps back through that sourcemap, so that the
esN+1 code sees stack trace info in terms of positions in its own esN+1
sources.
What all of this needs is someone who will take the lead writing a
proposal. It is important, but I do not have the time. If someone does
volunteer to take the lead, I will happily help, advise, ensure that all
requirements are met, and to champion this proposal on the committee.
Volunteers? Jonathan?
> Thanks
> Jonathan
>
> On Tue, Jan 12, 2016 at 6:32 AM Mark S. Miller <[email protected]> wrote:
>
>> On Mon, Jan 11, 2016 at 10:05 PM, Mark S. Miller <[email protected]>
>> wrote:
>>
>>> I am very interested. See the extended Causeway stack format in
>>> https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js
>>>
>>
>> From that page, the JSON Schema-ish in an ad-hoc notation:
>>
>>
>> stacktrace ::= {calls: [frame*]};
>> frame ::= {name: functionName,
>> source: source,
>> span: [[startLine, startCol?], [endLine, endCol?]?]};
>> functionName ::= STRING;
>> startLine, startCol, endLine, endCol ::= INTEGER
>> source ::= STRING | frame;
>>
>>
>>
>>
>> and the logic for scraping this information from the various stacktraces
>>> available on today's major platforms.
>>>
>>> The "extended" is about the multiple source position layers present when
>>> an "eval" in one place evals a string that, at some position in the string,
>>> does the call. Both FF and Chrome provide these nested positions, but
>>> differently.
>>>
>>
>>
>> The nesting is represented as the recursion through "frame" in the above
>> grammar.
>>
>>
>>
>>>
>>> See the attachments for the information successfully scraped when
>>> visiting <
>>> https://rawgit.com/tvcutsem/es-lab/master/src/ses/contract.html> on
>>> each of the platforms, converted to Causeway extended stack trace format,
>>> and then re-rendered in a common textual format. As you see, even with all
>>> the work at canonicalizing this information, it still differs substantially
>>> between platforms.
>>>
>>>
>>>
>>>
>>> On Mon, Jan 11, 2016 at 7:10 PM, Jonathan Kingston <
>>> [email protected]> wrote:
>>>
>>>> Hey all,
>>>>
>>>> Does anyone know if there is an active interest in revisiting the
>>>> Error.stack strawman proposal?
>>>>
>>>> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>>>>
>>>> I ask because CSP wanted an algorithm for getting the non standard
>>>> properties defined in Error objects:
>>>> https://w3c.github.io/webappsec-csp/#issue-f447ede5
>>>>
>>>> A simpler start may be possible in standardising just: lineNumber,
>>>> columnNumber and fileName
>>>>
>>>> Kind regards
>>>> Jonathan
>>>>
>>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
