Re: kudos and suggestions

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Graydon" == Graydon Hoare <graydon@pobox.com> writes:

Graydon> So "pretty printing" is only a summary of what I want; what I
Graydon> *really* want is the ability to have "a hook of my choice" perform the
Graydon> task of "child enumeration" to multiple parts of gdb.

Graydon> For example, if I register a hook on a type T, I want a value v of
Graydon> type T to pretty-print of course, but I also want it to be true that
Graydon> the keyboard sequence "v.<tab>" calls my hook to analyze v, and
Graydon> returns the child-value list from the analysis for my tab-completion
Graydon> prompt, and if child "foo" was in that list, then the keyboard
Graydon> sequence "v.foo" asks my hook for the foo'th child of v, and so forth.

Yeah, that would be nice.

At first blush, it seems too complicated for the near term.  I think
it would mean hooking into the expression code.  While I plan to write
a Python interface to that, I haven't done so yet.

For the field case, for C and C++, just having an expression rewriting
step, plus a hook into the completer, would probably be enough for
this.  That's because C field analysis is not done in the expression
parser -- it just writes out a field lookup operator without looking
to see whether it makes sense.

For other languages, or other syntactical changes, it might be harder.

Graydon>   - Separate hooks for pretty-printing a node in "summary" and "full"
Graydon>     modes.

I've been hoping we could stick with a relatively simple API, like we
have now, and let gdb make some of the formatting decisions for the
CLI.  E.g., we do this for "set print pretty"... I thought we did it
for "set print array elements", but apparently this isn't implemented.

Anyway the idea is that the "printers" can be fairly dumb about
actually printing -- we can let them just return bits, and let gdb
take care of its many options.

For this to be efficient, some printers have to be written to lazily
compute children.  But, that is probably a good idea anyway.


I'll look at the summary idea, though.  I do think we need to do
something here.  I've also been thinking that we need an "array"
display_hint, so that gdb can apply its various array-printing
parameters.

Graydon>   - The ability, as suggested earlier, to ask gdb to take over and
Graydon>     "do what it would normally do, to this value" at any point.

The documentation is wrong here.  The printer's to_string method can
actually return any number of things, not just a string.  If it
returns an instance of Value, that is printed using gdb's machinery.
If it returns some Python value that is convertible to Value, then the
conversion is done and the result is printed.

Is this sufficient for your needs?

Graydon>   int(v.cast(gdb.Type('uint8_t')))

In case you're not following the list, I checked in a fix for this
yesterday.  Now int(v) and long(v) will work.

Tom