From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21875 invoked by alias); 29 Jan 2003 21:52:57 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21865 invoked from network); 29 Jan 2003 21:52:54 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by 172.16.49.205 with SMTP; 29 Jan 2003 21:52:54 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h0TLlJ8A024407; Wed, 29 Jan 2003 16:47:19 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h0TLlHbJ024403; Wed, 29 Jan 2003 16:47:17 -0500 To: Nick Roberts Cc: rms@gnu.org, gdb@sources.redhat.com Subject: Re: obsoleting the annotate level 2 interface References: <15917.39229.935851.920452@nick.uklinux.net> <15927.12416.601404.240113@nick.uklinux.net> From: Jim Blandy Date: Wed, 29 Jan 2003 21:52:00 -0000 In-Reply-To: <15927.12416.601404.240113@nick.uklinux.net> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-01/txt/msg00500.txt.bz2 Nick Clifton 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.