On Mon, Mar 9, 2015 at 12:15 PM, Mark S. Miller <[email protected]> wrote:
> On Sat, Mar 7, 2015 at 2:55 PM, John Lenz <[email protected]> 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. > The threads I dug up, simply state what you state here. That there is an "information leak". Are filename and function names considered sensitive? In what way? I did not intend to promote a "rich stack inspection API" such as V8 has. > 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 <[email protected]> >> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> >>>>> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
