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

[Noam Yorav-Raphael <noamraph at gmail dot com>]

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