Re: [cdt-dev] DSF Variable-Expression API Question

[<ken.ryall@xxxxxxxxx>]

Title: Re: [cdt-dev] DSF Variable-_expression_ API Question

Pawel,

Thanks, that’s a good idea, I’ll start working in that direction.

Which led to another thought: Since each variable for a stack frame has to be uniquely identified by name I need to come up with a notation to distinguish between variables with the same name from different scopes within the same function. It looks like IVariableVMData.getName is only used to create the _expression_ and not for display so I suppose I could encode additional info about the variable into the string returned by IVariableVMData.getName.

Ken

---

From: ext Pawel Piech <pawel.piech@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Fri, 5 Jun 2009 01:17:07 +0200
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] DSF Variable-_expression_ API Question

I suppose this is a good example of the GDB bias in the DSF interfaces.  IVariableDMData has two methods: getName() and getValue(), because these are the two pieces of data returned by GDB for the -stack-list-args command.  But for the variable data to be really useful, the full _expression_ information needs to be retrieved using the _expression_ service.  In fact, the UI implementation currently doesn't even use the IVariableDMData.getValue().  IMO, it would be acceptable to just deprecate this method.

I think you can do two things to simplify the implementation:
1) Implement IVariableDMData to only return the getName(), return a null value for getValue().  This way, your implementaiton of getVariableDMData() wouldn't require any target access.
2) Implement IVariableDMContext and IExpressionDMContext using the same object, then delegate the getVariableDMData() call to the _expression_ service, this way the caching will be simple.  At the API level we didn't want to introduce too many dependencies between the interfaces, so that for example we could replace the IExpressions service with something like IExpressions2, without having to deprecate methods in other services.  But this doesn't mean that you can't mix and match these interfaces within your implementation.

Cheers,
Pawel

ken.ryall@xxxxxxxxx wrote:

 DSF Variable-_expression_ API Question DSF folks,
 
I’m working on getting local variables to show up in the Variables View. After getting the list of variables from the symbol data I produce a list of IVariableDMData from iStack.getLocals. These seem to get consumed by the code in VariableVMNode. GetLocalsUpdateElementsInSessionThread. For each of them it asks for their name and then calls the _expression_ service to create a new _expression_ from that name. The resulting ExpressionsDMCs are then used to drive the view.
 
This bothers me because I’m first getting the information about all the variables for a stack frame and handing their names to the _expression_ service which will then look them up all over again in order to evaluate the expressions. I can do some smart caching to reduce the impact of this but it seems like there ought to be more direct route from iStack.getLocals to the list of ExpressionDMCs that are eventually used, maybe a way to create an ExpressionDMC directly from a VariableDMC?
 
Please let me know if I’m missing something.
 
Thanks,
 
Ken

---

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev