[fpc-pascal] fpDebug extension for Visual Studio Code

Joost van der Sluis joost at cnoc.nl
Tue May 19 15:55:47 CEST 2020

On 5/19/20 12:59 PM, Martin Frb wrote:
> On 19/05/2020 10:42, Joost van der Sluis wrote:
>> 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;

> Where is that documented? Assuming this is part of the API?
> E.g. what goes into Flags/AdditionalInfo?

You misunderstood me. The class above is my own design. The 
variable-definition of DAB is even simpler. (As you already found out)

It is not documented, and, to be honest, only name, value and type are 
being used now. It is just a rough idea, we have to figure things out.

> Btw, for Children (I guess Fields of a struct?) we have TDbgFields. So 
> maybe that can be replaced? But it affects all debuggers....

They don't have to be fields. It can be anything. To the user it is 
presented as something they can collapse/expand. If you want to give a 
hint to the GUI how to represent the data, you can set a flag.

At least that's how it is implemented in DAB. I thought it would be a 
good idea to add a second 'group of children', the AdditionalInfo. For 
example for the character-set of a string. Things like that.

> Things like Children should have a Getter, so they can be produced on 
> demand.

Yep. But I see this structure more as a an interface. A definition about 
how the data should be structured.

In DAB they resolve this by setting some reference-id. So instead of the 
children, you get an ID. And if you want to have the children, just send 
a request with the given Id, and you will receive the children.

Not a real solution for our case, I would think.

> 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.

Maybe. I don't really have a solution yet. Maybe the reference-id is not 
that bad. (In FPDServer the id is an auto-incremented field. In a map I 
store the related info, like the thread-id, callstack-index and such. 
When this info is not available anymore, the item is removed from the 
map. Seems to work ok)



More information about the fpc-pascal mailing list