Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Bob Rossi <bob_rossi@cox.net>
To: gdb@sources.redhat.com
Subject: Re: obsoleting annotate level 2
Date: Wed, 05 Feb 2003 20:04:00 -0000	[thread overview]
Message-ID: <20030205200423.GB4309@white> (raw)
In-Reply-To: <vt2el6nte8e.fsf@zenia.red-bean.com>

On Wed, Feb 05, 2003 at 01:48:17AM -0500, Jim Blandy wrote:
> 
> Mike Mueller <mmueller@cs.uri.edu> writes:
> > Jim Blandy wrote:
> > 
> > > The plan has been, for a very long time, to remove all 
> > > annotations.  I proposed keeping level one annotations.  Here was 
> > > my rationale:
> > 
> > > Level one annotations are implemented by code at two or three 
> > > points in GDB.  They're not a big deal to maintain.  And they're 
> > > what current releases of Emacs use.
> > 
> > > Level two annotations are implemented by (I think) around eighty
> > > different bits of code, scattered throughout GDB.
> > 
> > > Thus, while level one annotations are only a small maintenance 
> > > burden, level two annotations are.  Even if Emacs had been using 
> > > level two annotations for years, we would be trying to get rid of 
> > > them.
> > 
> > Jim,
> > 
> > Our only concern is that annotate 2 is the basis of our 
> > application.  Our request is that the removal of annotate 2 is done 
> > when MI is stable and is successfully used by at least one 
> > application.  Until MI has reached that point, our application will 
> > be forced to depend on annotate 2.
> 
> MI is already successfully in use by one (admittedly non-free)
> application --- Apple's Power Builder.  Eclipse uses it now, too.
> 
> MI is, by design, always going to be more stable than annotation level
> two.  MI imposes more structure on its output than annotation level
> two does.
> 
> So I think MI is ready for the transition.
> 
> When you do find something you need, ask here.  In most cases, it's
> very easy to add something to MI; when an easy case comes up, I'll
> point it out, and you can get a chance to try doing it yourself.  Once
> you can write your own patches to provide what you need, and you
> understand the GDB coding standards, I think things will go very
> quickly for you.

Is gdb-mi ready to be used in gdb-5.3? or should I check out the cvs
tree in order to start building the new interface between cgdb and gdb?

Bobby


  reply	other threads:[~2003-02-05 20:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-04 19:53 Mike Mueller
2003-02-05  6:57 ` Jim Blandy
2003-02-05 20:04   ` Bob Rossi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-02-04 12:44 Bob Rossi
2003-02-04 15:49 ` Elena Zannoni
2003-02-04 16:12   ` Peter Kovacs
2003-02-04 16:30     ` Elena Zannoni
2003-02-04 16:37       ` Bob Rossi
2003-02-04 17:10         ` Elena Zannoni
2003-02-04 19:48           ` Jim Blandy
2003-02-04 21:22             ` Nick Roberts
2003-02-04 23:01               ` Andrew Cagney
2003-02-04 16:41       ` Peter Kovacs
2003-02-04 16:46         ` Peter Kovacs
2003-02-04 17:16         ` Elena Zannoni

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=20030205200423.GB4309@white \
    --to=bob_rossi@cox.net \
    --cc=gdb@sources.redhat.com \
    /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