On Mon, Jun 18, 2012 at 6:05 PM, C Anthony Risinger <[email protected]> wrote: > On Mon, Jun 18, 2012 at 7:43 AM, Waldemar Kornewald > <[email protected]> wrote: >> A better approach might be to generate >> normal JS code (without those ugly closures wrapped around every expression) >> and then analyze the actual JS exception's traceback and map that back to >> Python source. This might also give us source map support almost for free, >> thus making debugging even easier once source maps are supported in all >> major browsers. We could use this code to extract the JS traceback: >> https://github.com/eriwen/javascript-stacktrace > > interesting; i don't have issue with using small specialized JS > libraries like this since it's essentially optimized assembly. > > so, you are suggesting we walk up the trace produced by said library, > and determine the corresponding python ... does that stacktrace > library return live references to objects higher in the stack? IIRC > the python line number is incremented explicitly, and the stack is > appended/popped before/after each function call ... i think we may > still need those pieces, or at least line-tracking (unless you have > something in mind), but overall it sounds like a better approach.
Well, I haven't thought this 100% through, so I might be missing something, but the JS traceback already contains the line numbers of the generated JS code and the trace of all called functions. We can store a mapping from generated JS lines and columns to Python lines and columns. That should allow us to reconstruct the whole traceback. We don't need to increment/push/pop line numbers in the generated JS code, anymore. There's just a little complication in the try/except/raise handling. JS has no notion of re-raising or raising with a custom traceback, so we have to work around this, maybe by injecting the traceback into the exception object, so a try/except block can set sys.exc_info() to the injected traceback instead of using the one created by the javascript-stacktrace library. Not sure if I've missed other details that might complicate this approach, but I'm pretty sure we can pull this off. > i'm not as familiar with source maps ... i realize they are a method > of mapping minified/object code back to "non-minified" code (or the > original source if translated), but very little beyond that. my brief > search suggests it's not available in the current release of any > browser, is that right? This article provides a good overview (especially the videos): http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ Source maps can be used in the debugger, so you can step through Python code (!) instead of the generated JS code. This will radically improve the whole debugging experience. Unfortunately object inspection stays at the JS level, so when you have a list object you still have to look at __array. But that'll surely be improved, too. Source maps are already in the unstable builds of Chrome and Firefox, so it won't take long until they're supported in the official stable releases. Bye, Waldemar
