This is the mail archive of the
mailing list for the Archer project.
Re: pretty-printing update
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
* 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:
Or, we could do any number of other things. Speak up if you have a
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