Pretty-printed MI vars with children get "{...}" instead of the wanted string

Pretty-printed MI vars with children get "{...}" instead of the wanted string

[Noam Yorav-Raphael]

Hello,

I sent this as a bug (
http://sourceware.org/bugzilla/show_bug.cgi?id=10616 ), but as this is
an intended behavior, Tom asked me to raise the subject on the mailing
list.

The current situation in the python branch is that if a pretty-printer
has both a to_string() method and a children() method, in MI the
to_string method is ignored and instead "{...}" is used. The result is
that in a GUI which uses gdb as a backend, a variable gets no
meaningful text near it; it looks like this:

[+] x   {...}
[+] y   {...}

Only if I open the "x" node, I see meaningful stuff:

[-] x    {...}
 |---a   1
 |---b   2
 |---c   3
 ... more fields
[+] y   {...}

I have structs with quite a few number of fields, but only a few
usually change during the running of the program and should be
constantly viewed. I wrote a pretty-printer for the struct which
returns the important fields in the to_string() method, so now the GUI
should look like this:

[+] x   a=1,b=2
[+] y   {...}

And of course I can open the "x" node if I'm interested in some other
fields. This saves a lot of screen space and lets the user focus on
the important stuff.

I also wrote a pretty-printer to display 64-bit machine words, which
are treated as a vector of 8 bytes. Thus I see in the GUI:

[+] x   1,2,3,4,5,6,7,8
[+] y   {...}

I might have to make the "locals" pane (which is located on the left
side of the screen) a bit wider, but since today's screens are quite
wide, it's not a problem.
If the to_string() method is ignored, I have to open the variable view
in order to see the bytes:

[+] x   {...}
 |---[0]   1
 |---[1]   2
 |---[2]   3
 ... 5 more lines
[+] y   {...}

Since I only have about 30 rows to view locals, using 9 of them just
to view the value of x is quite wasteful.

So, can this be changed? I'm sure there are reasons why the current
behavior was chosen, but as you see, using the to_string() method can
improve the debugging experience significantly in some situations.

Thanks,
Noam

Re: Pretty-printed MI vars with children get "{...}" instead of the wanted string

[Vladimir Prus]

Noam Yorav-Raphael wrote:

> Hello,
> 
> I sent this as a bug (
> http://sourceware.org/bugzilla/show_bug.cgi?id=10616 ), but as this is
> an intended behavior, Tom asked me to raise the subject on the mailing
> list.
> 
> The current situation in the python branch is that if a pretty-printer
> has both a to_string() method and a children() method, in MI the
> to_string method is ignored and instead "{...}" is used. The result is
> that in a GUI which uses gdb as a backend, a variable gets no
> meaningful text near it; it looks like this:
> 
> [+] x   {...}
> [+] y   {...}
> 
> Only if I open the "x" node, I see meaningful stuff:
> 
> [-] x    {...}
>  |---a   1
>  |---b   2
>  |---c   3
>  ... more fields
> [+] y   {...}
> 
> I have structs with quite a few number of fields, but only a few
> usually change during the running of the program and should be
> constantly viewed. I wrote a pretty-printer for the struct which
> returns the important fields in the to_string() method, so now the GUI
> should look like this:
> 
> [+] x   a=1,b=2
> [+] y   {...}
> 
> And of course I can open the "x" node if I'm interested in some other
> fields. This saves a lot of screen space and lets the user focus on
> the important stuff.
> 
> I also wrote a pretty-printer to display 64-bit machine words, which
> are treated as a vector of 8 bytes. Thus I see in the GUI:
> 
> [+] x   1,2,3,4,5,6,7,8
> [+] y   {...}
> 
> I might have to make the "locals" pane (which is located on the left
> side of the screen) a bit wider, but since today's screens are quite
> wide, it's not a problem.
> If the to_string() method is ignored, I have to open the variable view
> in order to see the bytes:
> 
> [+] x   {...}
>  |---[0]   1
>  |---[1]   2
>  |---[2]   3
>  ... 5 more lines
> [+] y   {...}
> 
> Since I only have about 30 rows to view locals, using 9 of them just
> to view the value of x is quite wasteful.
> 
> So, can this be changed? I'm sure there are reasons why the current
> behavior was chosen, but as you see, using the to_string() method can
> improve the debugging experience significantly in some situations.

Unfortunately, the to_string implementation for std::vector produces
huge string that makes sense for CLI, but makes no sense for MI. So, for
now we went with backward-compatible behaviour that composite values in
MI are shown as "{...}" on top-level.

While this might be possible to extend in future, I think we should stop
for 7.0. Reliable pretty-printing in frontend is hard, let's get basics
working first.

- Volodya

Re: Pretty-printed MI vars with children get "{...}" instead of the wanted string

[Noam Yorav-Raphael]

Keeping things stable is, of course, a sensible thing to do.

But I still have a question. When I do a simple "print" of an object
with a pretty-printer, I get something like:

$1 = x=0 = {
  s = {a = 0, b = 0},
  x = 0
}

That is, both the to_string() result and the children are printed. So
why should the std::vector to_string() return a large string with all
the elements in the vector, if whenever it's printed all the elements
are printed again after it?

What I'm saying is this: It seems to me that for both CLI and MI, if a
pretty-printer provides the children() method, its to_string() methods
should return a short abstract of the object's content, not the full
content. And if that is the case, there's no reason to hide the
to_string() result in MI.

What do you think?

Noam


2009/9/9 Vladimir Prus <vladimir@codesourcery.com>:
> Noam Yorav-Raphael wrote:
>
>> Hello,
>>
>> I sent this as a bug (
>> http://sourceware.org/bugzilla/show_bug.cgi?id=10616 ), but as this is
>> an intended behavior, Tom asked me to raise the subject on the mailing
>> list.
>>
>> The current situation in the python branch is that if a pretty-printer
>> has both a to_string() method and a children() method, in MI the
>> to_string method is ignored and instead "{...}" is used. The result is
>> that in a GUI which uses gdb as a backend, a variable gets no
>> meaningful text near it; it looks like this:
>>
>> [+] x   {...}
>> [+] y   {...}
>>
>> Only if I open the "x" node, I see meaningful stuff:
>>
>> [-] x    {...}
>>  |---a   1
>>  |---b   2
>>  |---c   3
>>  ... more fields
>> [+] y   {...}
>>
>> I have structs with quite a few number of fields, but only a few
>> usually change during the running of the program and should be
>> constantly viewed. I wrote a pretty-printer for the struct which
>> returns the important fields in the to_string() method, so now the GUI
>> should look like this:
>>
>> [+] x   a=1,b=2
>> [+] y   {...}
>>
>> And of course I can open the "x" node if I'm interested in some other
>> fields. This saves a lot of screen space and lets the user focus on
>> the important stuff.
>>
>> I also wrote a pretty-printer to display 64-bit machine words, which
>> are treated as a vector of 8 bytes. Thus I see in the GUI:
>>
>> [+] x   1,2,3,4,5,6,7,8
>> [+] y   {...}
>>
>> I might have to make the "locals" pane (which is located on the left
>> side of the screen) a bit wider, but since today's screens are quite
>> wide, it's not a problem.
>> If the to_string() method is ignored, I have to open the variable view
>> in order to see the bytes:
>>
>> [+] x   {...}
>>  |---[0]   1
>>  |---[1]   2
>>  |---[2]   3
>>  ... 5 more lines
>> [+] y   {...}
>>
>> Since I only have about 30 rows to view locals, using 9 of them just
>> to view the value of x is quite wasteful.
>>
>> So, can this be changed? I'm sure there are reasons why the current
>> behavior was chosen, but as you see, using the to_string() method can
>> improve the debugging experience significantly in some situations.
>
> Unfortunately, the to_string implementation for std::vector produces
> huge string that makes sense for CLI, but makes no sense for MI. So, for
> now we went with backward-compatible behaviour that composite values in
> MI are shown as "{...}" on top-level.
>
> While this might be possible to extend in future, I think we should stop
> for 7.0. Reliable pretty-printing in frontend is hard, let's get basics
> working first.
>
> - Volodya
>
>
>

Re: Pretty-printed MI vars with children get "{...}" instead of the wanted string

[Vladimir Prus]

On Wednesday 09 September 2009 Noam Yorav-Raphael wrote:

> Keeping things stable is, of course, a sensible thing to do.
> 
> But I still have a question. When I do a simple "print" of an object
> with a pretty-printer, I get something like:
> 
> $1 = x=0 = {
>   s = {a = 0, b = 0},
>   x = 0
> }
> 
> That is, both the to_string() result and the children are printed. So
> why should the std::vector to_string() return a large string with all
> the elements in the vector, if whenever it's printed all the elements
> are printed again after it?
> 
> What I'm saying is this: It seems to me that for both CLI and MI, if a
> pretty-printer provides the children() method, its to_string() methods
> should return a short abstract of the object's content, not the full
> content. And if that is the case, there's no reason to hide the
> to_string() result in MI.
> 
> What do you think?

I do not know why in the vector pretty printer produces such a long
string. Note that it does not duplicates contents, just uses too may
words to say what the size and capacity is.

- Volodya

Re: Pretty-printed MI vars with children get "{...}" instead of the wanted string

[Noam Yorav-Raphael]

Where is the code of std::vector pretty-printer? I haven't found it in
the gdb sources.
Perhaps it may be changed, so printing the to_string() result in MI
would be possible?

2009/9/9 Vladimir Prus <vladimir@codesourcery.com>:
> On Wednesday 09 September 2009 Noam Yorav-Raphael wrote:
>
>> Keeping things stable is, of course, a sensible thing to do.
>>
>> But I still have a question. When I do a simple "print" of an object
>> with a pretty-printer, I get something like:
>>
>> $1 = x=0 = {
>>   s = {a = 0, b = 0},
>>   x = 0
>> }
>>
>> That is, both the to_string() result and the children are printed. So
>> why should the std::vector to_string() return a large string with all
>> the elements in the vector, if whenever it's printed all the elements
>> are printed again after it?
>>
>> What I'm saying is this: It seems to me that for both CLI and MI, if a
>> pretty-printer provides the children() method, its to_string() methods
>> should return a short abstract of the object's content, not the full
>> content. And if that is the case, there's no reason to hide the
>> to_string() result in MI.
>>
>> What do you think?
>
> I do not know why in the vector pretty printer produces such a long
> string. Note that it does not duplicates contents, just uses too may
> words to say what the size and capacity is.
>
> - Volodya
>