From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21152 invoked by alias); 16 Nov 2006 23:07:41 -0000 Received: (qmail 21143 invoked by uid 22791); 16 Nov 2006 23:07:39 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Nov 2006 23:07:33 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-197.snap.net.nz [202.124.125.197]) by viper.snap.net.nz (Postfix) with ESMTP id 5025D3D9CEE; Fri, 17 Nov 2006 12:07:57 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id A994FBE43D; Fri, 17 Nov 2006 12:03:32 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17756.60994.909354.46765@kahikatea.snap.net.nz> Date: Thu, 16 Nov 2006 23:07:00 -0000 To: Daniel Jacobowitz Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: MI: frozen variable objects In-Reply-To: <20061116220029.GA28461@nevyn.them.org> References: <17756.56523.353271.828046@kahikatea.snap.net.nz> <20061116220029.GA28461@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.90.14 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/msg00154.txt.bz2 > > 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. > Do you think this would do any good? AFAICS the first change (Variable objects laziness) is optimisation of existing behaviour. It looks sound to me overall but, with the many conditionals, could easily introduce new bugs. I see no urgency and as I don't have a deep understanding of all the details the only way I can really check it is to use it within Emacs. Maybe the second change is safer as it is a new feature, although it could still clearly impact on existing behaviour. > As far as I know, you and Vlad > are the only people who ever test GDB/MI from CVS with frontends. Alan Magloire has also said to me that he will check changes to MI with Eclipse but I don't know how that relates to your interest in Eclipse. > I'm not particularly inclined to wait, since none of this will show up > unless your target / IDE specifically try to use it, but I'm sure I > could be persuaded. If existing behaviour is broken it _should_ show up. A six month release cycle doesn't seem long to wait especially coming from Emacs whose last mainline release was Oct 2001 (GDB 5.3 was current when I started!). Maybe there is another agenda with Emacs, I don't know, but presumably it will be released one day and I would like it to work with current GDB when it is. -- Nick http://www.inet.net.nz/~nickrob