From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24689 invoked by alias); 26 Jul 2009 01:14:33 -0000 Received: (qmail 24680 invoked by uid 22791); 26 Jul 2009 01:14:30 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 26 Jul 2009 01:14:21 +0000 Received: from totara (217.30.255.123.dynamic.snap.net.nz [123.255.30.217]) by viper.snap.net.nz (Postfix) with ESMTP id 2A37B3DB291; Sun, 26 Jul 2009 13:14:14 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id 1AC1BC15A; Sun, 26 Jul 2009 13:14:13 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19051.44515.133597.439183@totara.tehura.co.nz> Date: Sun, 26 Jul 2009 11:42:00 -0000 To: tromey@redhat.com Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: [mi] -stack-list-arguments --simple-values In-Reply-To: References: <200906301339.30711.vladimir@codesourcery.com> <19020.32725.55167.391078@totara.tehura.co.nz> <19021.49761.460467.374394@totara.tehura.co.nz> From: nickrob@snap.net.nz (Nick Roberts) 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/msg00635.txt.bz2 > 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. Thanks for the offer but I have found it hard to convince maintainers to make changes that they are not interested in. For example, changing the behaviour of "record stop" to not need confirmation when the server prefix is used: http://sourceware.org/ml/gdb/2009-07/msg00153.html I see this as an uncontroversial change that wouldn't affect other GDB developers. It probably wouldn't benefit them either but in Emacs development the rule is just basically "do no harm". With larger changes, e.g. using notifications for breakpoints, it can be harder to reach a 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? Just that the output of some commands break the formal syntax rules, or at least, parsing would be easier if: "[" RESULT ( "," RESULT )* "]" wasn't admissible as in a LIST. This could be circumvented, by adding new commands ("embrace and extend") that provide a more consistent rather than adding another MI level. In Emacs, Dmitry Dzhus, has parsed the GDB/MI output as JSON objects and, by way of an example, we might submit a patch for the new command -stack-list-locals-and-args that was discussed earlier on the gdb mailing list. Of course, changes in asynchronous output probably would need a new MI level. -- Nick http://www.inet.net.nz/~nickrob