From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id rJEmAEzUDGKPLQAAWB0awg (envelope-from ) for ; Wed, 16 Feb 2022 05:39:08 -0500 Received: by simark.ca (Postfix, from userid 112) id D9EF51F3C9; Wed, 16 Feb 2022 05:39:07 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B01181EDF0 for ; Wed, 16 Feb 2022 05:39:06 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AE0633857C66 for ; Wed, 16 Feb 2022 10:39:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AE0633857C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1645007945; bh=XBsBCaMpiTebpEPQXbf4i8YUNJgXj+arvmGU9ZyL/EU=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=mNOyHL0wWUmjWXrIwx3cyPmwkbbqLdbcdydSUnMGCrBL1yTw5tm0ovsTkrW9tdA3d aK9cnll2p3Dg1G1yNlxByr5UkorIthwd497qTgSow2pCIY7t/omXwLYvg+uCubmFrf mhIHxg9x4QEICf8+v4jmrhBhsbHVUR1PQlJEKv+0= Received: from jupiter.monnerat.net (jupiter.monnerat.net [46.226.111.226]) by sourceware.org (Postfix) with ESMTPS id 45BE53858D3C for ; Wed, 16 Feb 2022 10:38:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 45BE53858D3C Received: from [192.168.0.128] ([192.168.0.128]) by jupiter.monnerat.net (8.14.8/8.14.8) with ESMTP id 21GAcZI8025949 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=OK); Wed, 16 Feb 2022 11:38:41 +0100 DKIM-Filter: OpenDKIM Filter v2.10.3 jupiter.monnerat.net 21GAcZI8025949 Message-ID: <5e6194e4-3a83-e169-0c9a-5858c993bf59@monnerat.net> Date: Wed, 16 Feb 2022 11:38:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v3] gdb: Improve debuginfod progress updates Content-Language: en-US To: Aaron Merey References: <20220126005817.56356-1-amerey@redhat.com> <20220209022548.343785-1-amerey@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Patrick Monnerat via Gdb-patches Reply-To: Patrick Monnerat Cc: Tom Tromey , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi Aaron, On 2/16/22 03:09, Aaron Merey wrote: > Thanks for taking another look. You're welcome. >>> + /* Transfer size is known. */ >>> + double percent = (double)cur / (double)total; >> The variable name is confusing as it is <= 1.0. > update_progress_percent uses the name "howmuch" for this. It would be > better if "howmuch" was used here too. Good choice. >>> + if (percent >= 0.0 && percent <= 1.0) >> I don't think this test is needed: cur and total are obtained >> (indirectly) from curl and IMHO you can trust it. > I've experienced at least one case where percent was > 1.0. I haven't > been able to reproduce it because it seemed to coincide with a network > hiccup. Very strange! TCP is supposed to guarantee no duplicate data reception. If this really occurs, debuginfo data are probably corrupted too! > + progress_update object. */ > + void update_progress_bar (double howmuch) >> This is never called! why do you provide both PERCENT and (unused) BAR? >> This is a bit confusing. > The progress update message originally included the bar but I now want to > only print messages that fit entirely on one line. This makes it possible > to rewrite an entire message with transfer size information once it becomes > available. Because the progress bar was already implemented I figured I'd > leave it in case it ends up serving a purpose in the future. Thanks for this precision. Maybe put it in a comment? Cheers, Patrick