This is the mail archive of the
mailing list for the Archer project.
Re: pretty-printing update
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: archer at sourceware dot org
- Date: Fri, 10 Oct 2008 18:54:56 +0400
- Subject: Re: pretty-printing update
- Organization: CodeSourcery
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On Tuesday 07 October 2008 04:44:13 Tom Tromey wrote:
> 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.
I think it's already done, no?
> * 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
So, in other words, you suggest to move the type->formatter mapping
from GDB (as it is in my patch) core to Python? I guess it's probably
> * 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".
Right now you can set any formatter on a variable object, or set it
to none. It seems to be useful thing to me, for example, it allows
IDE user to click on a field called "next" and say
"show list chained on next", and IDE will install formatter to do
so, without necessary making all objects of the same type be formatted
as list. It might be a good idea to defer this, but it already works :-)
> * -var-info-num-children will dispatch to Python as well.
> I think we can just call len(object) here.
Doesn't it work this way already?
> 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.
Iterators will handle this just fine.
> * 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.
Well, in my code varobj code gets values from Python code, and stores
them, and those don't change until -var-update.
> 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).
With the iterator approach we don't need to pass the starting bound, either.
> * 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:
> -var-list-children var
> Or, we could do any number of other things. Speak up if you have a
I think the above output is just not backward compatible at all. I suggest
just outputting children as plain list, key and values interleaved, and
adding a new field with display hint. For display hint of 'map', frontend
would be expected to display the linear list of children as map.