From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14299 invoked by alias); 15 Jul 2005 22:37:17 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14230 invoked by uid 22791); 15 Jul 2005 22:37:11 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 15 Jul 2005 22:37:11 +0000 Received: from farnswood.snap.net.nz (p44-tnt1.snap.net.nz [202.124.110.44]) by viper.snap.net.nz (Postfix) with ESMTP id 805FD5F7445; Sat, 16 Jul 2005 10:37:07 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 434A362A99; Fri, 15 Jul 2005 23:39:22 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17112.15129.400036.830436@farnswood.snap.net.nz> Date: Fri, 15 Jul 2005 22:37:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH: gdb/mi + doco] -var-update In-Reply-To: <20050715152840.GA20960@nevyn.them.org> References: <20050617140410.GA24575@nevyn.them.org> <20050703195630.GM13811@nevyn.them.org> <20050704050151.GA8321@nevyn.them.org> <17099.44050.219050.156429@farnswood.snap.net.nz> <20050715014341.GA23331@nevyn.them.org> <17111.13428.966975.183852@farnswood.snap.net.nz> <20050715041538.GA29817@nevyn.them.org> <17111.53825.9630.703339@farnswood.snap.net.nz> <20050715152840.GA20960@nevyn.them.org> X-SW-Source: 2005-07/txt/msg00138.txt.bz2 Daniel Jacobowitz writes: > On Sat, Jul 16, 2005 at 03:12:00AM +1200, Nick Roberts wrote: > > > BTW, if it's OK with you, I would prefer that you add new testcases > > > rather than modifying existing ones. Yes, the ones that are there are > > > slightly redundant. But changing what a test case is testing is bad > > > form for long-term results analysis. > > > > OK. I'm not very comfortable with expect, but I'll give it a go. > > I have learned a frightening (to me anyway) amount about expect and TCL > lately; bug me with any questions you may have. Thanks. > > > Now that this patch is in, I believe your current gdb-mi.el will work > > > with CVS GDB. Is that right? If so, could you post it? I promise to > > > look at it promptly. > > > > Yes it does work, but not perfectly (if it did it could go straight into > > the Emacs CVS repository). It has changed quite a lot since last time. > > Unfortunately it still requires Emacs in CVS, but a release is planned. > > Confused - I thought we'd decided it belonged with GDB, not with > emacs, because of the GDB version dependencies? The eventual aim is to move it to Emacs CVS. While MI and gdb-mi.el are changing , GDB CVS seems a good place for it. You're right though, since it currently requires MI features that are only in GDB CVS, it wouldn't make sense to move it to Emacs CVS yet. > I won't try to second-guess you about this code - my LISP sucks. But > could you explain briefly why you changed from -break-insert to "break" > in some places? Yet at the same time changed from until to > -exec-until... I changed "until" to -exec-until as it's an MI command. I changed -break-insert back to "break" because the output from -break-insert spills into the GUD buffer. Clearly the proper solution is to handle the output of -break-insert, but I haven't got that far yet. I don't know how important that is because gdb-mi.el will always have to be able to handle CLI user input from the GUD buffer anyway. > Anyway, go ahead and check this in. Committed. Thanks. Nick