Re: obsoleting the annotate level 2 interface

[Jim Blandy <jimb at redhat dot com>]

Nick Clifton <nickc@redhat.com> writes:
> I think writing a mode for Emacs that uses MI would require quite a different
> approach to gdb-ui.el. Think of what was involved in `bringing GDB over to MI'
> (a lot of work, I would imagine).

I don't think it will be too bad.  After all, with MI GDB provides all
the same information, but in a reliably parseable form.  I would
expect a good amount of hair in gdb-ui.el to go away.

> At the time, streams didn't seem to work. I couldn't seem to generate the @
> prefix output. That's probably changed now. I can't really say much more
> until I have something concrete to experiment with.

Probably the most recent release (GDB 5.3) is a good place to start.

> I have never seen the source for GDB. Perhaps you can explain why
> annotations is difficult to maintain. In my limited experience, I
> have found that two features in a program can often be orthogonal to
> one another. That is, one feature can be developed as if the other
> feature isn't there.

Well, I talked about this a bit in my original post.  Three reasons:

- Both annotations and MI involve little changes sprinkled throughout
  GDB's code: every command that produces output has to be marked up.
  (This isn't the whole story; with MI, we often just add new commands
  that have more disciplined behavior for a program to use.)  We don't
  want to have to maintain both of those systems, when one of them is
  good enough to do the job.

- MI is more stable.  Annotation simply flags pieces of GDB's ordinary
  output to suggest where a consumer might start parsing --- but the
  data being parsed is GDB's direct output.  This means that any time
  we change the way GDB prints something --- say, to make something
  clearer, or to provide newly available information --- we may break
  clients trying to parse that output.  There's history to show that
  this is a problem.

  With MI, however, there's a much clearer segregation between the
  information intended for machine consumption, and that intended only
  for human consumption --- data that isn't yet available in a nicely
  parsed form, or presumably isn't interesting to other programs.
  They're produced using distinct calls.  So for a GDB developer, it's
  much clearer when you're changing something that another program
  might care about.

- MI can age more gracefully than annotations can.  With annotations,
  it's never clear to a GDB developer exactly which information other
  programs are consuming, and which they don't care about.  MI is
  designed so that, when you discover something a program needs, it's
  easy to rework the output code (or write some new output code) to
  produce it in MI form --- so MI's capabilities can grow in an
  evolutionary, organic kind of way, without breaking things all the
  time.

Really, once you get things going with MI, I think you'll prefer it.

> Also gdb-ui.el probably doesn't need all the annotations. If you
> lost some key ones (frames-invalid and breakpoints-invalid, for
> example) would this make it easier to maintain?

Well, but if gdb-ui takes off, people will want to add more and more
features to it.  That's what we all hope for, right?  You don't want
your success case to be the one that you've promised to avoid.

Like you, I don't have time officially allocated for this.  So we'll
both need to be patient with each other.  But Emacs is the only
environment that I can imagine using, and I use GDB in Emacs daily, so
I'm interested in doing what I can to make this work out.