Re: asynchronous MI output commands

[Vladimir Prus <ghost@cs.msu.su>]

On Thursday 11 May 2006 06:37, Bob Rossi wrote:

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

The "continue" command always produces

  *stopped

response and that's mostly enough for frontend.



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

What do you mean by "determine what an MI output command is"? You certainly 
can parse the response into DOM-like tree without knowing the output command.
If you want to create C data structures for each response, then yes, you'd 
need to know the exact type of the last command. But then, I'm not sure why 
you want to use C data structures. In KDevelop, the DOM is fully dynamic and 
that works just fine, for example:

    const GDBMI::Value& children = r["children"];

    for (unsigned i = 0; i < children.size(); ++i)
    {
        QString exp = children[i]["exp"].literal();


If you have specific structures for each response this won't be very much 
simpler.

> For asynchronous commands, there is simply no way to know what you are
> looking at AFAIK. 

What exactly do you want to know that's not obtained from parse tree?


- Volodya