This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI: asynchronous operation details


[in future, please cc the list]

 > > Rather than discuss the possible benefits of asynchronous operation in an
 > > abstract manner, I suggest that you integrate as much of MI into your
 > > front-end (kdevelop?) to find out the limitations.  These limitations
 > > can then be discussed within a context.
 > 
 > So, this amount to saying "you need to convert all of KDevelop to MI to 
 > understand how anynchronous operation is good"?

I'm saying that if you only look for perceived flaws in MI and are not
prepared to write any code that uses it, then you're wasting other people's
time.

 >                                                Sorry, I'm not happy with 
 > this idea -- if "anynchronous operation" is one of selling points of MI, and 
 > there's no clear list of advantages of anynchronous operation, I'm rather 
 > worried.

AFAIK no-one is selling anything.  Currently anynchronous operation is not
really even part of MI.  If you choose to use MI and contribute to its
development, that is welcome.  If you decide not to use it, thats your choice.

 > Speaking about limitations -- KDevelop already has a debugger, writted before 
 > me, and it works mostly fine. There are no grave limitations I want to fix. 
 > The reasons I'm trying MI are just:
 > 
 >    - Simplify parsing of responses.
 >    - Easily determine if command has failed or not.
 > 
 > > In Emacs, Richard Stallman has stated that any front-end fro GDB must keep
 > > the GUD buffer.  This is used to enter CLI commands.  I have found that the
 > > best way to get CLI commands to work well with MI is through asynchronous
 > > operation.  
 > 
 > Why?

It decouples the input, CLI or MI, from the output.  There might be other ways
and it might be partly fortuitous, because all the MI commands that control
execution: -exec-run, -exec-next, -exec-finish etc, are really CLI commands in
disguise, but it works.  Also, thats the path taken by Apple who have a lot of
experience in this area with Project Builder and Xcode.  Thats enough to
convince me.

 > ...Large number of commands are meaningless while inferiour is running -- no 
 > matter if those commands are CLI ones.
 > Look, I'm not trying to say asynchronous operation is useless, or something. 
 > I'm trying to understand if I'll be missing something by ignoring it, and if 
 > I should design to use asynchronous operation. 
 >
 > > Apple have already done this with their version of GDB and you 
 > > can see it in action by installing a copy of Opendarwin.
 > 
 > To begin with, I don't have OSX anywhere to try Opendarwin.

You don't need OSX.  You can download Opendarwin from:

http://www.opendarwin.org

and install it on a partition.  The version that I have (OpenDarwin 7.2.1) is
all comand line and came on a CD.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]