From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9466 invoked by alias); 7 Oct 2004 14:27:59 -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 9445 invoked from network); 7 Oct 2004 14:27:57 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 7 Oct 2004 14:27:57 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 15:27:35 +0100 From: "Dave Korn" To: "'Bob Rossi'" Cc: "'Eli Zaretskii'" , Subject: RE: probing GDB for MI versions Date: Thu, 07 Oct 2004 14:39:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20041007140455.GA14402@white> Message-ID: X-OriginalArrivalTime: 07 Oct 2004 14:27:35.0673 (UTC) FILETIME=[CA355690:01C4AC79] X-SW-Source: 2004-10/txt/msg00210.txt.bz2 > -----Original Message----- > From: 'Bob Rossi' > Sent: 07 October 2004 15:05 [Eli, if you'd rather I Cc you out of this now-getting-fairly-pointless-and-repetitive discussion, just drop me a note offlist] > > You use the term "adhoc parser" as if that were a bad > thing. It's not. > > It's an entirely reasonable way for a computer program to > parse some data > > and extract some simple information that it requires. > > You seem like you want "more of the old". Don't put words in my mouth or impute motives to me, you know nothing about me. > GDB has come a long way from > the adhoc parsers the front end's had to generate to deal > with the CLI. Your argument is a strawman. > 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. > Getting the data, one line at a time, not in the context of > an MI Output > command is fine with me. It has nothing to do with MI and I like that. Your rigidity and inflexibility of thought cripples your ability to apply the appropriate tool to solve a VERY VERY SIMPLE problem. It doesn't matter if the data is in MI format, the simple string matching approach WILL STILL FIND IT EMBEDDED IN THE MI FORMATTING. > I have thought about this long enough to have come to a conclusion. I > think it is silly to add an MI command to GDB that can not be > used by a front end that speaks the MI protocol. Your claim is utterly false: of course the command can be used by such a front end. The front end can use whatever means it likes to select the correct parser for the mi version of the gdb its using, and then the output from the -mi-versions command can be parsed by it. Just because I presented the output as a simple plaintext string doesn't mean it shouldn't be given in MI format, and I didn't say anything to suggest it should be, so this is yet another strawman where you invent your own false representation of what I've described and then attack the flaws you placed in your own invention. > * Let's make this clear, MI commands are there for front ends that > speak the MI protocol. An irrelevant truism. > The solution of adding an MI command that can only be looked > at by an adhoc parser As I explain above, it can also be looked at by a full MI parser. > and making rules like "the command will never change" > is non-intuitive and confusing. How much experience of computer programming do you actually have? Have you any concept of versioning mechanisms? Have you ever heard of an ABI, or an "interface specification", in the context of it being a future guarantee? What I describe is standard practice throughout the software industry and has been for many many years. You need to read some books or take a course or something. Nobody else has the conceptual difficulties you've been getting yourself stuck in with these fundamentals. > Having a simple mechanism, such as a command > line switch or a > new interpreter, would be simple and understandable. This is still an invalid argument, for still the exact same reason that I explained in my last post and you conveniently ignored because you had no good answer for it. You are now just repeating yourself without adding any new content. So I may as well repeat my explanation of the problem without adding any new content. Please pay attention this time: You claim that the problem is in having to supply an adhoc parser and make rules like "the output will never change". Yet _your_ proposed solution suffers from the exact same flaw. cheers, DaveK -- Can't think of a witty .sigline today....