* Pretty-printed MI vars with children get "{...}" instead of the wanted string
@ 2009-09-09 7:21 Noam Yorav-Raphael
2009-09-09 7:57 ` Vladimir Prus
0 siblings, 1 reply; 5+ messages in thread
From: Noam Yorav-Raphael @ 2009-09-09 7:21 UTC (permalink / raw)
To: archer
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Pretty-printed MI vars with children get "{...}" instead of the wanted string
2009-09-09 7:21 Pretty-printed MI vars with children get "{...}" instead of the wanted string Noam Yorav-Raphael
@ 2009-09-09 7:57 ` Vladimir Prus
2009-09-09 10:43 ` Noam Yorav-Raphael
0 siblings, 1 reply; 5+ messages in thread
From: Vladimir Prus @ 2009-09-09 7:57 UTC (permalink / raw)
To: archer
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Pretty-printed MI vars with children get "{...}" instead of the wanted string
2009-09-09 7:57 ` Vladimir Prus
@ 2009-09-09 10:43 ` Noam Yorav-Raphael
2009-09-09 12:40 ` Vladimir Prus
0 siblings, 1 reply; 5+ messages in thread
From: Noam Yorav-Raphael @ 2009-09-09 10:43 UTC (permalink / raw)
To: Vladimir Prus; +Cc: archer
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
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Pretty-printed MI vars with children get "{...}" instead of the wanted string
2009-09-09 10:43 ` Noam Yorav-Raphael
@ 2009-09-09 12:40 ` Vladimir Prus
2009-09-09 21:54 ` Noam Yorav-Raphael
0 siblings, 1 reply; 5+ messages in thread
From: Vladimir Prus @ 2009-09-09 12:40 UTC (permalink / raw)
To: Noam Yorav-Raphael; +Cc: archer
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Pretty-printed MI vars with children get "{...}" instead of the wanted string
2009-09-09 12:40 ` Vladimir Prus
@ 2009-09-09 21:54 ` Noam Yorav-Raphael
0 siblings, 0 replies; 5+ messages in thread
From: Noam Yorav-Raphael @ 2009-09-09 21:54 UTC (permalink / raw)
To: Vladimir Prus; +Cc: archer
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-09-09 21:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-09 7:21 Pretty-printed MI vars with children get "{...}" instead of the wanted string Noam Yorav-Raphael
2009-09-09 7:57 ` Vladimir Prus
2009-09-09 10:43 ` Noam Yorav-Raphael
2009-09-09 12:40 ` Vladimir Prus
2009-09-09 21:54 ` Noam Yorav-Raphael
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).