From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30377 invoked by alias); 6 Oct 2004 17:21:42 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 30237 invoked from network); 6 Oct 2004 17:21:39 -0000 Received: from unknown (HELO lakermmtao08.cox.net) (68.230.240.31) by sourceware.org with SMTP; 6 Oct 2004 17:21:39 -0000 Received: from white ([68.9.64.121]) by lakermmtao08.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041006172139.EUWX27830.lakermmtao08.cox.net@white>; Wed, 6 Oct 2004 13:21:39 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFFTu-0003Hf-00; Wed, 06 Oct 2004 13:21:38 -0400 Date: Wed, 06 Oct 2004 17:24:00 -0000 From: 'Bob Rossi' To: Dave Korn Cc: 'Eli Zaretskii' , gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041006172138.GI12213@white> Mail-Followup-To: Dave Korn , 'Eli Zaretskii' , gdb@sources.redhat.com References: <20041006170513.GG12213@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00151.txt.bz2 On Wed, Oct 06, 2004 at 06:14:49PM +0100, Dave Korn wrote: > > -----Original Message----- > > From: 'Bob Rossi' > > Sent: 06 October 2004 18:05 > > > Sorry if I was rude here, I am very frustrated. > > It shows. But seriously, if you have to keep on saying the same thing > over and over again, we're not disagreeing with you just to be contrary, > it's because either _we_ haven't understood the problem, or because _you_ > haven't understood the solutions we've proposed. At that point, there's a > communication difficulty going on, which will not be resolved by simply > repeating the same description over and over getting more angry each time. Understood. > > No one has attempted to do what I am trying to do. Write a front end > > that is capable of working with different GDB's. > > > > If they do do this, I would like to know how they negotiate the MI > > version to talk. > > > > Again, you seem to be saying that if I generate a parser off of the MI > > output syntax, that I am somehow wrong. > > No, that's not what I'm saying. I fully accept that you have to know what > version to deal with in order to invoke the correct full parser, and I fully > accept that while in general newer versions are supersets there are also > genuine backwards-incompatibilities that would require different parsing. > It's entirely proper to generate a parser from the MI output syntax. > > The only thing I'm disagreeing is your assumption that there's no way of > determining which MI version to talk without using a full MI parser. You > can do it MUCH more simply than that. That's the point which people keep on > having to repeat to you each time you repeat your description of the > problem, because while everyone understands the initial problem, nobody sees > what's wrong with the solutions that have been proposed so far. You are the first person so far that has pointed out directly to me that you understand the problem I am describing. > > Is this the general feel of the community? > > Well, it's not what I feel, as I hope I've explained patiently above. I > wouldn't care to speak for the community at large, but I would be surprised > if anyone else felt that it was wrong to generate a parser from the MI > output syntax. What I feel is wrong is your assumption that a generated > parser is the only possible means of processing plain ascii human readable > text for the purpose of finding and extracting a single integer value. I guess the bottom line is, I already have a parser that is capable of dealing with a specific version of MI's output. I don't want to start up MI with an adhoc parser, just to figure out what real parser I should use. This seems not correct to me, and I guess it's the issue to deal with. The problem is, we would be adding a command to the MI function set that would not be able to be parsed and understood with an MI parser. This seems really wrong to me. It's probably the issue we should be discussing. Thanks, Bob Rossi