« Return to Thread: debugging interfaces

Re: debugging interfaces

by Mark S. Miller-2 :: Rate this Message:

Reply to Author | View in Thread

On Mon, Jun 15, 2009 at 5:06 AM, Jordan Osete <jor@...> wrote:
Hi everybody.

I've wondered for some time if it weren't possible to harmonize stack traces across browsers.
I have submitted a (simple) proposal on the WHATWG mailing list (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020359.html), and got somehow "redirected" here ;-)

So here is the proposal, as I first submitted it. Please tell me if it is not exactly the best place for this.

This is the best place. Thanks for posting.

 
Part of the functionality proposed here also assumes a browser environment (html / js files) which probably cannot be implemented in some other environments (like JS interpreters).
Also I do not care that much about the proposed property names. They are just here as examples.

Note: unfortunately, I do not "speak" Java at all, and thus I don't know JVM TI. I only skimmed through "JavaTM Virtual Machine Tool Interface (JVM TI)" (http://java.sun.com/javase/6/docs/technotes/guides/jvmti/), but it seems it goes far beyond what I describe here.

It does indeed. I do not suggest that a debugging API be modeled on it in any detail. However, it does have one great virtue: it is stratified in the sense explained by <http://bracha.org/mirrors.pdf> and not generally accessible from within the computation being reflected upon. This is essential to reconcile debuggability with strong encapsulation.

In particular, one of the motivations for introducing strict mode into es5 is so that the encapsulation of strict functions can be safe even from non-strict functions. This is explained starting at slide <http://google-caja.googlecode.com/svn/trunk/doc/html/es5-talk/img39.html> which corresponds to minute 41 of <http://www.youtube.com/watch?v=Kq4FpMe6cRs>. However, the mechanisms explained there were insufficient, resulting in the following agreement at the last EcmaScript meeting:

On Mon, Jun 1, 2009 at 5:11 PM, Waldemar Horwat <waldemar@...> wrote:
Rather than describing the evil things that implementations do with F.caller, we agreed to just impose a blanket prohibition of code peeking into the environment records or identity of strict functions on the stack.  This way a test suite can ensure that F.caller does nnot reveal strict functions without us having to introduce the evil things into the standard.  I'll write up proposed wording.
 


 

-----------------------------------------------

* What is the problem you are trying to solve? *
If you want a traceback, you need to cater for multiple browsers behaviours, and different and incomplete information.

* What is the feature you are suggesting to help solve it? *
Harmonize JavaScript stack traces across browsers. There could be a global getStackTrace() method, wich would return an array of stack frames, closest one first (or last, I don't care). Every stack frame object could have the following properties:

To identify what script we are in:
- the script filename, if external script (JSFileName)
- or HTML filename, in case of an inline script (HTMLFileName)
- or, in case of an "eval()" call, a special evalScope property must be
set to true
- a reference to the script tag DOM object, if the script was not eval'd
(scriptTag)

To identify where in the script we are:
- a simple way to get the script's full source code, whatever way it is
eval'd or included. For example, a fullJSSourceCode property
- the line number, relative to the start of the script (sourceLine)
- the line number, relative to the start of the file containing the
script. It is equal to sourceLine, except if it is an inline script in
an HTML file (fileLine)
- the position of the substring delimiting the instruction in the source
code, relative to the start of the line. This is especially useful if
the JS source is "packed" or minifed, and thus newlines have been
suppressed (instructionOffsetStart and instructionOffsetEnd)

And about the environment:
- a reference to the "this" object in the given stack frame (thisObj)

If the debugging API is unstratified or generally accessible, this violates encapsulation.
 

- a reference to the function called (func). This is a function object.

If the debugging API is unstratified or generally accessible, this violates encapsulation.

- the arguments the function was called with, just like the arguments
pseudo-array in a function (arguments)

If the debugging API is unstratified or generally accessible, this violates encapsulation.

- a reference to the variable object, that carries all of the variables
that have been defined with the "var" statement, and that can be
accessed in this stack frame ? (variables)

If the debugging API is unstratified or generally accessible, this violates encapsulation.
 

However, if the debugging API is constructed and made available in a way that doesn't violate security, your list above may be a good start. Thanks.

--
   Cheers,
   --MarkM

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

 « Return to Thread: debugging interfaces