From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11061 invoked by alias); 3 Jul 2005 16:45:02 -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 11007 invoked by uid 22791); 3 Jul 2005 16:44:59 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 03 Jul 2005 16:44:59 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1Dp7aU-0003lk-9c for gdb-patches@sources.redhat.com; Sun, 03 Jul 2005 12:44:58 -0400 Date: Sun, 03 Jul 2005 16:45:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Hooks still needed for annotations Message-ID: <20050703164458.GC13811@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20050601113004.GC15414@white> <17054.10607.109160.333076@farnswood.snap.net.nz> <20050603190856.GB32722@nevyn.them.org> <17056.56022.36723.292491@farnswood.snap.net.nz> <20050603235923.GA9992@nevyn.them.org> <20050604130228.GA24976@white> <20050613031400.GF9288@nevyn.them.org> <20050615155248.GC20778@white> <20050615160749.GA17626@nevyn.them.org> <20050615163147.GD20778@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050615163147.GD20778@white> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00020.txt.bz2 On Wed, Jun 15, 2005 at 12:31:47PM -0400, Bob Rossi wrote: > Well, I already have planned a way to translate the parse tree into Tcl. > I am going to walk the parse tree and then build up a Native Tcl parse > tree using callbacks. By doing this, I can write testcase's in Tcl using > the parse tree. This would really allow for a much higher level of testing. > The ADA developers could use the exact same approach and it would be much > more trivial for them to do so. > > I'm getting a vibe from you that you think writing a parser could be a > bad idea. Do you really think that the community wouldn't embrace such a > parser? The whole reason I decided to create it (or at least in the > works) is because I was frustrated with the thought of writing yet > another low level parser to parse the MI. I just wanted one that worked, > and worked well. Even more than that, I wanted one that I didn't have to > constantly maintain. I mean, Nick and I are already going to create > two different parsers. As things evolve, and the parser's need to work > with old versions of GDB, different bugs will pop up in each. I think > this hurts GDB in the long run. I also firmly think that the > only possible way to get a stable MI parser is to test it in GDB's > testsuite. In GDB's testsuite it tests against the current versions of GDB, so obviously if you want it to work with old GDBs then that isn't enough testing to be useful. I don't much care whether you write a reusable parser or not. I'm skeptical that it should be maintained as a part of the GDB distribution, with the intention for other projects to import it from GDB. If it's part of GDB, then it's going to be GPL, which will restrict its use. If it's not part of GDB, then GDB developers aren't going to update it. Pick your poison... I don't know which I think would be a better idea, yet. I haven't thought about it much. -- Daniel Jacobowitz CodeSourcery, LLC