Re: [PATCH 1/2] strbuf: create strbuf_humanize() to show byte sizes
- From
Antoine Pelisse <apelisse@gmail.com>
- Date
- Apr 10, 2013, 20:12 UTC
- Message-ID
- <CALWbr2w=q=BkMOeqmSAbi50vNbup+e9GF0gdxNH9-vpyyND5Vw@mail.gmail.com>
- In-Reply-To
- <7vr4iikvkd.fsf@alter.siamese.dyndns.org>
On Wed, Apr 10, 2013 at 9:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 17 quoted lines
> Antoine Pelisse <apelisse@gmail.com> writes: > >> Currently, humanization of downloaded size is done in the same >> function as text formatting in 'process.c'. This is an issue if anyone >> else wants to use this. >> >> Separate text formatting from size simplification and make the function >> public in strbuf so that it can easily be used by other clients. >> >> We now can use strbuf_humanize() for both downloaded size and download >> speed calculation. One of the drawbacks is that speed will now look like >> this when download is stalled: "0 bytes/s" instead of "0 KiB/s". > > Personally, I do not think the "drawback" is so big an issue. If > the caller really cares, we could always add another parameter to > this formatter to tell it the minimum unit we care about (e.g. pass > 1024 to say "Don't bother showing scale lower than kibi").
I thought about that, but decided it was not worth it (at least for the moment)
Show 5 quoted lines
> This is a bit late response, but if we ever want to count something > in a dimention other than "bytes", like time (e.g. "kiloseconds") or > number of commits (e.g. "centicommits"), etc., we cannot reuse this > formatter very easily. We may want to have "byte" somewhere in its > name for now to make sure the callers understand its limitation.
I'm not in a hurry. But it look tough to make it generic: one is binary, another is sexagesimal, and the last is decimal
> I'll tentatively rename it to "strbuf_humanize_bytes()" while queuing.
I like the idea, Thanks,