This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: pretty-printing update
On Wednesday 01 October 2008 21:19:39 Tom Tromey wrote:
> >>>>> "AndrÃ" == Andrà PÃnitz <apoenitz@trolltech.com> writes:
>
> AndrÃ> For a "machine" interface, something more structured (and more
> AndrÃ> robust to parse) would be needed anyway.
>
> We talked about this at the meeting.
Ah ;-)
> In my email I didn't mention it, but there is already code on the
> python branch to handle pretty-printing for MI. This code works in a
> somewhat different way than the CLI pretty-printing I've implemented.
>
> One thing on my to-do list is to look at unifying the two. It would
> be nice for library authors (e.g.) to be able to write a single class
> for printing a type and have it work in all cases.
>
> Currently I think this will involve changes to both cases.
>
> Right now the MI code relies on the MI consumer (GUI or whatever) to
> sent "var-set-format" with the name of a type and the name of a
> formatter class.
>
> I think it would be fine to keep this, but I'd prefer the default
> setup to be less client-specific.
Well, I feel the opposite. See below.
> Instead I think the print class
> should be specified by python code, and this should (typically) happen
> when an objfile is opened.
>
> That is: user program loads libstdc++, gdb looks in libstdc++ install
> directory (or separate debug info directory) for python code, then
> that python code registers printers.
But from a GUI point of view there is not really much difference whether gdb
automatically looks in certain places for custom formatters or whether it has
to pump a few hundred lines of "-var-set-format" into gdb "manually".
Actually I would argue that the formatter code is pretty likely to depend
more on the actual GUI than on the type (even with changing libstdc++
in mind). In the example I gave there are fields like "name" and
"valueencoded" that will probably only make sense to a very specific GUI.
So if these values are produced by the "installed" formatters, all but one
consumer will get a bunch of information they consider useless. If, on the
other hand, the values are not produced or only available by additional
means one GUI will be unhappy.
But since you aim for both approaches I'd guess there's nothing to
complain about ;-)
Andre'
PS: Thanks for your effort.