From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-19752-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 692 invoked by alias); 6 Oct 2004 19:16:57 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 685 invoked from network); 6 Oct 2004 19:16:57 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sourceware.org with SMTP; 6 Oct 2004 19:16:57 -0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i96JGp53025725
	for <gdb@sources.redhat.com>; Wed, 6 Oct 2004 15:16:57 -0400
Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i96JGfr25595;
	Wed, 6 Oct 2004 15:16:41 -0400
Received: from gnu.org (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP
	id 4F11C28D2; Wed,  6 Oct 2004 15:16:20 -0400 (EDT)
Message-ID: <41644484.50203@gnu.org>
Date: Wed, 06 Oct 2004 19:19:00 -0000
From: Andrew Cagney <cagney@gnu.org>
User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831
MIME-Version: 1.0
To: "'Bob Rossi'" <bob@brasko.net>
Cc: Dave Korn <dk@artimi.com>, "'Eli Zaretskii'" <eliz@gnu.org>,
        gdb@sources.redhat.com
Subject: Re: probing GDB for MI versions
References: <NUTMEGGNhwO4fAT1Ily000002da@NUTMEG.CAM.ARTIMI.COM> <41643C45.4050407@gnu.org> <20041006185034.GO12213@white>
In-Reply-To: <20041006185034.GO12213@white>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-10/txt/msg00179.txt.bz2


>>> I find this focus on such pedantic details both puzzling and time 
>>> wasting.   Especially given that any code intended to handle multiple MI 
>>> variants must be adhoc.  Otherwize it won't work with all the variants 
>>> that pre-date the above - mi0, mi1, mi2 (prior to the above extension.

s/handle multiple/handle initial negotiation of multiple/

As everyone else has pointed out, with the negitiation done, the real 
parser can be loaded.

> You are stating that a parser that implements an MIn Output syntax has
> to be adhoc? I plan on having a parser for each of these interface's and
> none of them is adhoc. I don't think you should force your adhoc
> approach onto the front end developers.
> 
> 
>>> MI needs is additional commands and extensions, driven by the needs of 
>>> Free software projects.  Neither of those - EMACS and Eclipse - appear 
>>> to be having problems this technical nits such as this.
> 
> 
> I can't explain why. 

Andrew