From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17027 invoked by alias); 24 Jul 2009 21:06:31 -0000 Received: (qmail 17015 invoked by uid 22791); 24 Jul 2009 21:06:30 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_20,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Jul 2009 21:06:19 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n6OL6GIG024238 for ; Fri, 24 Jul 2009 17:06:16 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n6OL6GnJ010060 for ; Fri, 24 Jul 2009 17:06:16 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n6OL6EaX020432; Fri, 24 Jul 2009 17:06:15 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 8EC635081C2; Fri, 24 Jul 2009 15:06:14 -0600 (MDT) To: nickrob@snap.net.nz (Nick Roberts) Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: [mi] -stack-list-arguments --simple-values References: <200906301339.30711.vladimir@codesourcery.com> <19020.32725.55167.391078@totara.tehura.co.nz> <19021.49761.460467.374394@totara.tehura.co.nz> From: Tom Tromey Reply-To: tromey@redhat.com Date: Fri, 24 Jul 2009 22:07:00 -0000 In-Reply-To: <19021.49761.460467.374394@totara.tehura.co.nz> (Nick Roberts's message of "Fri\, 3 Jul 2009 20\:33\:37 +1200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00608.txt.bz2 >>>>> "Nick" == Nick Roberts writes: Replying to an old-ish note. Nick> People often lament the poor syntax of MI but it really needs a Nick> plan to replace it with something better. However, such a plan Nick> would really need a maintainer to lead it and doesn't really work Nick> on a Write After Approval basis. I think we can differentiate here between a plan and the patches implementing the plan. In my view we could discuss the plan on the gdb list and reach some kind of agreement. This can be initiated by anybody. If you want to start it, I will try to help ensure that the discussion reaches some conclusion. I think if there is general agreement about the direction then patch review need not be a big problem. I suppose my view is based on the idea that the plan is probably where most of the contention lies, and usually the implementation bits are straightforward. Volodya> FWIW, both the above issue is universally believed to be not Volodya> good, so patches to introduce MI3 version and switch select Volodya> commands to "right" syntax appear to be fairly simple. Nick> I quite like the idea of incrementally changing the output with Nick> new commands because as soon as MI3 is released, you can be sure Nick> people will find shortcomings with that. You could say it is a Nick> more agile approach. What do you suggest? I ask because this does seem to come up over and over. Not only are there MI formatting bugs, there are things like the recently discussed "info shared" output problem -- a command that has no MI equivalent, no use of ui_out, and which, presumably, existing MI consumers handle by parsing the CLI output. I have been thinking about this case for a few days and I really don't have any good solution. I also think that MI versioning seems to work at too coarse a granularity. For pretty-printing we're adding an explicit "enable" command to work around this problem -- but it seems odd to have an MI session start off with 100 -enable-foo commands. And, this case doesn't account for the mess that it would leave behind if we, e.g., applied it to the "info shared" case. Tom