use of python to pretty-print STL structures, etc.

use of python to pretty-print STL structures, etc.

[Doug Evans]

Hi.  Python scripting support will eventually be added to gdb.  I'd
like to better understand folks's views on if/how Python will help
with one sore spot in gdb, namely the printing of c++ data structures
in a way that is useful to the programmer, instead of the raw dump
that is done today.

e.g. instead of

#include <string>
string s ("hello");
int main () { return 0; }

(gdb) p s
$1 = {static npos = 4294967295,
  _M_dataplus = {<std::allocator<char>> =
{<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>}, _M_p = 0x9783014 "hello"}}

and staring at the output to find what one wants, or doing "p
s._M_dataplus._M_p", programmers would often rather just do something
like "p s" and get "hello".  Similarily for vectors, etc.

As I understand it, and I'm sure you'll correct me if I'm wrong :-),
the plan is to solve this problem with the new Python scripting
support.

I realize there's no real design as of yet (at least that I'm aware
of), but my question is whether folks have thought about what it would
look like from the command line.

At a very basic level, do folks envision keeping the current cli u/i
(*1) and enhancing it to provide python-providable extensions?  Have
folks thought about how they would like the above problem to be solved
(with python or without)?

---
(*1): One can replace the implementation as desired, it's the u/i I'm
concerned with in this message.

Re: use of python to pretty-print STL structures, etc.

[Vladimir Prus]

Doug Evans wrote:

> Hi.  Python scripting support will eventually be added to gdb.  I'd
> like to better understand folks's views on if/how Python will help
> with one sore spot in gdb, namely the printing of c++ data structures
> in a way that is useful to the programmer, instead of the raw dump
> that is done today.
> 
> e.g. instead of
> 
> #include <string>
> string s ("hello");
> int main () { return 0; }
> 
> (gdb) p s
> $1 = {static npos = 4294967295,
>   _M_dataplus = {<std::allocator<char>> =
> {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
> fields>}, _M_p = 0x9783014 "hello"}}
> 
> and staring at the output to find what one wants, or doing "p
> s._M_dataplus._M_p", programmers would often rather just do something
> like "p s" and get "hello".  Similarily for vectors, etc.
> 
> As I understand it, and I'm sure you'll correct me if I'm wrong :-),
> the plan is to solve this problem with the new Python scripting
> support.
> 
> I realize there's no real design as of yet (at least that I'm aware
> of), but my question is whether folks have thought about what it would
> look like from the command line.
> 
> At a very basic level, do folks envision keeping the current cli u/i
> (*1) and enhancing it to provide python-providable extensions?  Have
> folks thought about how they would like the above problem to be solved
> (with python or without)?
> 
> ---
> (*1): One can replace the implementation as desired, it's the u/i I'm
> concerned with in this message.

As you mention, no real design exists yet. What I personally plan to try
is to implement MI support -- where one can have "smart" variable objects,
such that the list of children is computed by Python code.

For my purposes, it would be sufficient if GUI could say "use this Python"
code to compute children of this variable object (or type)".

For strings, we'd probably need to customize how a varobj is actually
converted to text, as opposed to customizing getting children, but
customizing conversion to text is easier.

Anyway, the biggest part of this project appears to be exposing all the
necessary functionality to python -- the value machinery, first of all.

- Volodya

Re: use of python to pretty-print STL structures, etc.

[Jim Blandy]

"Doug Evans" <dje at google.com> writes:
> I realize there's no real design as of yet (at least that I'm aware
> of), but my question is whether folks have thought about what it would
> look like from the command line.
>
> At a very basic level, do folks envision keeping the current cli u/i
> (*1) and enhancing it to provide python-providable extensions?  Have
> folks thought about how they would like the above problem to be solved
> (with python or without)?

My dream is to let people put a gdb-custom.py file in their source
trees, and then have GDB automatically look for that and load it if
present.  gdb-custom.py would say something like:

  def print_foo (obj):
      ... code to print a GDB value whose type is 'foo' nicely ...

  print_type_with ('foo', print_foo)

And then the fundamental GDB printing code would defer to print_foo as
needed --- whether the 'foo' appeared as the entire value of the
expression, or as a member of a structure or array.  So not only
'print' and 'display', but also 'frame', 'finish', and everything else
would use print_foo.

Since gdb-custom.py would get loaded automatically, it wouldn't take
any special effort to get GDB to print a program's values in a
meaningful way --- you'd just debug the program normally, and you'd
get appropriate representations.  People who never wanted custom
printing could put 'set python auto-load off' in their ~/.gdbinit
files.

Some format specifier, say /q, would disable all custom printing
things, so you could see what was underneath it.

The output from 'print_foo' might be wrapped in some brackets or have
a special (brief) prefix to distinguish it from ordinary GDB values.

I don't know how you'd register a handler for 'vector<T>' for all T.
Or how the printing procedure would obtain the T at hand.

Maybe you'd pass an instance of some class to print_type_with, not
just a procedure, to register a collection of operations for 'foo' all
at once, if there's something we care about beyond printing.

A winning solution would have many useful, tempting examples less than
20 lines long, so people could just get the gist of the interface and
play with it.