[Lazarus] Playing with debuggers

[Joost van der Sluis]

Op 14-09-2021 om 02:18 schreef Martin Frb via lazarus:
> On 14/09/2021 01:00, Joost van der Sluis via lazarus wrote:
>> I'm playing with several debuging-concepts. And I want to share this 
>> one with you.
>>
>> I've created a new Lazarus-debugger LazDabDebugger that can work with 
>> FpdServer. It depends on a package (LazDebugExtensionIntf) that adds 
>> another way of showing debugging variables inside Lazarus.
> Great, the frontend was overdue for a remake.
> 
> I have not yet looked at the code.
> But ideally this should just replace/extend the existing watches. Of 
> course that also would need the debugger intf to be updated.  (That does 
> need an overhaul, and yes it could mean all existing debuggers will need 
> a bit of work to follow / ideas welcome)

What I did now, is add new dialogs, and created an debug-interface 
separate from the existing one. But with the idea that it could 
replace/be merged with the existing one.

What we could also do is make the debug-windows (watches, locals, 
evaluation pluggable, so that a debugger can choose which one to use.)

> Ideally the entire debugger frontend could move into a package of its 
> own too (all the current windows).

Exactly, that is why I created a new debug-intf package instead of 
adapting the existing one.

>> I can write tons of texts about the background and possibilities. But 
>> for now I'm just curious at your input.

> Currently the debugger intf allows to fetch watches as plain text, or as 
> structure. But this has to be passed in as flag at the request time.
> 
> Any watch object should instead have methods to fetch "sub watches" so 
> structures can unfold.

What I have now is that each object has a 'reference', and there is a 
separate call to get the sub-watches that belong to the reference. That 
way the data (in the object) and the logic (function to retrieve 
sub-watches) are separated.

I don't have a solution for requesting the result as text(string) only. 
But that's not a bad idea.

> I see you pass the variable to the debugger, that is ok. But that may 
> well get abstracted into the Watch, so the watch has its own ref to the 
> debugger, and makes the needed calls.

I don't follow exactly. But if there's a need for an extra abstraction 
layer before sending the variable to the debugger directly, this could 
be added.

> Not sure about passing callbacks directly. Thinking of the current 
> notification system (data monitors).
> What does your new watch window do, if the user modifies a variable? 
> This triggers re-eval of all watches (so they need to unfold again).
> Currently the debugger backend can trigger the re-eval, and through the 
> data-monitors tell everyone about the updates.
> 
> Have to look at it in more detail....

I have something similar as the data-monitors.

Main difference is that the events are based on what the gui needs, 
instead of what the debugger does.

So: there is an event to tell the 'gui' that it is inpossible to show 
any data. (for example: the application has stopped or there is no 
debugger at all) There is an event for the case that debug-data has 
become available or unavailable. (Application paused or continued)

And I should add an event for the case that the debug-info should be 
re-evaluated. (context switch, or variable-change). And I can think of 
another event that can be send when the debug-data could have been 
changed, due to unforeseen effect, for example when a propperty with a 
getter has been evaluated.

The advantage of 'events' that are more geared towards the gui, is that 
it is easier to add catchy things. For example: to avoid flickering, 
when the gui receives an event that debug-data is not available anymore, 
it starts a timer of 200 mseconds, and only after that timer the data is 
removed from the screen. This way, when stepping through the code, there 
is no flickering in the small periods of time that the application runs.

It also made it easy to highlight variables that changed.

But atm they are only suitable for displaying variables. Stuff like the 
call-stack are not touched.

Regards,

Joost.