Re: [PATCH 1/1] Improve progress display in kB range.

From: Nicolas Pitre <nico@cam.org>
Date: Apr 21, 2009, 17:28 UTC
Message-ID: <alpine.LFD.2.00.0904211319570.6741@xanadu.home>
In-Reply-To: <m3skk2szgv.fsf@lugabout.jhcloos.org>

On Tue, 21 Apr 2009, James Cloos wrote:

Show 16 quoted lines

> >>>>> "Nicolas" == Nicolas Pitre <nico@cam.org> writes:
> 
> Nicolas> On Sun, 19 Apr 2009, James Cloos wrote:
> >> When progress.c:throughput_string() is called, the variable total
> >> invariably has its twelve least significant bits set.  Ie, it is
> >> always the case that:
> >> 
> >> total & 0xFFF == 0xFFF
> 
> Nicolas> Could you please explain ow you come to that conclusion?
> 
> Empirical evidence.
> 
> Even since the current progress was added, it has always shown nn.99 KiB
> in that range.  I added an extra snprintf(3) to show total in hex and it
> always ends in FFF.

Empirical evidence on my side shows the opposite. I just did a fetch in my kernel repo and got:

   Receiving objects: 100% (1373/1373), 223.36 KiB, done.

> I presume the progress function is getting called just before total hits
> a page boundry.  In any case, the empirical evidence is clear.  And only
> even seeing .99 is annoying.  Hense the proposed patch.

I must NACK your patches. Presumptions are not good enough justification for such a change, especially if results can't be reproduced. That doesn't mean the code is completely bug free of course, but finding the source of the bug affecting you would be a far better course of action than simply turning our back on it. Maybe you can tell us more about your environment?

Nicolas