Comment by skybrian | Hacker News Reader

Comment by skybrian | Hacker News Reader

We do need a good way to inspect the JavaScript heap when it contains data structures from non-JavaScript languages. However, I'm not convinced this should be represented as data. It seems better to represent it as a reflection API that's implemented as a JavaScript library provided by the compiler. The debugger can load the javascript file into the web page when needed, and it can use whatever data format it likes.

Chrome is working on a way to this [1]. However, it's not done yet, and it needs to be be turned into a real standard. It's also not likely to work well for asm/wasm as-is.

New standards are important but we also need to properly implement the standards we already have. Sourcemaps have been around for years but they're not fully implemented by most browsers that claim to support it. (Firefox sourcemaps didn't work well when I tried it in January, though some bugs have been fixed since then.) I think someone needs to write something like the Acid tests [2] for browser debuggers.

[1] https://docs.google.com/document/d/1FTascZXT9cxfetuPRT2eXPQK...

[2] http://www.acidtests.org/

Note that the proposal you linked is solving a different (albeit related) problem compared to what I discuss in the article.

That proposal is about formatting the JS-implementation of Java/Clojure/etc specific objects/types at the source-level.

The article is discussing how to even locate a binding's value. The more aggressive your compiler, and the further your source language from JS, the more this becomes a problem that needs solving. However, this is also a problem for people that simply need to debug minified JS and don't want to figure out which source-level variable "aB" refers to, or struggle to figure out that some other source-level constant variable was inlined and can't be inspected by the debugger anymore.

Neither of the two solutions need to block progress on the other. Neither of the two wholly fixes the other's problem, either.

This idea of a procedural interface between compiler and debugger goes back Norman Ramsey's ldb: https://www.cs.tufts.edu/~nr/retargeting-summary.html (if not further). It seems like a good one.

Reflecting over JavaScript objects isn't going to allow you to reconstruct the original source structures from a non-trivial transpilation. Any case where there isn't a 1:1 mapping won't work.

The Chrome feature you link to deals with custom formatting of JavaScript objects, which is not the same thing. For example, what happens when two JS objects map to one object in the source language? The browser requires knowledge of the source language to handle that. Also dumping objects is very different from inspecting the scope tree - the latter requires knowledge of the current stack frame, closures, etc. which are only available to the debugger.

I agree that inspecting the stack is different than inspecting the heap; the Chrome proposal doesn't cover that. But we could come up with a similar API allowing the debugger to pass in a representation of the JavaScript stack to a stack deobfuscator and get back a language-specific representation of the stack for display; it's basically the same thing. (A complication: when a program is written in multiple languages that call each other, we need to figure out which language each portion of the stack belongs to.) Stack frames are often not one-to-one either due to inlining and variable reuse, but for a given stack frame and a given location in the source code, there will be some interpretation of the JavaScript stack frame that makes sense.

The idea is that the reflection library has all the language-specific knowledge baked in, because a compiler generates a different .js file containing debugging information for each program, just as it generates a source map today.

More generally, any information sent as a data file can just as easily be sent as a JavaScript file if we can come up with a suitable API. A data format will in general be less flexible than one that includes the possibility of running code.

Its easier and cheaper to both write and interpret a pure data api.

A pure data api is going to be more easily compressible, more performant, and easier to specify (since execution state or time never enters into the picture).

It also avoids a lot of issues with your proposal, like multiple passes (do you need to run it through multiple functions? this is getting more complicated, not to mention even slower...), multiple languages (which you mentioned, but is really only an issue caused by your suggestion...)

You'll have to explain how to do it with a pure data format because I don't see how. It seems like a data format will only work for languages with a similar implementation to what the designers of the format had in mind?

As a simple example, how do you determine the type of a JavaScript object on the heap when each language implements runtime type tags differently, and each language has a different type system?

A language-specific JavaScript function running in the same heap can do whatever it likes to compute the type, including calling into the language's runtime system. Furthermore, the Chrome API I linked to doesn't even care what the type system is; all it cares is that the data can be somehow displayed in outline format.

Of course, this approach has its limitations too; it does assume that, at least at the top level of the outline, you start with a JavaScript object and there's some way to compute a runtime type from it. This doesn't work for an untagged language where we refer to objects using array indexes like with asm.js. So it's not completely general. But I think that just means the design needs improvement; I don't see how switching to a pure data format would help.

Scopes are tree-shaped, what more flexibility do you need? Do you have a reason to believe that DWARF, which has stood the test of time, is somehow lacking in this regard? Don't forget that unnecessary flexibility is really just needless complexity. As the article says, the final mapping from a debugger entry to a value can be performed using JavaScript in order to have flexibility where it is actually needed.

Any API which inspects the stack is (obviously) going to have to run in a separate thread/stack which then means you won't be able to use plain JavaScript to retrieve in-scope object values, as in the article. Instead you'll have to introduce an API which provides a means to reflect over the other thread/stack's scope tree - so the "less flexible" scope tree will simply be baked in to your (by this point very complex) API.

I'm not that familiar with DWARF, but its support for languages that aren't C seems to be limited. Go apparently emits DWARF information [1] but it's regarded as a language that doesn't have good debugger support - for example, see [2]. Apparently Haskell (ghc) has some support but it's pretty limited? [3]

It's not used at all for Hotspot, V8, or Dart. The way these languages work is that they have a debugger protocol that allows the debugger to connect to the runtime system. That isn't so far from providing a debugging library written in JavaScript.

So I think if DWARF can work, it needs to be proven.

[1] http://blog.golang.org/debugging-go-code-status-report [2] http://www.reddit.com/r/golang/comments/2h57hf/trouble_debug... [3] https://ghc.haskell.org/trac/ghc/wiki/DWARF

Reply on news.ycombinator.com