What do kernels need to do to participate in this?

[davidanthoff]

We've made a lot of progress with a DAP protocol implementation in Julia, now I'm wondering how we can integrate that with the work here and get the Julia kernel to support debugging.

I looked through https://github.com/jupyterlab/debugger/issues/64, and that is super helpful already, i.e. I'm getting a good overview of how this is supposed to work. But a fair number of important details are unclear to me :)

So, I guess first question: is there a more complete spec somehwere?

Some more specific questions:

• kernel_info_request should somehow indicate debugging capability. What exactly needs to be added?
• What is the debugInfo request that is shown in the diagram?
• I assume the initialize request is the first "normal" DAP request, right?
• Am I right that the DAP messages are then wrapped in debug_request requests? What exactly is wrapped there? The whole DAP message, including things like the seq field?

[JohanMabille]

This is still experimental and on-going work, so a more complete spec is not available yet. However all the work done here and in xeus-python will be used for extending the Jupyter messaging protocol. Here is what is currently done in xeus-python (especially in this file):

• kernel_info_request: for now we simply added a debugger boolean entry in the kernel_info_reply message, see this PR
• debugInfo is a message sent to the kernel to retrieve all the info relative to a debugging session (when a client connects to a kernel that already has a running debugger, or when you reload a jupyterlab page for instance). You can see the different fields of this message here
• indeed initialize is the first "normal" DAP request
• DAP requests are wrapped in debug_request messages, DAP response in debug_reply messages and DAP events in debug_event. These messages are regular Jupyter messages whose content field is a whole DAP message (including the seq field).

[davidanthoff]

Awesome! Do you think it makes sense to start working on this? Or is this all still so in flux that it is too early? I wouldn’t mind some breaking changes, as long as the general story is ready? Might also be useful to stress test the design with another language kernel?

[SylvainCorlay]

@davidanthoff yes, I think that most of it is already stable, There may be minor changes with respect to the extra messages that are required in addition to the DAP messages.

Another aspect to be aware of in your implementation is that ideally, your kernel should be able to process messages of the control channel (including debug messages) concurrently with the messages of the shell channel (which include e.g. execution requests) so that you can add or remove breakpoints while code is running, and not have to wait until the current execution request has completed.

The xeus-python codebase is rather simple to look at as it is much more concise than ipykernel and it may be a good way to get a sense of how the backend works.

[afshin]

@davidanthoff Having another kernel that uses the debugger front-end would be great. Please try it out, kick the tires, and feel free to post issues here.