From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-19785-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 17073 invoked by alias); 7 Oct 2004 14:37:18 -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 17066 invoked from network); 7 Oct 2004 14:37:17 -0000
Received: from unknown (HELO lakermmtao03.cox.net) (68.230.240.36)
  by sourceware.org with SMTP; 7 Oct 2004 14:37:17 -0000
Received: from white ([68.9.64.121]) by lakermmtao03.cox.net
          (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP
          id <20041007143716.SWJL13098.lakermmtao03.cox.net@white>;
          Thu, 7 Oct 2004 10:37:16 -0400
Received: from bob by white with local (Exim 3.35 #1 (Debian))
	id 1CFZOO-0003m1-00; Thu, 07 Oct 2004 10:37:16 -0400
Date: Thu, 07 Oct 2004 14:50:00 -0000
From: 'Bob Rossi' <bob@brasko.net>
To: Dave Korn <dk@artimi.com>
Cc: 'Eli Zaretskii' <eliz@gnu.org>, gdb@sources.redhat.com
Subject: Re: probing GDB for MI versions
Message-ID: <20041007143716.GB14402@white>
Mail-Followup-To: Dave Korn <dk@artimi.com>, 'Eli Zaretskii' <eliz@gnu.org>,
	gdb@sources.redhat.com
References: <20041007140455.GA14402@white> <NUTMEG9TxKJXnCSXOeG000002f9@NUTMEG.CAM.ARTIMI.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <NUTMEG9TxKJXnCSXOeG000002f9@NUTMEG.CAM.ARTIMI.COM>
User-Agent: Mutt/1.3.28i
X-SW-Source: 2004-10/txt/msg00212.txt.bz2

> > The MI developers, wise as they are, decided to formalize the way GDB
> > output's data and front end developers parse it.
> 
>   Your insistence on using formal parsers for every single job regardless of
> the fact that you can also see that they're not suitable for the job flies
> in the face of sanity.  You're a child with a hammer and every single
> problem looks to you like a nail.

You are inappropriate.

I clearly understand that either way an adhoc parser is involved. I
undersatnd the problem can be solved both ways, with an MI command or a
command line switch.

I understand that adding an MI command to the MI function set that can
not be accessed by a front end that understands the MI protocol is
nonsensical and confusing, that is why I am arguing on the side of not
adding this command to the MI function set, but solving the problem
another way.

Thanks,
Bob Rossi