Re: variable objects and registers

[Vladimir Prus <ghost@cs.msu.su>]

On Wednesday 20 December 2006 23:30, Nick Roberts wrote:
>  > >  > or just "-var-list"? On the other hand, on Apple branch the varobjs for
>  > >  > locals are created using
>  > >  > 
>  > >  >         -stack-list-locals --make-varobjs
>  > > 
>  > > Most of the functionality seems to come from varobj.c so, unless Apple
>  > > contribute this code to the FSF repository, I see no need to follow their
>  > > approach.
>  > 
>  > I don't think this particular interface decision is important, but I don't
>  > follow your general principle. It does not matter if Apple ports their code
>  > to FSF, or we do it -- if differences are introduces for no good reason,
>  > it makes it harder to merge changes for everyone, and that's bad.
> 
> It's easier for Apple to port their changes back than us, and they can always
> do this if they wish.  If it's easier to put the function in mi-cmd-stack.c I
> would call it "-stack-list-locals --make-varobjs", but if it's easier to put it
> in mi-cmd-var.c I would call it -var-"something".
>  
>  > > 
>  > >  > I slightly prefer
>  > >  > 
>  > >  >         -var-list --locals
>  > > 
>  > > -var-list-create --locals?  -var-create-list --locals?
>  > 
>  > I've settled on -var-list. I don't think 'create' clarifies much,
>  > and this is not user command,
> 
> Except that it doesn't just list existing variable objects but "creates" new
> ones.  

I fact, I'm not sure what duplicated

	-var-list --locals 

should do. Create afresh, or just return already created?

> Its _always_ helpful to have a descriptive name. 

The name itself is not useful without docs, so we need no try too hard. For example,

	-var-list-create

and
	-var-create-list

are also inaccurate, because this command does not create list. It creates 
variable objects and then lists them.

Can we have some reasonable way out of this bikeshed?

>  >                               and '-var-list-children' also creates
>  > variable objects without having 'create' in the name.
> 
> Good analogy.  I had to add the fact that it created variable objects for
> the children to the manual because the original author had ommitted/forgotten
> it.  Are you saying we should copy existing bad design?

I'm saying this does not matters much. One has to read all the docs anyway.
 
>  > > Insight creates variable objects for display of locals.  The delay is
>  > > quite apparent when there are more than a couple of them, but it only
>  > > updates when
>  > > the frame changes.  
>  > 
>  > By "updates" you mean '-var-update' or regetting new list of locals and 
>  > creating new vars?
> 
> The latter.
> 
>  > > In Emacs, I update after every GDB command using "info 
>  > > locals" which is quicker 
>  > 
>  > Quicker than what? -var-update? Is this a measurable difference? If
>  > so, we should fix it.
> 
> Quicker than regenerating variable objects for all the locals.

Yeah, not surprising given that "info locals" is a 'wholesale' operation.

>  > > but not as good.  We need to find a way to detect 
>  > > when the frame changes 
>  > 
>  > FWIW, KDevelop uses "info frame" 
> 
> Does this approach know when it's not another invocation of the frame
> with the same name?

No, but this approach is only the first check. After that the list of all
local name is obtained and then addresses of all locals are obtained and
compared with previous values.

>  > I think that we need more higher-level notification -- namely "new locals
>  > appeared" and either:
>  >         - "varobj now refers to different object"
>  >         - or have a command that creates varobjs for all variables
>  >         in a function.
> 
> The latter is "-stack-list-locals --make-varobjs" isn't it?  Or are you talking
> about variables declared within compound statements?

Both. -stack-list-locals --make-varobjs creates variable objects for all variables
in a function, including in nested blocks.

I think it might be good idea for you and I to go though Apple branch grepping
for all "APPLE LOCAL" markers so that we know everything they've added.

>  > >  > Then, the varobj.c would have to expose magic "@" and "*" values in its
>  > >  > interface. I think it's better to keep this closer to parsing code and
>  > >  > keep varobj.c separated.
>  > > 
>  > > Yes.  OK, in that case I would call the function create_var_in_frame. 
>  > 
>  > That function creates and returns variable object. Calling
>  > it 'create_var_in_frame' would imply that it creates some 'var',
>  > and that would not be accurate.
>  > 
>  > > Likewise with existing functions:
>  > > 
>  > > varobj_update_one    -->  var_update
>  > > print_varobj         -->  print_var
>  > 
>  > This one, too, prints variable object.
> 
> They're all for variable objects.
> 
>  > > so that they are in the file you would expect to find them.
>  > 
>  > I'm not sure. I don't know why a name of a function should map to the
>  > name of the file in the way you indicate.
> 
> The distinction I'm making is that var_* functions and variables are for use in
> MI and generally live in mi_cmd_var.c while varobj_* ones may be used by
> Insight and live in varobj.c

I don't think the difference between "var" and "varobj" in function
name communicates what you want, and I don't think such a coding guideline makes sense
for future.

- Volodya