From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb@sources.redhat.com
Subject: MI & pretty-printing
Date: Mon, 13 Jul 2009 17:42:00 -0000 [thread overview]
Message-ID: <200907132142.18043.vladimir@codesourcery.com> (raw)
On IRC, Tom and I talked about best way to support Python
pretty-printing with MI. Here's my attempt at summarizing.
1. It does not seem like existing frontends can make use of
pretty-printing automatically. If frontend tries to list
children of an invalid value, GDB may just hang. If GDB
automatically limits the number of children, then existing
frontends will not be able to see the children beyond this
limit (or have GUI for that). Therefore, it is suggested than
a new MI command is used to explicitly enable pretty-printing
in MI, say
-enable-pretty-printing [0|1]
2. The FE may request a specific range of children by passing
low and high boundary:
-var-list-children varobj [low] [hi]
If no range is specified, an attempt to report all children is
made, be what may.
3. A varobj keeps a range of children to fetch on -var-update, and
a new command is added to set that range, say,
-var-set-update-range varobj low hi
The important aspect is that the range updated by -var-update is
not automatically changed by -var-list-children. This allows the
frontend to implement any update strategy it wishes, for example:
- Frontend might initially set update range to 0-10 and also
fetch first 10 children. If user wishes to see 10 children more,
frontend does -var-list-children 10 20. On next step, -var-update
updates first 10 children, the remaining ones are discarded.
- Frontend might display a part of big array, say from 1000th to 1100th
elements. User scrolls. FE does:
-var-list-children varobj 1100 1110
to fetch 10 more items, and then does
-var-set-update-range varobj 1010 1110
so that the entire view is updated on next step.
This actually seem almost same as Tom's original design, except that
-var-list-children does not automatically change the update range.
Since this is somewhat contrived area, I am not 100% sure the above is
best solution -- feedback appreciated.
- Volodya
next reply other threads:[~2009-07-13 17:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-13 17:42 Vladimir Prus [this message]
2009-07-14 1:55 ` Nick Roberts
2009-07-15 12:19 ` Vladimir Prus
2009-08-06 21:02 ` Tom Tromey
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=200907132142.18043.vladimir@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=gdb@sources.redhat.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