From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24895 invoked by alias); 9 Sep 2009 07:21:15 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 24797 invoked by uid 22791); 9 Sep 2009 07:21:13 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Date: Wed, 09 Sep 2009 07:21:00 -0000 Message-ID: Subject: Pretty-printed MI vars with children get "{...}" instead of the wanted string From: Noam Yorav-Raphael To: archer Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2009-q3/txt/msg00190.txt.bz2 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