What exactly is this hypothetical parser needed for? Can you give more detail on what is needed?

I've been working on the debug adapter for a while now and made it possible to work with DAP-compliant IDEs, like VScode. You can check it out at the 'debugger' branch of my Pike fork [1].
Breakpoints, stack trace and variable browsing seems to work pretty well. I've also made it possible to attach to a running Pike process and set breakpoints at runtime. To make it possible I've introduced a program cache, which is string-program mapping. It exists in the master object and is updated every time a program is loaded. It is needed because the way we handle breakpoint initialization deferring is insufficient for this scenario. I wonder how does it affect memory optimization.

One major thing that is missing is setting breakpoints on class methods. Any clues how to implement it?

[1] https://github.com/mkrawczuk/Pike/tree/debugger

czw., 7 lut 2019 o 19:14 H. William Welliver III <william@welliver.org> napisał(a):

Update:

I took a little time this morning and merged grubba's local variable names branch with the debugger branch, and it looks pretty good.

Seems to me that the next piece of infrastructure that's needed probably involves some sort of Pike parser. I've looked at the java parser a bit and I'm not really happy with it. Perhaps it would make sense to extend Parser.LR to work with Parser.C.Tokens and generate a pike grammar for use with it?

I looked a little bit at Parser.LR and it looks like some features we'd want might not be complete (like %token) or that would make maintaining similarity with the existing grammar (like |). Does anyone have much experience using Parser.LR or might have some real examples?

Bill

February 6, 2019 8:20 PM, "H. William Welliver III" <william@welliver.org> wrote:

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