Maximally minimal stack trace standardization

Mark S. Miller erights at google.com
Mon Mar 9 19:15:50 UTC 2015


On Sat, Mar 7, 2015 at 2:55 PM, John Lenz <concavelenz at gmail.com> wrote:

> I wanted to ping this thread and see how we could get "max-min stack
> traces" to the next step?
>

Hi John, the best way to take this to the next step is to read <
https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU/edit>
and submit a proposal to <https://github.com/tc39/ecma262>.

"If you are a TC39 member representative, just submit a pull request for
your proposal."

Since you are at a member organization, attend and participate actively at
TC39 meetings to advance your proposal through the process.

Please keep in mind that the stack trace information should not be
available simply from the error object by itself, as that is a bad
information leak. See the previous es-discuss discussions of the need for
something like the getStack function of <
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#300>
for rights amplification.

Other proposals-to-be that need to traffic in source positions are
* source maps
* passing source position through an eval
* causality tracking for multi-turn computation; at least deep stacks
* adding source positions/maps to the template objects of template strings.

Of course, these should be as decoupled as possible. But it's good to keep
your eye on the whole picture when you start standards work that depend on
source positions.



> On Fri, Oct 10, 2014 at 11:47 AM, Frankie Bagnardi <f.bagnardi at gmail.com>
> wrote:
>
>> I think this is a great idea.  I often use stack traces, especially in
>> node.js, for debug error messages and logging.  This would make it much
>> simpler to work with them.
>>
>> Also there are some libraries which end up with a lot of wrapped
>> functions, which could be omitted using an error cleaner function.
>>
>> I suggest a stackTrace property (getter, no write) of Error objects:
>>
>>  - .frames is an array of stack frame metadata objects
>>  - no concept of sourcemaps
>>  - [[ToString]] is left implementation dependant, allowing them to add
>> information from sourcemaps, or otherwise customize it
>>
>> This allows for a programmable api, and a human readable version.  Also
>> devtools and other code applications (like Carl Smith's) can create rich
>> UIs for this data.
>>
>> I'm sure the smart people at TC39 can come up with a good (or good
>> enough) way to represent PTCs.
>>
>>
>>
>> On Sat, Oct 4, 2014 at 9:31 AM, John Lenz <concavelenz at gmail.com> wrote:
>>
>>> Is ES6 "shipping" PTCs without implementer feedback? Or how have those
>>> that tried dealt with stack traces?
>>> On Sep 29, 2014 3:20 PM, "John Lenz" <concavelenz at gmail.com> wrote:
>>>
>>>> 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 <brendan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150309/9ed9b91c/attachment.html>


More information about the es-discuss mailing list