Improving stack traces

[rgbkrk]

This is somewhat of a cross project issue, as I badly want to improve support across all the Jupyter kernels. However, for my current language of choice, javascript, I want us to be able to get to an ideal similar to RunKit:

/cc @carreau @minrk @maxogden

[n-riesco]

The way I see it, there are two issues to solve here:

• extend request_reply to include stack-trace locations
• create an API to inspect stack trace locations (extend inspect_request? or a new message type; e.g. inspect_location?)

I've had a quick look at how this would affect IJavascript:

• parse V8 stack traces (easy, see info below)
• add documentation for the Node.js library (this's been a long standing item in my TODO list)
• inspect local source files

My feeling is that, unlike https://github.com/jupyter/jupyter_client/issues/51 , this issue could be supported by the Jupyter messaging protocol in cross-kernel way without much problem. We only need to agree how to represent stack-trace locations.

A very simple solution (that wouldn't require any changes in request_reply) would be to represent locations as strings (and let the kernel parse those strings to provide inspect information).

---

Some relevant info for IJavascript:

Stack traces in V8 gives information about:

• error: type and message

• location: function, and source line and column

  Below is a screenshot of what stack traces look like currently:

[minrk]

+💯 There's quite a bit of interest in better stack traces. A draft spec for discussion would be super useful, so we can start to get feedback from a few kernel authors (I'm especially interested in the common bits between Python, Julia, and Haskell, which tend to cover a lot of the potential variety).

One super simple extension (at the protocol level, anyway) would be allow tracebacks to be mime-bundles. Then a rich HTML representation could be rendered by the client, and nicer renders could get custom mime-types.

The discussion has been touched on here, if you'd like to pitch in with proposals.

[n-riesco]

@minrk I think we should agree what use cases we want to support before drafting a spec. From your message and mine, these are the two use cases I see:

• provide rich formatting of stack traces
• provide inspect information for stack locations