debugging support

[clankill3r]

I guess it's easier to post ideas on the issues page then to implement them...

Ok, it would be nice to some day have support for a debugger.

https://jupyterlab.readthedocs.io/en/stable/user/debugger.html https://microsoft.github.io/debug-adapter-protocol/

[padreati]

Hi,

There are multiple things to make that work. And, of course, plenty of work. There is the messaging protocol that you mention it, probably make the engine to work in a separate process (I am not sure that debugging works in the same process).

But there is something more subtle, which I don't figure out yet. This is how I identify the breakpoints inside jshell code snippets. I can take info from notebook, break it into snippets and evaluate it separately. But I am afraid I don't have a clear process in my head on how to identify those in jshell. Another approach to that would be to allow breaking points only on lines of code, and when I run a cell with code, break it into snippets and manage to pause the execution myself. That would not require a separate process, but requires probably more work on what to find pieces to display to the user.

I will take a deeper look on that and do some experiments. If I find a way I could start to do that if I find enough contiguous time.

Thank you for ideas and feedback. Best regards, Aurelian

[dsyer]

I have found it useful to attach a debugger to a running kernel. You can do it by adding JVM args in the kernel.json and then attaching the debugger after the kernel launches.

VSCode is happy to let me set breakpoints in the Java cells, but they are greyed out, so the debugger doesn't stop there. It does happily stop inside code from the classpath though, and it's easy to make that show up in the IDE as a dependency. It also does know the location of the breakpoint (file name and line number are displayed in the list of breakpoints). So it seems like we are close to having all the pieces of the puzzle.

[padreati]

When you change kernel.json to enable debugging you enable debugging on kernel program. This is different from debugging the code executed in notebook. What you can do is simply debug how kernel works, but not how notebook works. The latter could be done to some extent if while debugging the kernel you step into the jshell code and see how that works, but is far from what you want.

Since the code is executed and hosted by jshell, jshell needs debug support. JShell does not have debug support. There is JEP 222: jshell: The Java Shell (Read-Eval-Print Loop). This JEP states in NonGoals section:

Out of scope are graphical interfaces and debugger support. The JShell API is intended to allow JShell functionality in IDEs and other tools, but the jshell tool is not intended to be an IDE.

This kernel is based on JShell and I do not know any other Java interpreter which can be used. So I don't see an straight forward way t implement that.

At a deeper thought I think there is a way with JShell. We can split all code snippets, maintain a out-of-JShell registry of those snippets, send the snippets sequentially, maintain out-of-JShell a registry with debug bookmarks and related and hook everything. That would mean to create an external wrapper over JShell and control everything. Addaitionally it also implies implementing all of [Jupyter Debugger Protcol][https://jupyter-client.readthedocs.io/en/latest/messaging.html#debug-request). That is an effort of some hundred hours of work. I will give it a thought, but is far from immediate.

[dsyer]

What you can do is simply debug how kernel works, but not how notebook works.

That's not 100% true. It lets me debug the running notebook, but it only stops on breakpoints in the code from the classpath, not the code cells (as long as it is on the classpath for the Java project where the notebook lives). So pretty useful, but not quite on the money yet.

The fact that VSCode knows how to set a breakpoint in the cell seems hopeful to me. I also wish I could CTRL-click into the method names in the cells (like I can in Python) to browse the code in the classpath. I could open a speparate ticket for that if it helps, but I think it's part of the same problem.