Re: MI non-stop mode spec

[Bob Rossi <bob_rossi@cox.net>]

On Wed, Mar 19, 2008 at 04:50:27PM +0300, Vladimir Prus wrote:
> > > The following changes will happen:
> > > 	output ==> 
> > > 	( out-of-band-record )* [ result-record ] "(gdb)" nl
> > > becomes:
> > > 	output ==>
> > > 		( out-of-band-record | result-record | "(gdb)" ) nl
> > 

> The above grammar say that gdb outputs either:
> 
> 1. out-of-band record,
> 2. result record
> 3. prompt
> 
> and that any of those is followed by a newline. So, you can
> have 100 out-of-band-records, followed by result record, followed by
> prompt, followed by some more out-of-band records.
> 
> The 'output' nonterminal does not describe all the output
> that gdb might produce during entire run, it describes a single line
> that gdb might output.

Hmm, that's interesting. So you are suggesting that output will be 
called over and over, instead of once. Am I correct?

Is it no longer possible to add a top level rule?
  ie. 
    output ==> output_line* (some terminator)

    output_line ==> 
	( out-of-band-record | result-record | "(gdb)" ) nl

I'm not sure how to rationalize about getting line after line, with no
final response. Perhaps I need to entirely rethink what gdb/mi is, and
how to model an api on top of it. Could you give me some pointers?

> > OK, that's great. Please think about the request I'm going to make, I
> > think it's very important. I think the first thing gdb should do is
> > output a single line (a header) that tells the version that mi is going
> > to use during this communication, and the current versions that the 
> > particular gdb supports.
> > 
> > The more we bump the MI revisions, the more it is going to take time for
> > front ends to continually start gdb, probing for the best version it 
> > supports.
> > 
> > I can submit a patch for this, if you don't feel like doing it.
> 
> We should see what the final changes will be. Probably, we can announce
> them using the existing -list-features command and then add a mechanism
> to enable new behaviour with a MI command.
> 
> Of course, if that proves unsufficient, we can implement a command
> to query the available MI versions, and switch to the desired one.

hehe. Think of it like this, xml, html, all of these other great
languages always tell you first what the protocol you are communicating
with is using. I just want mi to do the same thing. It's WAY to late in
the game to call -list-features. For all you know, the user has some
stuff in his .gdbinit that get run, and MI starts spewing out.

I'm sure we could play some games with the command line, to put our own
.gdbinit command to run first, but that just seems overly complicated.

We should, at a minimum, print out the current version of mi in a
prolouge mi statement.

Bob Rossi