variable objects and registers

[Nick Roberts]

 > >  > 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.  Its _always_ helpful to have a descriptive name.

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

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

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

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

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

-- 
Nick                                           http://www.inet.net.nz/~nickrob