Re: pretty-printing update

[Tom Tromey <tromey at redhat dot com>]

Vladimir> Note also in MI, each variable object is associated with an instance
Vladimir> of a class, so it can keep some state. I was also thinking that the
Vladimir> method returning children should actually return an interator 
Vladimir> (use yield), so that incremental fetch of children is possible.

I looked at the MI code a bit today.

I'm thinking of changing all this code to work something like this:

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

* We'll have both gdb.mi_pretty_printers and gdb.cli_pretty_printers
  to manage the mappings.

  mi_pretty_printers will map a regular expression to a constructor.

  cli_pretty_printers will map a regular expression either to a
  function (as now) or to an instance of an MI-style pretty-printer.
  In the latter case the glue code can apply the CLI settings ("print
  elements") as needed.  Maybe I will also add a "header" method to
  give a nice description (I've been putting these into the pretty
  printers as a way to indicate to the user that the output is
  washed.)

* We'll change -var-show-format to accept "raw" as a format.
  (This is one idea anyhow; another would be to add a new
  command... let me know what you think).
  "raw" will mean "bypass the python pretty-printer".

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

  I'm not sure what to do with things like linked lists, where
  computing the length may be expensive.  It might be nice to have a
  "return -1 if it is costly" flag.

* Allow the Python 'children' method to return an iterator.

* Make it possible to list a subset of the children of a varobj.
  One way is to add start and end arguments to -var-list-children:

  -var-list-children [PRINT-VALUES] [--first=N] [--last=N] NAME

  I'm uncertain as to how to handle laziness in the Python code.
  I have a few concerns about this area:

  * Throttling output.  I think the above handles that ok.

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

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

  My current idea is to pass the -var-list-children starting bound to
  the Python children method.  With the iterator approach we don't
  need to pass the end index (though -- if there is a situation where
  this would plausibly be more efficient, we could).

* Handling maps.  Here I think we must extend MI.

  We could try to be semi-backward-compatible.  For example,
  -var-list-children could alternate keys and values, and we could add
  an output field indicating special treatment here.  That is:

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

  Or, we could do any number of other things.  Speak up if you have a
  preference.

  In any case, I think this needs to be built into the Python API from
  the start.  Perhaps the child iterator can return tuples of the form
  (KEY VALUE).

Tom