I think there’s a sense that the parts of the debug infrastructure that run within the process under debug should be as lightweight as possible, and not be active unless the process is being debugged. In keeping with this line of thought, I think the in-process portion of the agent shouldn’t be fully featured, as that would imply that it would be parsing code for metadata like block locations and the like (for stepping over, etc). The —debugger option is intended to be the mechanism which activates the in-process debugging agent.
If your concern is that connecting to a hilfe session is not an ideal debugging tool, that is true, but it was never my intention for that to be the final state. Rather I had some code that served a similar purpose and it didn’t make sense to go off building a lot of infrastructure if the premise wasn’t workable.
Something along these lines is what I had in mind:
Debugging Tool <— DAP —> Debug Agent <— DAP-lite —> Pike process under debug
Now, the debugging tool and Debug Agent could theoretically be a single process, such as a command line debug utility along the lines of gdb, and it could possibly know how to start a pike process for debugging or could also just allow connecting to a running pike process which has the debugger enabled. This is basically how the Java debug agent works, and it allows local and remote debugging, which is pretty handy.
Bill
Forget that pull request, I've got something way better!
I gave up on hacking quicktype to make it spit out the protocol objects they way I wanted and started to rewriting it manually. I also came up with a proof-of-concept Debug Adapter written in Pike.
If you would like to take a test ride, just clone my repository[1]. More detailed description and instructions are in the readme.
Originally, the adapter is meant to be a mediator between a debugging editor and the debugger client, but since we don't have a debugger client we just might go with plugging the adapter inside the debugger and use it as a client (which will actually make it a debug server).
At this point we have to think how the debug mode should be launched. I don't believe the `--debugger` CLI arugment is the best approach. Maybe something GDB- or Python-style?
Now I'll be working to integrate what I already have here with Bill's concept debugger so it will be possible to set/stop at breakpoints using an editor of choice.