Re: pretty-printing update

[André Pönitz <apoenitz at trolltech dot com>]

On Friday 03 October 2008 20:25:43 Tom Tromey wrote:
> >>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:
> [...]
> That would let library authors implement an MI class and then define
> the CLI function simply, something like:
> 
>     gdb.pretty_printers[regex] = gdb.functionify_mi_class (class)
> 
> I haven't experimented in this area at all yet, this is just a random
> idea I had yesterday.
> 
> Vladimir> Returning children values, as
> Vladimir> opposed to some string names, is very desirable for
> Vladimir> MI. OTOH, there's no support to specify names for children,
> Vladimir> they are just numbered. Also, for std::map, you probably
> Vladimir> would want to return pairs of values and GUI should
> Vladimir> understand that mapping is been displayed, I don't know how
> Vladimir> to communicate this.
> 
> Can't a std::map expose its children as std::pair objects?

It could, but assuming that a std::pair would expand to (at least)
two or three items on screen (pair as 'container', first, second)
that's not the way people want to have it displayed in case of
'simple' values - they rather want a table-like layout then. [2]

> Then we'd recursively apply smart MI printing and expose the children
> of the std::pair.

Urm... I have the feeling this is going to place too much of the 
'business logic' that decides what to print, to what detail and
in what format on the gdb side, leading to a generic solution
that will not scale well to different, possibly even structurally
different  'output consumers'. [1]

For the case in question: If the keys of the std::map are sufficiently
simple a display like 

 [+] map      std::map<int, std::string>
  |-  2       "hello"
  `- 42      "world"

seems to be prefered. If not, it should be rather something like

 [+] map      std::map<Foo, Bar>
  |-  [-]           [key 1]        Foo
  |-  [-]           [value 1]     Bar
  |-  [-]           [key 2]        Foo
  `-  [-]           [value 2]     Bar

with the possibility to have a "data preview" in the second column
and to expand individual map keys or values by clicking on the [-].

The decision what is "sufficiently simple" does not only depend on
the types involved, but also on e.g. the available space on screen,
which in turn might depend on the nesting level or such. So every
brute force mapping from type-and-object-address to a "pretty
string" is most likely not general enough for potential consumers.
In the end it's basically the consumer deciding what data it wants
to see.

When I think about it, one way this can be solved without using 
consumer-specific pretty printers would be to feed the pretty 
printers with some kind of format string, or "response template"
that gets filled in by the prettyprinter.

At least recursion into children should only happen if the gui 
explicitly asks for it, and that's only really useful on a per-item base.
 
Andre'

[1] Pretty much the same way that MI variables don't work for me:
They are simply "too magic". All I want is to have 50 lines worth 
of data to fill some tree view. I am perfectly happy with piping 50
simple command into gdb for that, but getting an unpredicatable
amount of data for a simple -var-list-children (in case that's a, say,
array of  10000 std::string) is poison of 'consumer responsiveness'.

[2] 'they' and 'people' in this case is not 'me'...