Re: asynchronous MI output commands

[Bob Rossi <bob_rossi@cox.net>]

On Thu, May 11, 2006 at 10:58:08AM -0400, Alain Magloire wrote:
> 
> 
> > > > 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

This isn't a good idea, and probably impossible. Don't forget about user
defined commands. Also, don't forget that hitting a breakpoint can run
some commands. You never really know when 'continue' is sent.

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

Yes, sorry this is what I mean. Geez, I'm not good at expressing myself.

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

I need to play more with these. Thanks for the suggestions.

Bob Rossi