Re: Python API - pretty printing complex types

[Tom Tromey <tromey at redhat dot com>]

>>>>> "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.

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.

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.

Tom