zooba
commented
9 years ago Hi @ellisonbg, @fperez, @takluyver and @minrk (and anyone else you guys would like to call in), here's something we're hoping to do over our next major release, and it's going to need some collaboration. We're obviously willing to pick up a decent chunk of the IPython work to make this possible, but right now we're still at the "what's feasible" stage, so we'd love input like "that's impossible", "we tried already", "already works" etc.
ISTM that the multiple-frontend setup could be problematic (particularly that I think we'd want the PTVS frontend to get all messages but the notebook frontend to only get its own), though I haven't tried to do this yet or even looked at whether it would work.
I'd also like @int19h to pitch in and list any extra debug messages/requests we'd need to make this fully functional in VS.
(The whole point of us putting these sort of plans up publicly is to clarify them, so feel free to ask as many clarifying questions as you like until every little piece is clear.)
ellisonbg
den-run-ai
Carreau
SylvainCorlay
int19h
minrk
We should be able to attach VS to a running IPython kernel, submit code, and debug cells as they execute.
(Note that this will require some work on Jupyter and IPython to support it. Without this work, we will be extremely limited in what we can provide. Notes are included below as to which project needs changes to support the flow.)
Users would obtain some connection info from Jupyter (potential UI changes to Jupyter? - possibly a way to extract/request it from the URL?) and paste it into an interactive window in PTVS.
PTVS would attach to the IPython kernel, without disconnecting the notebook, and start mirroring every interaction. When a cell is executed from the notebook, the code and output are both added to the REPL as a previously executed input and its output. (Some way for Jupyter to recognize output for its own requests?)
Users can execute code against the kernel from the REPL and view the output. This code/output does not appear in the notebook. Users cannot access/modify the notebook contents from this entry point (this feature is about the kernel, not the notebook).
Users can hit a checkbox to enable debugging, either in PTVS or in Jupyter (TBD). This will signal the kernel to begin tracing execution and transmitting debug messages (line, call, return, ...? probably needs a server-side filter and breakpoint handling). The front-ends can transmit debug requests to get information like file contents (full source), directory listing, current stack trace, locals info, value repr, evaluate expression, ... and present this in whatever UI they choose. For PTVS, this will be the usual debugger interface, but Jupyter could also present this debugging information in some way.
When debugging, code submitted through the PTVS REPL automatically breaks at the first line, and users can set breakpoints in any open file from the kernel (initially, they'll probably just have to know the full path if it isn't already open, but we could eventually have a browser).
Potentially users could also set breakpoints in Jupyter that would break in PTVS (depends on Jupyter getting breakpoint UI).
Jupyter is unable to execute cells while a cell is being debugged, though it can still queue them for execution after the current cell completes.
Debug Requests
To implement full-featured debugging via the Jupyter protocol, we'd need to be able to make these requests of kernel. (Feel free to edit directly or comment if you have more suggestions/questions). ('id' means a unique identifier so we can call back into the kernel and identify the item; 'str' means a human-readable representation)
'inspect'messageglobals()in IPython - I think we can do better'inspect'messageDebug Events
To implement full-featured debugging via the Jupyter protocol, we'd need the kernel to send the following messages when debugging is enabled. Other filters may apply to events, primarily to improve performance while debugging by sending fewer events.