Re: asynchronous MI output commands

[Bob Rossi <bob_rossi@cox.net>]

> > For the record, that's basically what I have in KDevelop. There's command
> > queue, and commands are sent to gdb one-at-a-time, and responses come
> > exactly in the same order. Remembering the last issued command (i.e.
> > instance of GDBCommand class internal to KDevelop) makes it possible to
> > route the response back to the original command.
> > 
> > I'm don't quite understand the problems being discussed in this thread.
> > It's
> > not apparent why one has to know the type of the last command while
> > parsing, and if so, why remembering the last command is bad idea.
> > 
> > It's hard to believe that response from MI can be useful without knowing
> > the
> > last issued command. Say, response from -data-evaluate-expression is
> > useless if you don't know what part of frontend wants that data --
> > evaluating expression is used in many use cases. So, you need to associate
> > extra data with commands anyway.
> >
> 
> I agree, the example that comes to my mind is "next", "step", "finish",
> "continue" etc ...  To do some optimization front-ends will probably need to
> know the last command issue (for example clearing all the variable state in
> a variable view for "continue").

I see the point, however, how do you know if the user typed continue? I
allow the user to have access to the console, and by doing so, I can't
make any assumptions on what GDB is doing.

> Maybe I'm mistaken but I have the impression, looking at the thread, some
> folks are confusing OOB and synchronous response that comes after issuing a
> command.

I'm hopefull not confusing them, but maybe. For synchronous commands, I
just think it's a little ugly that you need the MI input command to
determine what an MI output command is.

For asynchronous commands, there is simply no way to know what you are
looking at AFAIK. You just have to poke around until your fingers get
tired. I still need to research this more though.

Bob Rossi