<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 7, 2015 at 2:55 PM, John Lenz <span dir="ltr"><<a href="mailto:concavelenz@gmail.com" target="_blank">concavelenz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I wanted to ping this thread and see how we could get "max-min stack traces" to the next step?</div></blockquote><div><br></div><div>Hi John, the best way to take this to the next step is to read <<a href="https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU/edit" target="_blank">https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU/edit</a>> and submit a proposal to <<a href="https://github.com/tc39/ecma262" target="_blank">https://github.com/tc39/ecma262</a>>.</div><div><br></div><div>"<span style="color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif;font-size:16px;line-height:28.4444465637207px">If you are a TC39 member representative, just submit a pull request for your proposal."</span></div><div><br></div><div>Since you are at a member organization, attend and participate actively at TC39 meetings to advance your proposal through the process.</div><div><br></div><div>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 <<a href="https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#300" target="_blank">https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#300</a>> for rights amplification.</div><div><br></div><div>Other proposals-to-be that need to traffic in source positions are</div><div>* source maps</div><div>* passing source position through an eval</div><div>* causality tracking for multi-turn computation; at least deep stacks</div><div>* adding source positions/maps to the template objects of template strings.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 10, 2014 at 11:47 AM, Frankie Bagnardi <span dir="ltr"><<a href="mailto:f.bagnardi@gmail.com" target="_blank">f.bagnardi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Also there are some libraries which end up with a lot of wrapped functions, which could be omitted using an error cleaner function.</div><div><br></div><div>I suggest a stackTrace property (getter, no write) of Error objects:</div><div><br></div><div> - .frames is an array of stack frame metadata objects</div><div> - no concept of sourcemaps</div><div> - [[ToString]] is left implementation dependant, allowing them to add information from sourcemaps, or otherwise customize it</div><div><br></div><div>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.</div><div><br></div><div>I'm sure the smart people at TC39 can come up with a good (or good enough) way to represent PTCs.</div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 4, 2014 at 9:31 AM, John Lenz <span dir="ltr"><<a href="mailto:concavelenz@gmail.com" target="_blank">concavelenz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">Is ES6 "shipping" PTCs without implementer feedback? Or how have those that tried dealt with stack traces?</p><div><div>
<div class="gmail_quote">On Sep 29, 2014 3:20 PM, "John Lenz" <<a href="mailto:concavelenz@gmail.com" target="_blank">concavelenz@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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?  </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 29, 2014 at 12:02 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>Allen Wirfs-Brock wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
No particular reason an implementation can't optimize through that if they want to.<br>
</blockquote>
<br></span>
The question is whether it should be normative. PTC is about observable asymptotic space performance (I keep saying :-P).</blockquote></div></div></blockquote></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div><br></div><div><br></div><div> </div></div>-- <br><div>    Cheers,<br>    --MarkM</div>
</div></div>