RE: probing GDB for MI versions

["Dave Korn" <dk at artimi dot com>]

> -----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....