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.