Re: asynchronous MI output commands

[Bob Rossi <bob_rossi@cox.net>]

On Thu, May 11, 2006 at 10:08:15AM +0400, Vladimir Prus wrote:
> 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.

OK, this isn't true. I used GDB CVS for this.

(gdb)
-break-insert main.c:4
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x08048364",func="main",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c",line="4",times="0"}
(gdb)
-break-insert main.c:5
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0804836b",func="main",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c",line="5",times="0"}
(gdb)
-exec-run
^running
(gdb)
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x08048364",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffbc9a4"}],file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c",line="4"}
(gdb)
-interpreter-exec console "continue"
~"Continuing.\n"
~"\n"
~"Breakpoint 2, main (argc=1, argv=0xbffbc9a4) at main.c:5\n"
~"5\t  argc = 2;\n"
^done
(gdb)

The continue command doesn't give a *stopped.

> > > 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. I need the MI input command to do that. I was hoping an
extension to the MI output would be allowed to get around this.

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

I need slightly more information and to do a little more testing to
describe the problem above in certanty. When I get to that point I'll
start another thread that's more meaningful.

Bob Rossi