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.
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
