From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25476 invoked by alias); 24 Jan 2015 08:50:10 -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 25462 invoked by uid 89); 24 Jan 2015 08:50:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout23.012.net.il Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 24 Jan 2015 08:50:07 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NIO00D00AWM4S00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Sat, 24 Jan 2015 10:50:04 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIO00DGSB7F0B70@a-mtaout23.012.net.il>; Sat, 24 Jan 2015 10:50:04 +0200 (IST) Date: Sat, 24 Jan 2015 14:12:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH 3/3 v2] Implement completion limiting In-reply-to: To: Doug Evans Cc: gbenson@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83k30csgu7.fsf@gnu.org> References: <1417094168-25868-1-git-send-email-gbenson@redhat.com> <1417094168-25868-4-git-send-email-gbenson@redhat.com> <20141210122233.GA7299@blade.nx> <21671.20308.262958.475080@ruffy2.mtv.corp.google.com> <20150107084255.GA17867@blade.nx> <21680.36641.315766.209208@ruffy2.mtv.corp.google.com> <83a91r6lbd.fsf@gnu.org> <20150115153930.GA14900@blade.nx> <83h9vhu7k8.fsf@gnu.org> <83zj99sbgk.fsf@gnu.org> <83wq4ds0lh.fsf@gnu.org> X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00666.txt.bz2 > Date: Fri, 23 Jan 2015 16:32:29 -0800 > From: Doug Evans > Cc: Gary Benson , > "gdb-patches@sourceware.org" > > On Fri, Jan 23, 2015 at 12:28 PM, Eli Zaretskii wrote: > >> Date: Fri, 23 Jan 2015 08:56:59 -0800 > >> From: Doug Evans > >> Cc: Gary Benson , > >> "gdb-patches@sourceware.org" > >> > >> How often will there be exactly N? > > > > About the same frequency as there will be exactly N-1, I guess. > > My point is, given any particular value I set for > "set max-completions N", what's the probability > that exactly that N completions will be found? > Rather low I expect. Rather low, I agree. But having N-1 is as low as having N. So the problem with wasting 99% of the time searching for a candidate that isn't there is not solved by not searching for the N+1st candidate. > > 200 is just a random number. It's not magic in any way. So you > > could have 199 completions found in the first 5 sec, followed by 5 > > minutes of waiting for the 200th which is never found. Ugh. > > > > There's no way around this issue. > > But if I, as a user, do "set max-completions 199" > and then find out gdb is looking for 200 completions > I would be disappointed. I might file a bug report even. When the user sets max-completions to 199, it expects GDB not to _show_ more than that. The documentation says: @item set max-completions @var{limit} @itemx set max-completions unlimited Set the maximum number of candidates to be shown during completion. [...] ^^^^^^^^^^^ @item show max-completions Show the maximum number of candidates to be shown during completion. ^^^^^^^^^^^ This usually means "find the completions, but don't show me more than the limit". If GDB is not going to try to see if there are more than the limit, then we need to tell that in the docs, otherwise some user might become disappointed and might file a bug report, claiming that GDB told it there might be more candidates, when there were none. > If I do "set max-completions N" I expect gdb to stop looking > when it gets to N. Well, at least one frequent user of GDB -- yours truly -- would expect GDB to actually try at least one more. So we should be explicit this is not what GDB does (assuming we are okay with that modus operandi). > >> I don't see the benefit of going to the trouble > >> of avoiding printing any message when there are > >> exactly N completions. > > > > That's fine, but then the option's name and its documentation should > > be changed to reflect this. They currently support what I thought > > user will get, not what you describe above. > > The option name and documentation is fine. See above.