Re: asynchronous MI output commands

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

On Thursday 11 May 2006 14:40, Bob Rossi wrote:

> > The "continue" command always produces
> >
> >   *stopped
> >
> > response and that's mostly enough for frontend.
>
> OK, this isn't true. I used GDB CVS for this.

Yea, I realized that "continue" not only does not produces "^running" but also 
does not produces "*stopped" right after posting.

> > > > 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.
>
> Sorry, I've described this before, but apparently not good enough. I
> definatly can create the abstract parse tree with out knowing the input
> command. However, then I want to create C data structures for each
> MI output. 

Why? With C data structures, the above frontend code will be only marginally 
simpler.

- Volodya