From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28265 invoked by alias); 6 Oct 2004 17:00:20 -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 28211 invoked from network); 6 Oct 2004 17:00:19 -0000 Received: from unknown (HELO lakermmtao02.cox.net) (68.230.240.37) by sourceware.org with SMTP; 6 Oct 2004 17:00:19 -0000 Received: from white ([68.9.64.121]) by lakermmtao02.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041006170018.EPJR23897.lakermmtao02.cox.net@white>; Wed, 6 Oct 2004 13:00:18 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFF9G-0003F1-00; Wed, 06 Oct 2004 13:00:18 -0400 Date: Wed, 06 Oct 2004 17:02:00 -0000 From: Bob Rossi To: Paul Koning Cc: eliz@gnu.org, drow@false.org, gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's Message-ID: <20041006170018.GE12213@white> Mail-Followup-To: Paul Koning , eliz@gnu.org, drow@false.org, gdb@sources.redhat.com References: <20041004131906.GB8121@white> <200410041533.i94FXsPa014648@juw15.nfra.nl> <20041004155805.GF8121@white> <01c4aabb$Blat.v2.2.2$e64c8fc0@zahav.net.il> <20041005140736.GC13586@nevyn.them.org> <01c4ab8d$Blat.v2.2.2$93dba3c0@zahav.net.il> <20041006112703.GB11747@white> <01c4ab9f$Blat.v2.2.2$e9a87e60@zahav.net.il> <20041006164621.GC12213@white> <16740.9220.368095.137426@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16740.9220.368095.137426@gargle.gargle.HOWL> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00141.txt.bz2 On Wed, Oct 06, 2004 at 12:57:40PM -0400, Paul Koning wrote: > >>>>> "Bob" == Bob Rossi writes: > > Bob> On Wed, Oct 06, 2004 at 02:26:55PM +0200, Eli Zaretskii wrote: > >> > Date: Wed, 6 Oct 2004 07:27:03 -0400 > From: Bob Rossi > >> > Cc: Daniel Jacobowitz , > >> gdb@sources.redhat.com > >> > > >> > > First, it is possible that when the front end knows which MI > >> version > > is the last stable one, it will not need to restart > >> GDB, but just > > arrange for the appropriate parser to be used > >> for the rest of the > > session. > >> > > >> > This is not correct. The front end has parsers for different > >> versions of > GDB's MI protocol. The parser for MI2 will not work > >> for the MI3 protocol > >> > >> In general, it won't, but for a very specific case of > >> _a_single_command_, it could very well do. > > Bob> You obviously not understanding the point here. I can not even > Bob> get my front end to the point where it can look at the > Bob> command. The reason is, I can not *PARSE* the command. > > Bob> Here is a simple explanation that I have tried to discuss over > Bob> and over. > > Bob> 1. Each version of MI comes with a grammar. 2. If the MI > Bob> grammar changes between MI1 and MI2 then 3. A parser is > Bob> generated that understands the grammar for MI1 4. A parser is > Bob> generated that understands the grammar for MI2 5. The parser for > Bob> MI1 *will not parse* the output of MI2 6. The parser for MI2 > Bob> *will not parse* the output of MI1 > > I'm puzzled. If MI2 is a superset of MI1, then the parser for MI2 by > definition will parse any string in MI1. And generalizing, unless MI1 > and MI2 have essentially nothing in common, I don't see how it can be > true that you cannot parse any command at all. > > Just as in any protocol, you need version numbers to cope with the > situation where a new MIx is NOT just a superset of MI. But the > usual picture of protocol evolution is that those cases are not all > that common -- most evoluation creates supersets. Paul, you are almost correct, but you are not. The MIx is not a superset of an MI. They are incompatible. That is the problem. Bob Rossi