From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Ingham To: gdb-digest-help@sources.redhat.com Cc: gdb@sources.redhat.com Subject: Re: gdb Digest 5 Mar 2001 20:42:12 -0000 Issue 473 Date: Wed, 21 Mar 2001 15:59:00 -0000 Message-id: <200103052309.PAA18907@scv3.apple.com> References: <983824932.9190.ezmlm@sources.redhat.com> X-SW-Source: 2001-03/msg00048.html Andrew, Both Project Builder and Insight offer a traditional GDB console as well as the GUI interface to gdb. In the case of Insight, the thought was that once the GUI provided ALL the access that you could need to gdb's functionality it would go away. In the case of PB, we have pretty strong feedback from our users that they REALLY like having the console there... So we will need to provide some way to run console commands, WHILE using the MI as the communications channel between gdb & PB. And the use of query is at present a problem which we still need to solve. So while I agree that the design of the MI itself, and of the libgdb interface by extension - should avoid this kind of callback, I at least need to think some more about how to support the CLI over MI mode for the near future. Tcl had the notion of service modes in its interpreter, so that you could modally re-enter the event loop looking for a particular bit of information, but not handling other types. This was needed, for instance, to do things like wait for Window creation in Tk before you went on to do something with the window... Maybe we could use this sort of notion to post & wait on the input channel without losing the local execution context? Jim On Monday, March 5, 2001, at 12:42 PM, gdb-digest- help@sources.redhat.com wrote: > > From conversations, I believe that the current thinking is that MI > operations should be largely self contained - they should not involve > things like call-backs. > > Comments? > > Andrew -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer