Re: Python API - pretty printing complex types

[André Pönitz <andre dot poenitz at nokia dot com>]

On Wednesday 09 March 2011 20:30:51 ext Andrew Oakley wrote:
> n Wed, 09 Mar 2011 09:07:09 +0100
> Joachim Protze <joachim.protze@wh2.tu-dresden.de> wrote:
> 
> > My first approach makes use of the undocumented (online-doc) 
> > array-method of gdb.Type, that i put in a handy function -- the
> > straight forward way.
> 
> OK, I was looking for that but couldn't find a way to do it.  I see
> this is now documented which is nice.  It still doesn't handle more
> complex cases though.
> 
> On Wed, 9 Mar 2011 09:54:49 +0100
> André Pönitz <andre.poenitz@nokia.com> wrote:
> 
> > On Wednesday 09 March 2011 01:46:19 ext Andrew Oakley wrote:
> > > [...] If API improvements are needed to do this I can have a go at 
> > > writing the code (the current src/gdb/python code seems fairly 
> > > easy to understand).
> > 
> > My 2 ct: The most dearly missing feature in the "official" pretty
> > printer API is the possibility to create multi-level displays with
> > "phony groups" and a flexible way to steer the "expansion state" of
> > such groups.
> 
> I don't know about "expansion state" it feels like it is GDBs job to
> manage that rather than the pretty printers themselves. 

I'd say it's a frontend's job to maintain the expansion state and
communicate that to gdb when asking for "expanded data".

 > I think it would be nice to be able to return pretty printers from the
> children iterator of another pretty printer. This would allow "phony
> groups" to be created - simply return another pretty printer for the
> group and it will get printed in the usual fashion.  

That's perhaps an possibility. Right now I feed a few parameters like
expansion state and individual formating requests to a fat script that
creates the full visible hierarchy in one go. That "naturally" solves the 
"phony group" issue, as each dumper can create as many level as
it wishes, and allows for the omission of repeated data (like type of
child nodes in a std::vector etc).

> I'm not sure what the best way to go about this is.  The problem is
> finding out if the value returned should be handled as a pretty printer
> or if it was something else.  I don't code much in python so I don't
> really know what the usual API conventions are.  These are the options
> I've thought of:
> 
> 1. Use a different display_hint if pretty printers will be returned.
> This is awkward if some of the children are simple types and some are
> more complicated.  I'm not sure how it would interact with GDB/MI.

> 2. Create a new base class that pretty printers inherit from.  This
> doesn't really feel like "the python way" - duck typing seems to be
> common.  

[I haven't done any python before using python with gdb, but duck 
typing certainly feels natural here]

> 3. Assume that objects that are not gdb.Value instances are pretty
> printers.  This prevents any further extensions from working in the
> same way.
> 
> 4. Assume that objects with a to_string member are pretty printers.
> This is the only required member of pretty printers and seems more in
> line with other python libraries.  We probably want to check for this
> after checking if the object was a gdb.Value, both for performance
> reasons and to ensure no existing code has an nasty surprises.
> 
> I think option 4 is the best choice here and I'm happy to write a patch
> to do this if there is some agreement that it is a reasonable decision
> (and therefore might actually get committed).  

It certainly looks like a step into the right direction. The missing "phony
levels" effectively prevented me from using the "official" pretty printing
approach in the past. 

It would be perfect if the pretty-printers-can-return-pretty-printers 
approach would also allow to (easily) feed  the pretty printers with 
per-value individual data. I found this pretty useful for "patchwork"
applications, that cannot easily use global settings for everything.
[In some cases you would like to do things like "display char * as
Latin1, but in some cases it's UTF-8, sometimes it's a \0-separated and
 \0\0-terminated 'list' of strings,  and sometimes really only a pointer
to a single char". Or you have some numerical data in an array that you'd
like to run through xplot as "pretty printer", but you don't want to 
invoke that on every value of type std::vector<double>. Things like that.]

Andre'