Re: Python API - pretty printing complex types

["André Pönitz" <andre.poenitz@nokia.com>]

On Thursday 10 March 2011 22:25:20 ext Tom Tromey wrote:
> >>>>> "André" == André Pönitz <andre.poenitz@nokia.com> writes:
> 
> >> I don't know about "expansion state" it feels like it is GDBs job to
> >> manage that rather than the pretty printers themselves. 
> 
> André> I'd say it's a frontend's job to maintain the expansion state and
> André> communicate that to gdb when asking for "expanded data".
> 
> If I understand correctly, then I think the varobj stuff does this ok.
> It is the front end's choice whether to fetch varobj children, and how
> many to fetch.  Front ends do have to do a little dance to make the
> "windowing" work out right, but it isn't too bad.
>
> Also, the pretty-printer API was designed so that a printer can be
> written to compute data lazily, to avoid over-fetching.  There are still
> some wrinkles here, I think strings still don't work completely
> properly.  I think there is still a PR open about this.
> 
> I know you aren't using varobj.  We could probably expose more of the
> pretty-printer stuff to pure Python if you'd find that helpful...
> though I suspect just the existing gdb.default_visualizer is enough.

I readily believe that varobj work ok for "normal C" cases, but after spending
quite some time on a varobj based general solution (still used on Mac btw)
I came to the conclusion that either I do not understand the concept on a 
very fundamental level, or the varobj approach can conceptually not work for
"phony" data. I.e. data that is entirely artificial (like grouping of data 
members of some struct) or the result of inferior calls ("getter" style 
functions).

Unfortunately, that kind of data is a large (and the most interesting) part of
what I need to display. E.g. object properties that are formally only accessible 
by getter functions, and even if most of them are backed by real data in some
memory "somewhere", that does not have to be the case when the result is 
constructed on-the-fly. How do I create a varobj representing such a result?

What kind of mechanism makes -var-update do the "right thing", i.e. notifies
me that that the result of an inferior call "changes", i.e. possibly would need 
to be re-computed as the context leading to its original computation?

I really think this cannot work with the gdb's varobj architecture, and neither
with some incremental improvement on top of it. But as it is easy to prove me
wrong by pointing to any other gdb frontend successfully handling that use 
case that question should be answerable.

> André> It would be perfect if the pretty-printers-can-return-pretty-printers 
> André> approach would also allow to (easily) feed  the pretty printers with 
> André> per-value individual data. I found this pretty useful for "patchwork"
> André> applications, that cannot easily use global settings for everything.
> André> [In some cases you would like to do things like "display char * as
> André> Latin1, but in some cases it's UTF-8, sometimes it's a \0-separated and
> André>  \0\0-terminated 'list' of strings,  and sometimes really only a pointer
> André> to a single char". Or you have some numerical data in an array that you'd
> André> like to run through xplot as "pretty printer", but you don't want to 
> André> invoke that on every value of type std::vector<double>. Things like that.]
> 
> varobj lets you assign a printer to a specific varobj, but I'm not sure
> if anything uses this, and it probably only makes sense if there is
> prior coordination with the front end.

That might work, pushing per-item configuration data from the frontend before
'-var-update' calls or such would be ok. I am not convinced, however, it
would help. Changing the display might easily impact the child nodes (see
above example of plain Latin1 vs \0-separated and \0\0-terminated list of 
strings) and therefore the varobjs representing these nodes. I have a gut
feeling that this will cause troubles.

> Handling this via sub-pretty-printers for (e.g.) specific fields in
> known structures seems reasonable.  But I don't know a fully general way
> to handle this, like if the user wants "print some_global_string" to
> automatically know to use a different encoding.

One could do some guesswork based on the actual string data. But according
to user feedback it's sufficient to have a reasonable first approximation
(like Latin1 or the system locale) and provide options to change encoding
globally and per-item. And that's straightforward to do with the "fat script"
approach.

Andre'