Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb@sources.redhat.com
Subject: Re: MI: asynchronous operation details
Date: Wed, 23 Nov 2005 09:31:00 -0000	[thread overview]
Message-ID: <17284.10758.341185.874368@kahikatea.snap.net.nz> (raw)
In-Reply-To: <200511230931.50438.ghost@cs.msu.su>

[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.


  parent reply	other threads:[~2005-11-23  8:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-22  8:33 Vladimir Prus
2005-11-22  9:07 ` Konstantin Karganov
2005-11-22 12:07   ` Vladimir Prus
2005-11-22 12:13 ` Bob Rossi
2005-11-22 12:20   ` Vladimir Prus
2005-11-22 13:38     ` Bob Rossi
2005-11-22 13:49       ` Vladimir Prus
2005-11-22 14:00         ` Bob Rossi
2005-11-22 14:12           ` Vladimir Prus
2005-11-22 14:19             ` Daniel Jacobowitz
2005-11-22 20:39             ` Nick Roberts
     [not found]               ` <200511230931.50438.ghost@cs.msu.su>
2005-11-23  9:31                 ` Nick Roberts [this message]
2005-11-22 20:04     ` Eli Zaretskii
2005-11-22 14:59   ` How can I unsubscribe? Gengis Toledo
2005-11-22 15:11     ` Daniel Jacobowitz
2005-11-22 15:02       ` Daniel Jacobowitz
2005-11-22 16:48       ` Christopher Faylor
2005-11-22 18:42         ` Dave Korn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17284.10758.341185.874368@kahikatea.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=gdb@sources.redhat.com \
    --cc=ghost@cs.msu.su \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox