From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org
Cc: "André Pönitz" <andre.poenitz@nokia.com>
Subject: Re: Python API - nested pretty printers MI implications
Date: Mon, 15 Aug 2011 13:26:00 -0000 [thread overview]
Message-ID: <201108151425.48364.pedro@codesourcery.com> (raw)
In-Reply-To: <201108151436.50248.andre.poenitz@nokia.com>
On Monday 15 August 2011 13:36:50, André Pönitz wrote:
> I am not sure how partial updates on MI varobjs with phony levels
> would work at all.
>
> Imagine a data structure containing a char m[1000000][10], and a
> "phony level pretty printer" that displays all the m[i] with m[i][0] == 'A'.
> Suppose initially that would be the items m[1] and m[10000], so we
> get a display like
>
> m --
> m[1] "A...."
> m[1000] "A...."
>
> Now the user steps over m[5000][0] = 'A'. Assuming there is no dummy
> varobj for every _potential_ child, what mechanism would trigger the
> varobj's update to produce the display
>
> m --
> m[1] "A...."
> m[5000] "A...."
> m[10000] "A...."
>
> eventually?
AFAIK, frontends do:
-var-update 2 *
and that should yield (but doesn't):
^done,changelist=[{name="var1.m",value="",in_scope="true",type_changed="false",new_num_children="1",has_more="0",new_children=[{name="var1.m.5000",exp="5000",numchild="1",value="A....",type="foo"}]}]
(gdb)
Note new_num_children. This should trigger the frontend re-fetching
the children of var1.m.
I think the issue here is that dynamic varobj's code doesn't
handle new children appearing before existing ones. I got a
patch to address that though, needed for supporting varobj's
that hide "<unavailable>" children.
--
Pedro Alves
next prev parent reply other threads:[~2011-08-15 13:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-14 16:11 Andrew Oakley
2011-08-14 22:18 ` Daniel Jacobowitz
2011-08-15 12:36 ` André Pönitz
2011-08-15 13:26 ` Pedro Alves [this message]
2011-08-15 14:33 ` André Pönitz
2011-08-15 14:49 ` Pedro Alves
2011-08-15 15:36 ` André Pönitz
2011-08-16 22:12 ` Andrew Oakley
2011-08-16 22:23 ` [PATCH] Allow nested python pretty printers andrew
2011-08-17 9:56 ` Phil Muldoon
2011-08-17 13:28 ` Andrew Oakley
2011-08-15 12:58 ` Python API - nested pretty printers MI implications Pedro Alves
2011-08-15 14:06 ` Andrew Oakley
2011-08-15 14:30 ` Pedro Alves
2011-08-16 22:12 ` Andrew Oakley
2011-08-17 12:49 ` Pedro Alves
2011-08-17 18:31 ` Andrew Oakley
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=201108151425.48364.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=andre.poenitz@nokia.com \
--cc=gdb@sourceware.org \
/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