From: Vladimir Prus <ghost@cs.msu.su>
To: gdb-patches@sources.redhat.com
Subject: Re: MI: frozen variable objects
Date: Fri, 17 Nov 2006 06:25:00 -0000 [thread overview]
Message-ID: <ejjkao$lbq$1@sea.gmane.org> (raw)
In-Reply-To: <17756.56523.353271.828046@kahikatea.snap.net.nz>
Nick Roberts wrote:
>
>> This patch introduces so called "frozen" variable objects -- variable
>> objects that are not implicitly updated by the "-var-update *" command or
>> by "-var-update" on parent variable objects.
>
> This explains your previous patch (Variable objects laziness):
>
> + We do this for frozen varobjs as well, since this
> + function is only called when it's decided that we need
> + to fetch the new value of a frozen variable. */
>
> I've not experienced a need for such functionality probably because my
> Emacs
> mode is still unreleased and therefore has a very small user base. Since
> you and Daniel J see that it is needed (through Eclipse?) it seems
> sensible to install a patch like this (and the earlier one, which I do
> understand now - perhaps the ChangeLog could say "Use install_new_value
> instead of
> gdb_value_fetch_lazy"). However, I would just suggest that these changes
> are
> made shortly after the release of GDB 6.6. That way there is time test
> them with frontends that might be using GDB/MI while GDB is still in CVS.
I don't have a strong opinion here, but it seems to me that frontend authors
are much better testing branch before it's realeased than random CVS state,
since frontends will typically work with released GDB.
And then, it's not much different if this change will be tested when it's on
6.6 branch than when it's on 6.7 branch.
- Volodya
next prev parent reply other threads:[~2006-11-17 6:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-16 21:53 Nick Roberts
2006-11-16 22:00 ` Daniel Jacobowitz
2006-11-16 23:07 ` Nick Roberts
2006-11-17 15:19 ` Daniel Jacobowitz
2006-11-17 20:52 ` Nick Roberts
2006-11-17 21:05 ` Daniel Jacobowitz
2006-11-17 23:12 ` Nick Roberts
2006-11-18 11:00 ` Eli Zaretskii
2006-11-17 6:25 ` Vladimir Prus [this message]
2006-11-17 18:14 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2006-11-18 6:59 Nick Roberts
2006-11-16 12:48 Vladimir Prus
2006-11-16 13:58 ` Greg Watson
2006-11-16 15:25 ` Frederic RISS
2006-11-16 15:55 ` Daniel Jacobowitz
2006-11-16 16:26 ` Frederic RISS
2006-11-16 16:34 ` Daniel Jacobowitz
2006-11-17 15:21 ` Greg Watson
2006-11-16 18:55 ` Vladimir Prus
2006-11-16 21:36 ` Frédéric Riss
2006-11-17 6:17 ` Vladimir Prus
2006-11-17 8:54 ` Frederic RISS
2006-11-16 18:47 ` Vladimir Prus
2006-11-17 15:09 ` Greg Watson
2006-11-17 15:15 ` Daniel Jacobowitz
2006-11-17 15:26 ` Greg Watson
2006-11-17 15:33 ` Daniel Jacobowitz
2006-11-17 15:41 ` Greg Watson
2006-11-17 15:45 ` Daniel Jacobowitz
2006-11-17 18:16 ` Daniel Jacobowitz
2006-11-17 15:35 ` Greg Watson
2006-11-17 15:27 ` 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='ejjkao$lbq$1@sea.gmane.org' \
--to=ghost@cs.msu.su \
--cc=gdb-patches@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