Our absolute favourite type of talk to do is one where we’ve been working on something so cutting-edge that we don’t have all the answers yet. This was the case with our work on the debug protocol and our talk at EclipseCon Europe. We got to take where we’d gotten to and present it to a room full of smart people who were generous enough to show up, ask questions and give us their insightful feedback.
The talk gives an overview of the debug protocol then demonstrates it working in:
- VS Code
- Eclipse IDE
- Eclipse Che
We demo 7 different types of debug functionality as supported by the protocol:
- Source lookup
- Call stacks
- Run control (step, continue, etc)
OK, so we are amazing at building debuggers but we are completely hopeless at repeating questions so you can hear them in presentation talk recordings. And the questions we were asked were really good, so here is my attempt to record them, as well as repost the answers plus update with the latest state of affairs.
Where can I find the code?
Here’s where you can find the git repo: https://github.com/tracymiranda/dsp4e. But even better, we are actively working on pull requests so that the code will become part of existing projects LSP4J, LSP4E and Eclipse Che. You can checkout the first PR for LSP4J here: https://github.com/eclipse/lsp4j/pull/131
Does the debug protocol support drop to frame? What about evaluate expressions? Hovers? Step into?
Definitely yes to evaluate expressions, hovers and step into. Don’t think it supports drop to frame, not obviously but may be there using different terminology.
Is the protocol extensible?
Yes, so you could add functionality like drop-to-frame. But the extensibility is not formalized so that is something we would like to help address.
Is the protocol blocking?
No it is asynchronous.
Does it use JSON-RPC just like the Language Server Protocol?
No it pre-dates JSON-RPC 2.0 and uses its own custom protocol. It is similar enough to JSON-RPC. While it would be nice to have the same protocol being used, it is probably not worth the effort to change this given the number of existing debug adapter implementations already out in the wild.
Also thanks to all those who left written feedback on the talk, especially the person who had this to say:
“A really good initiative. Don’t over do it though by pushing making the protocol complex just to support features of one language, seems like it is a case for C/C++, i.e. registers support. It could be a separate extension.”
Great point, thanks for the input!