Hi! Thanks for the update.
I think it makes most sense to get the portions of the code that exist within existing files merged into the 8.1 codebase. Very little of the code is within an active path for most users, and I think the risk of running into unwanted behavior in the short term is outweighed by the possibility of more merge nightmares if it's kept on a feature branch.
In my mind, there's a logical argument to be made for splitting the effort into a) the componentry required to support debugging in pike, b) the componentry required to support one or more debugging protocols and c) any work required to be able to debug a pike program from a debugging tool.
The majority of the work required in the lower reaches of pike is more or less done. I believe the last major pieces are: - the ability to throw a thread into single-step mode - the ability to stop at any of multiple offsets for a given line - my proposal for naming threads - exception trapping
Each of these feel to me like incremental features and probably don't need to hold up integration.
The remaining major core functionality would likely be restricted to the Pike.Debug module: providing access to the additional low level features and mapping programs to file paths. I need to look more closely at how DAP and other debug tools handle step-into and friends; that will determine whether or not the core debugging support needs to handle those features directly or not.
As always, thoughts and feedback are welcome.
Bill
On 2020-02-14 03:45, Mateusz Krawczuk wrote:
Hey Bill, Sorry for the late response. I'm happy for your interest in continuing the debugger project.
Most of the answers to your questions can be found in the 'debugger, status and suggestions sought' thread, in the last few letters.