From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21414 invoked by alias); 17 Nov 2006 06:25:18 -0000 Received: (qmail 21401 invoked by uid 22791); 17 Nov 2006 06:25:18 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Nov 2006 06:25:10 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Gkx9q-0005Ph-Tj for gdb-patches@sources.redhat.com; Fri, 17 Nov 2006 07:25:02 +0100 Received: from 73-198.umostel.ru ([82.179.73.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 07:25:02 +0100 Received: from ghost by 73-198.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 07:25:02 +0100 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: MI: frozen variable objects Date: Fri, 17 Nov 2006 06:25:00 -0000 Message-ID: References: <17756.56523.353271.828046@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.2 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00160.txt.bz2 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