Re: RFC: MI output during program execution

[Nick Roberts <nickrob at snap dot net dot nz>]

 > > Using strcmp (interpreter_p, "mi") and not strncmp (interpreter_p, "mi", 2)
 > > means that this should only change behaviour for the current mi level.
 > 
 > Checking the name of the MI interpreter seems inelegant.  It'll break
 > this when we transition from MI2 to MI3 as the stable version for
 > instance.  Maybe there's a way to make mi_version usable outside of
 > mi/*.

If the change proves to a good one (which seems unlikely now) then it could
possibly be used for all versions.

 > Forcing this to raw_stdout is also not OK, since my whole point was to
 > pass this information to the interpreter so that it can distribute it
 > to clients appropriately - they may not be on stdout.  I realize that's
 > what the MI layer previously did, but I don't get a good taste in my
 > mouth from bypassing the MI output layer this way.

You presumably mean what the MI layer _currently does_.  Using raw_stdout
doesn't improve things but it doesn't make them any worse.

 > The hooks we were talking about were primarily for things like the
 > breakpoint list and thread list.  The ^running response is touchier.
 > ^running is a result record, not an async record.  It has to be the
 > result of a command.  

It is classed as a result record in MI but presumably its an asynchronous
process.  Perhaps it should be *running, just as it is *stopped.  Treating it
as a result record means that new commands which run the inferior must
also call mi_execute_async_cli_command or they won't output ^running.  Putting
it in proceed ensures this automatically.

 >                      Bob's our expert on this, but I'd think that this
 > change could break the grammar.  There's probably a way to get this to
 > happen when the resulting prompt does not signify that another command
 > may be accepted now.
 > 
 > Certainly it makes verifying from the source that we obey the grammar
 > much more difficult, by moving bits of the MI implementation into
 > infrun.  That's enough reason for it not to have been done this way in
 > the first place - it's harder to maintain.

I will look at making to more modular.  You have said:

DJ> What I'd like to see is a way to keep multiple interpreters open at the
DJ> same time.Then, have one of them accepting input at a time, and receiving
DJ> informative output, but all of them receiving some kinds of output.

This presumably requires the code that generates MI output to be moved
outside MI specific code.

 > Also, Bob said he was willing to work on doing this correctly.

I'm lost.  I'm not sure what correctly means in this case.  I would like
to get MI-like output (specifically about whether the execution is running
or not) from CLI commands.  Is Bob offering to do this?

Nick