From: Tom Tromey <tromey@redhat.com>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb@sources.redhat.com
Subject: Re: MI & pretty-printing
Date: Thu, 06 Aug 2009 21:02:00 -0000 [thread overview]
Message-ID: <m3iqh0fyg0.fsf@fleche.redhat.com> (raw)
In-Reply-To: <200907132142.18043.vladimir@codesourcery.com> (Vladimir Prus's message of "Mon\, 13 Jul 2009 21\:42\:17 +0400")
>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
Volodya> On IRC, Tom and I talked about best way to support Python
Volodya> pretty-printing with MI. Here's my attempt at summarizing.
I finally finished the first draft of this. I pushed it to the
archer-tromey-python branch today. Please give it a try; if it is all
looking ok I will extract it and push it into CVS.
Volodya> -enable-pretty-printing [0|1]
I omitted the argument in my implementation.
I didn't see a benefit to letting MI clients disable pretty-printing
globally. They can do it per-varobj, or simply not send this command in
the first place. (If we did allow this, then we'd have to define what
it meant for existing varobjs with printers installed.)
Volodya> -var-list-children varobj [low] [hi]
Volodya> -var-set-update-range varobj low hi
I implemented these verbatim.
There is now an optional has_more attribute on varobj output; it is a
boolean which is "1" if there seem to be children past the last
requested child.
The "numchild" attribute is now a bit funny. It can't tell the actual
number of children, only the number you've requested. It may be smaller
than the range you requested. The user has to pay attention to this,
because it is the only way to notice that children were deleted (for
-var-update, this will show up in new_num_children).
When doing a -var-update, a dynamic varobj may report "new_children".
This is a list of any new children added during this update. New
children can only be added at the end of the update range (changes to
existing elements are reported as changed varobjs).
I haven't documented all these details yet. I'll do that soon.
(FWIW, -var-update seems under-documented in general.)
Tom
next prev parent reply other threads:[~2009-08-06 21:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-13 17:42 Vladimir Prus
2009-07-14 1:55 ` Nick Roberts
2009-07-15 12:19 ` Vladimir Prus
2009-08-06 21:02 ` Tom Tromey [this message]
2009-08-07 5:18 ` Vladimir Prus
2009-08-15 20:43 ` Vladimir Prus
2009-08-17 18:48 ` Tom Tromey
2009-08-18 7:19 ` Vladimir Prus
2009-08-18 18:41 ` Tom Tromey
2009-08-19 6:51 ` Vladimir Prus
2009-08-19 19:50 ` Tom Tromey
2009-08-20 6:04 ` Vladimir Prus
2009-09-05 9:27 ` Vladimir Prus
2009-09-09 22:34 ` Tom Tromey
2009-09-14 11:19 ` Vladimir Prus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3iqh0fyg0.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=vladimir@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox