Re: RFC: MI output during program execution

[Bob Rossi <bob@brasko.net>]

> >Thanks for all the guidence so far. Even though you have not attempted
> >the observer approach, how do you feel about it? Is this something  
> >that
> >you think could be accomplished with the current FSF GDB? Nick, Daniel
> >and Eli, do you like this approach? I'm sure I could find some time to
> >get something going in this direction, with a little bit of thought.
> 
> This should work fine.  Actually, the "events" that Keith introduced  
> seems easier to do, since it looks like there's already an event call  
> wherever there is a "deprecated_*_hook" but I am not sure what the  
> difference between events & observers is supposed to be...

OK, unfortunatly, I'm still trying to catch up here. I think I
understand the observer approach, however, what is the event approach?
Is that different than the "hooks" you have? 

> >Anyone else willing to work towards this solution?
> >
> >I really like Daniel's idea of just alerting the user that  
> >something has
> >changed, instead of actually giving the user the data. For instance he
> >had,
> >
> >   =breakpoint-changed,[bpnum="1",state="disabled"]
> >   =thread-changed,[thread="2"]
> >
> >I might even prefer,
> >   =breakpoint-changed,thread-changed
> >which would then allow the FE to call -list-breakpoints or whatever if
> >they are interested.
> 
> Why?  These sorts of events are never going to have that much data in  
> them.  Why would you want to force another round trip just to avoid  
> packaging up some data that you already have on hand.  That just  
> makes the UI's job more complicated.  For instance, if a breakpoint  
> command set a breakpoint and started the target going again,  
> currently you are going to have to stop the target to get the  
> breakpoint list, which seems silly.  And even if we made "-break- 
> info" a command that you can issue while the target is going, what if  
> it stopped again between you sending the break info and it getting  
> processed.  You will get another async message before you get the  
> break info response...
> 
> Of course the UI has got to be robust against this sort of thing, but  
> I see no reason to make the job arbitrarily complex.
> 
> Again, what is your reason for wanting to do this?

Well, I just figured it would be easier to say, "This has changed",
instead of giving the entire change. However, if I'm wrong here, that is
fine. It's easy to change this kind of thing once the functionality is
in place. As long as the approach is aggreed on, then I think we'll all
be happy.

Bob Rossi