I agree that LSP may be a bit off-topic in this discussion, but I think DAP is very much relevant: implementing it, or the relevant portion of it, as the means of communicating with the in-process debug agent gets us a large bit of the way to having support in a range of debugger clients (VS Code, Eclipse, emacs). Put another way, if hilfe-over-socket isn’t going to be the debug interface (and I never really had it in mind for that to be the ultimate solution), then we’d need to implement something else and I’m not sure there’s a better option.
There’s plenty of functionality present in the proof of concept to be able to start working against the actual debug agent, or a stub at the very least. Yes, there’s still a lot of low-level work required but it doesn’t make sense to wait for that to be completed before getting started with higher level bits… especially if someone wants to help out but isn’t comfortable working in the depths of the interpreter.
I’ve already used the POC to explore some programs and have learned a few interesting things.
A few examples of things that could be worked in parallel:
- The DAP message specification is contained within a JSON schema. There are a lot of message types to be implemented. It would be really handy if there were a way to spit out marshaling code from the schema. There’s a tool called QuickType[1] that can do this, and can be extended to support new languages. Perhaps someone can come up with an approach to using Standards.JSON to marshal/unmarshal JSON messages and implement a Pike class generator for QuickType? I think this would be valuable and given the amount of work maintaining those classes manually, could save a lot of time.
- There probably needs to be some thought given to calculating code blocks so that step-in and step-out can work. I’m not sure what the best approach here would be, but if speed were not a concern, it could be a layer of pike code that sits on top of single stepping and monitoring the code position against a rudimentary tree generated by parsing the pike code under debug.
- There will probably need to be an agent process responsible for starting and monitoring the process under debug, possibly passing portions of the DAP message stream on to the in-process debug agent.
- Does optimization hurt the ability to debug? Breakpoints on constant expressions or on a for loop, as examples, won’t get hit how you might expect them to. Is that okay, or should we explore ways to skip optimization at runtime?
Bill
I think having both
LSP and
DAP implementations for Pike would be awsome, but I feel that this discussion is getting further away from it's main point. We've been talking about LSP for a little during the Conference. There is a huge interest in it and I think we should move the LSP discussion to another mailing thread to avoid mixing contexts.
Having a Pike debug adapter would also be great, but since DAP is used for estabilishing communication between IDE and the debugger, we can't move on with it until we actually have a debugger.
From what I understand the greatest challenge now would be to reach the local variables. I've heard that long time ago, the language got some optimizations that makes retrieving local variable names very challenging. Is it true? If yes, how we can jump this through?
I would be more than happy to help crossing-out the remaining TO-DOs, if I only could get some itroduction and clues.