RE: asynchronous MI output commands

[Alain Magloire <alain at qnx dot com>]

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

I suppose you could intercept the CLI commands before sending it to GDB

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

You can certainly parse the MI output without knowing what the input was.
The problem is when you get answer what do you do with it?  For example
-data-evaluate-expression may be an action for hovering or to update a tree
viewer etc... Most commands are "synchronous" i.e. an answered to a
question.  Usually front ends will have callbacks attach to the MI
question/command.


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

OOB were suppose to be a way for GDB to notify of changes, that did not come
from a user action. Comes to mind hitting a breakpoint, thread creation,
loading of a library, etc...

> Bob Rossi