This is the mail archive of the
mailing list for the Archer project.
Re: pretty-printing update
- From: Tom Tromey <tromey at redhat dot com>
- To: AndrÃ PÃnitz <apoenitz at trolltech dot com>
- Cc: archer at sourceware dot org
- Date: Wed, 01 Oct 2008 13:19:39 -0600
- Subject: Re: pretty-printing update
- References: <email@example.com><firstname.lastname@example.org>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "AndrÃ" == AndrÃ PÃnitz <email@example.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.
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
I think it would be fine to keep this, but I'd prefer the default
setup to be less client-specific. 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.
The CLI code will have to change to use these printer objects instead
of functions as it currently does.