From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18388 invoked by alias); 25 Jul 2009 06:16:24 -0000 Received: (qmail 18380 invoked by uid 22791); 25 Jul 2009 06:16:23 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 25 Jul 2009 06:16:15 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MUaYE-0004D7-1O for gdb-patches@sources.redhat.com; Sat, 25 Jul 2009 06:16:10 +0000 Received: from h86-62-88-129.ln.rinet.ru ([86.62.88.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 Jul 2009 06:16:10 +0000 Received: from vladimir by h86-62-88-129.ln.rinet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 Jul 2009 06:16:10 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [mi] -stack-list-arguments --simple-values Date: Sat, 25 Jul 2009 07:21:00 -0000 Message-ID: References: <200906301339.30711.vladimir@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes 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/msg00619.txt.bz2 Tom Tromey wrote: >>>>>> "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. I presume one approach is to declare MI3 "volatile" and subject to breaking change on short notice, so that I can evolve and stabilize freely, and only then be freezed. - Volodya