[fpc-pascal] fpDebug extension for Visual Studio Code

[Martin Frb]

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.