Re: MI query questions

[Jim Ingham <jingham@apple.com>]

On May 30, 2006, at 11:54 AM, Bob Rossi wrote:

> On Tue, May 30, 2006 at 11:40:51AM -0700, Jim Ingham wrote:
>> Seems like having a callback in your parser to handle async messages
>> from gdb represents cleanly what is going on.  You haven't gotten a
>> completed MI command yet, and you're not ready for another MI
>> command.  But gdb is asking on the side for more input.  Seems like
>> making the two cases look the same is more likely to cause trouble.
>
> I undstand, and sort of agree with you. However, things get slightly
> worse from my perspective. I've designed my FE thus far to behave like
> this:
>   - It is always looking for data from GDB to assemble MI output  
> records.
>   - It will send only a single GDB command at a time.
>
> With that in mind, my FE assembles an MI output record, and then sends
> it up the chain to be looked at more specifically. However, with this
> callback-in-the-middle scenario, my FE will have to be retrained to
> handle partially returned MI output records.
>
> Does this seem acceptable to you?
>
> For instance, the annotate=2 looks like this:
>     pre-prompt
>     (gdb)
>     prompt
>     b A::func
>
>     post-prompt
>     [0] cancel
>     [1] all
>     [2] A::func(float) at overloaded.cpp:8
>     [3] A::func(int) at overloaded.cpp:7
>
>     pre-overload-choice
>>
>     overload-choice
>
> I think the overload choice is as much a prompt as any other  
> command. I'm
> not exactly sure why you think it's a "special" input from the user.

I thought Daniel already answered this.  It's not prompting for MI  
input, which is what the ordinary prompt does, it's just trying to  
slide some information to the CLI interpreter under the covers.  As  
such it is very different from the ordinary prompt.  You also don't  
have a completed MI output at this point - you haven't seen the  
matching ^done or any other appropriate command terminator - so in  
any case you are going to have to deal with partial MI output.

I also like this =read-one-line thingie, because it makes it explicit  
what's going on, namely something other than the MI is trying to read  
one line of input.  So the FE should solicit a line of input from  
whoever it's getting that from in the command that caused this  
message to be delivered, and send it on...

Jim

>
> I do see your point about the way your FE does this, however, do  
> you see
> my point here?
>
> Thanks,
> Bob Rossi