Re: pretty-printing update

[Tom Tromey <tromey at redhat dot com>]

Vladimir and I had a chat on irc about this.
This note is just to summarize our conclusions.

Tom> * A varobj's pretty-printer will be set when the varobj is updated,
Tom> based on the type of the expression.

Vladimir> I think it's already done, no?

Yeah.

Vladimir> Right now you can set any formatter on a variable object, or
Vladimir> set it to none. It seems to be useful thing to me, for
Vladimir> example, it allows IDE user to click on a field called
Vladimir> "next" and say "show list chained on next", and IDE will
Vladimir> install formatter to do so, without necessary making all
Vladimir> objects of the same type be formatted as list.

This seems like a good argument to me, and I'm going to restore this
feature.

We did decide that instead of specifying the varobj visualizer using a
class name, the MI user will send a Python expression.  This allows
more flexibility:

    -var-set-visualizer varobj FollowPointerVisualizer("next")

Tom> * -var-info-num-children will dispatch to Python as well.
Tom> I think we can just call len(object) here.

Vladimir> Doesn't it work this way already?

Yeah -- I think I broke it.  Time for me to write some tests, I guess.

Tom> * Lazily computing children.  I think it would be better to also
Tom> throttle fetching values from the inferior -- e.g., if the MI
Tom> consumer asks for 10 elements of a std::vector, then only fetch
Tom> those ten, rather than the entire vector.

Vladimir> Iterators will handle this just fine.

Tom> * Caching.  It would be nice if we could cache whatever we compute.
Tom> Perhaps this can be left entirely to the Python layer somehow.
Tom> Or, maybe the C layer can cache compute children, based on index,
Tom> between -var-update calls.

Vladimir> Well, in my code varobj code gets values from Python code, and stores
Vladimir> them, and those don't change until -var-update.

Here I think we decided to:

* Keep a relatively simple iterator interface for the python code.

* Extend the MI command to allow selecting a range of children.

* Have the varobj code cache values that it fetches (as now).
  However, it will only request the needed subset of value from
  Python.

* Extend the -var-list-children output for the case where the number
  of children is unknown.  That will look like numchild="some".

If we need even nicer caching (or more random access) support in the
future, we can extend the Python API a bit.

Tom> -var-list-children var
Tom> ^done,numchild=N,mapflag=1,[
Tom> {numchild=0,name=var.0,value="key"},
Tom> {numchild=1,name=var.1,value="value"}]

Vladimir> I think the above output is just not backward compatible at
Vladimir> all. I suggest just outputting children as plain list, key
Vladimir> and values interleaved, and adding a new field with display
Vladimir> hint. For display hint of 'map', frontend would be expected
Vladimir> to display the linear list of children as map.

It turns out that I just omitted the "children=" in the above, and our
two approaches are similar.

I like the "display hint" idea better, though, so I'll implement that.

We didn't decide on the detail of how to communicate the display hint
from Python to varobj.  This is no big deal; maybe a new optional
method.

Tom