From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6461 invoked by alias); 15 Nov 2013 12:39:17 -0000 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 Received: (qmail 6432 invoked by uid 89); 15 Nov 2013 12:39:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,RDNS_NONE autolearn=no version=3.3.2 X-HELO: rock.gnat.com Received: from Unknown (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 15 Nov 2013 12:39:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 129661160D8; Fri, 15 Nov 2013 07:39:40 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pBGF6zkkBFlW; Fri, 15 Nov 2013 07:39:40 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 953D41160D7; Fri, 15 Nov 2013 07:39:39 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 056F5E1407; Fri, 15 Nov 2013 16:39:06 +0400 (RET) Date: Fri, 15 Nov 2013 14:38:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: Tom Tromey , =?iso-8859-1?Q?Andr=E9_P=F6nitz?= , gdb-patches@sourceware.org Subject: Re: [RFC] New GDB/MI command "-info-gdb-mi-command" Message-ID: <20131115123905.GW3481@adacore.com> References: <8761rzknb4.fsf@fleche.redhat.com> <1384255504-28444-1-git-send-email-brobecker@adacore.com> <20131112205229.GA7068@klara.mpi.htwm.de> <20131113021514.GG3481@adacore.com> <52851A04.6040004@redhat.com> <52851E57.30103@redhat.com> <87iovuwx7l.fsf@fleche.redhat.com> <20131115033021.GT3481@adacore.com> <52861143.3030408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52861143.3030408@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-11/txt/msg00411.txt.bz2 > > Regarding invalid switches, we may have to extend the current proposal > > to allow the command to specific what in the usage caused problem? > > Not sure about that. Sounds more complicated than it's worth it. > > > In my proposal, it was easy to extend by adding a "feature=[...]" > > list to the output. Or maybe that's overkill? Or use list-features > > for that instead? > > As list-features already exists, and works just as well, that might > indeed be overkill. Or put another way, is there a use case that > list-features doesn't cover, or something about "feature=[]" > that'd make ours and frontend writers' lives easier? Just like with > list-features, we'd always have to manually take care of listing the > new command feature in "features=[]", so on our end it doesn't seem > to buy anything. > IOW, thinking in terms of KISS seems to suggest sticking with > list-features. OK, I think will work well enough in practice, and, really, worrying about a few more bytes at a time was a bit of an overreaction :). > > I'd like us to decide to something I can go and implement. Either way, > > I think we can start by concentrating with the initial goal, which is > > to determine whether a command exists or not. > > Yeah. I have no problem with your proposal. There's actually one > case where it works, and '^error,code="unknown-command"' does not, > which is when a command works and has effects without options. In such > cases, you can't probe for the command's existence without causing > the (side) effects. I think the intent was not to provide a probing mechanism, but rather to provide an approach where the FE just fires the command when it needs to, and then fallback on a CLI-based approach if detecting an 'unknown-command' error. But, on the other hand, I am thinking that some FEs might still want to probe ahead of time, for instance if they do not wish to provide a fallback mechanism (thus disabling the relevant parts of the GUI ahead of time); or even if it is easier programatically for them to probe, instead of having to handle this specific error. > > People seem to have reacted > > more positively to the idea of try-and-fallback approach, shall we go > > with Pedro's idea (without the "invalid switch"/"usage" part)? > > If I had infinite time, I'd go for all of the above. Command to > probe existence of commands, and make ^error indicate both > unknown command, and bad usage. :-) I don't have infinite amount of time, but the first 2 (new GDB/MI command and new ^error for unknown commands) are fairly small tasks, so I'm happy sending patches for both. That way, we get the best of both worlds, without must cost, I think, in terms of extra maintenance, since both patches would be pretty small, and localized. For invalid usage, I could add that to my list, but that'll have to be next year... (/me wishes I would say that on Dec 31st...) -- Joel