From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9052 invoked by alias); 18 Sep 2005 03:46:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9032 invoked by uid 22791); 18 Sep 2005 03:46:41 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 18 Sep 2005 03:46:41 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EGq8V-0001w0-FV; Sat, 17 Sep 2005 23:46:39 -0400 Date: Sun, 18 Sep 2005 03:46:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Joel Brobecker , gdb-patches@sources.redhat.com Subject: Re: [RFA] print arrays with indexes Message-ID: <20050918034639.GB6990@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Joel Brobecker , gdb-patches@sources.redhat.com References: <20050906202018.GC1153@adacore.com> <20050906205710.GA12715@nevyn.them.org> <20050907053951.GC1540@adacore.com> <20050907132316.GA3622@nevyn.them.org> <20050907202402.GF1540@adacore.com> <20050914171319.GD27542@adacore.com> <20050917204930.GB8777@nevyn.them.org> <20050917215138.GB2496@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00156.txt.bz2 On Sun, Sep 18, 2005 at 06:37:19AM +0300, Eli Zaretskii wrote: > > Date: Sat, 17 Sep 2005 14:51:38 -0700 > > From: Joel Brobecker > > > > > Then doesn't it make sense to agree on the interface first? :-) > > > > Right! I just wanted to hear a few other opinions to choose. > > Perhaps Eli and/or Mark would like to comment? > > > > In any case: > > > > > You suggested on/off/auto and a separate threshold. Jim suggested > > > on/off/threshold. I prefer on/off/threshold of those two options, > > > although it may be a bit tricky to get GDB to handle that correctly. > > > Want to give it a try, or continue discussing alternatives? > > > > I'm willing to give it a try. I couldn't find a mechanism in our > > "set/show" machinery that handled something like this, though. > > Unless I missed it, that's something I'll need to add too. > > I don't see any disadvantages to the on/off/auto+threshold method that > would justify yet another add_* interface. Can someone please tell > why is that a good idea? My first reaction was that it would be confusing. We'd have a variable to hold the threshold, and it would always show up in "show" or "help" output, but most of the time its value would be ignored. The trickier something is to document accurately, the more likely it is to confuse users. I'm not real attached to either one. If you think two separate knobs is simpler, then that's fine with me. -- Daniel Jacobowitz CodeSourcery, LLC