On Mon, Jun 18, 2012 at 7:43 AM, Waldemar Kornewald <[email protected]> wrote: > On Monday, June 18, 2012 9:20:39 AM UTC+2, C Anthony Risinger wrote: >> On Sun, Jun 17, 2012 at 8:42 PM, Michael Fox <[email protected]> wrote: >> > If Adobe Air had been wildly successful then I think the world would >> > be clamoring for an open-source alternative. >> > >> > XULrunner seemed like a good idea at the time but apparently it >> > disappeared from Ubuntu years ago and I didn't notice. >> > >> > An easier, and more sensible project would be implementing the python >> > stack trace (or, more ambitiously, pdb or even ipython) in pyjamas for >> > a debugging facility. >> >> --enable-debug (possibly some others) should already create a stack >> trace, with pretty good accuracy. use --enable-strict --disable-debug >> for production, though. > > Unfortunately, the traceback won't reach into JavaScript code, so there's no > way to debug something caused by a pyjslib bug, for example. Also, the > generated code is a huge pain to go through in a debugger because it wraps > every expression in an ugly closure.
yeah, you are definitely correct here :-( the javascript code is so massively mangled that debugging pyjslib/builtin issues becomes harder than simply reading the code and/or manually inserting `debugger` statements. > 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. 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? -- C Anthony
