From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1702 invoked by alias); 24 Jan 2015 00:32:36 -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 1677 invoked by uid 89); 24 Jan 2015 00:32:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f43.google.com Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 24 Jan 2015 00:32:32 +0000 Received: by mail-wg0-f43.google.com with SMTP id y19so364635wgg.2 for ; Fri, 23 Jan 2015 16:32:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.19 with SMTP id d19mr18969992wjr.48.1422059549791; Fri, 23 Jan 2015 16:32:29 -0800 (PST) Received: by 10.27.39.198 with HTTP; Fri, 23 Jan 2015 16:32:29 -0800 (PST) In-Reply-To: <83wq4ds0lh.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> Date: Sat, 24 Jan 2015 08:50:00 -0000 Message-ID: Subject: Re: [PATCH 3/3 v2] Implement completion limiting From: Doug Evans To: Eli Zaretskii Cc: Gary Benson , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00663.txt.bz2 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. >> And in that particular and massively rare case, >> once gdb has found N, how much extra work will >> be performed searching the entire executable >> and all its shared libraries just to verify there are >> in fact no more completions? >> [because that's what has to happen if >> we're to avoid printing *any* message] >> >> The user waits 5 minutes for the entire list and >> gets her 200 completions, and wonders >> why it took so long. Then she digs a bit >> deeper and finds out they were found >> in the first 5 seconds. Ugh. > > 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. If I do "set max-completions N" I expect gdb to stop looking when it gets to N. >> 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. If I do "set max-completions 42" I expect gdb to stop looking when it finds 42 completions. It's a rather straightforward interpretation of the option's name IMO.