This is the mail archive of the
mailing list for the Archer project.
Re: pretty-printing update
- From: André Pönitz <apoenitz at trolltech dot com>
- To: archer at sourceware dot org
- Date: Mon, 6 Oct 2008 16:20:17 +0200
- Subject: Re: pretty-printing update
- Organization: Trolltech GmbH
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com>
On Friday 03 October 2008 20:25:43 Tom Tromey wrote:
> >>>>> "Vladimir" == Vladimir Prus <firstname.lastname@example.org> 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. 
> 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'. 
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
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.
 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'.
 'they' and 'people' in this case is not 'me'...