On 19/05/2020 10:42, Joost van der Sluis wrote:
Yes, you write about it earlier. Now it's time to discuss things.
Looking at the DAB-protocol I came to some new insights. Microsoft
managed to create a simple interface which makes it possible for all
kinds of debuggers to work with the same GUI. Just by adding an
abstraction layer.
Only thing is that I missed a few functions and do not need others.
So I've added my own abstraction layer. Now it is in the FPDServer
project, but I think it should be made part of fpDebug itself.
It is basically this class: (see
https://gitlab.freepascal.org/Joost/fpdserver/blob/master/fpdbgvariables.pas)
TDbgVariable = class
private
FName: string;
FValue: string;
FType: string;
FVisibleInScope: Boolean;
FFlags: TStringArray;
FAdditionalInfo: TDbgVariableList;
FInheritedChildren: TDbgVariableList;
FChildren: TDbgVariableList;
published
property Name: string read FName write FName;
property Value: string read FValue write FValue;
property &Type: string read FType write FType;
property VisibleInScope: Boolean read FVisibleInScope write
FVisibleInScope;
property Flags: TStringArray read FFlags write FFlags;
property AdditionalInfo: TDbgVariableList read FAdditionalInfo;
property InheritedChildren: TDbgVariableList read FInheritedChildren;
property Children: TDbgVariableList read FChildren;
end;
I think that we can give a frontend (Lazarus, Console, DAB) all the
information it needs with this structure.
The advantage is that it is layered, so a GUI can collapse
information. We could expand the TDbgVariableBuilder to create these
structures.
For strings for example, we could add the length, string-type,
binary-representation and character-set of the string in
AdditionalInfo. In VS Code this info will end-up as a child of the
variable, which a user could expand if needed.
A lot of the existing functionality can be used.
Where is that documented? Assuming this is part of the API?
E.g. what goes into Flags/AdditionalInfo?
Btw, for Children (I guess Fields of a struct?) we have TDbgFields. So
maybe that can be replaced? But it affects all debuggers....
Things like Children should have a Getter, so they can be produced on
demand.
Though that creates issues:
- Calling in correct thread
- any data retrieval from the debugger needs to be async. I.e. on
callback. The IDE demands the data, and it will be available in/after a
callback.
However, maybe that can be done in a subclass/wrapper in the
TFpDebugDebugger class. That is were the async is currently handled.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
