On Thu, Aug 14, 2008 at 04:04:55PM -0700, Junio C Hamano wrote:
quoted text
> Petr Baudis <pasky@suse.cz> writes:
> 
> > My point still stands - in case of binary units, we should always
> > consistently use the i suffix. So having an example in the commit
> > message that advertises "bps" is simply wrong when it should read "iB/s"
> > (like it does with the current progress.c code).
> >
> > I may sound boring, but it seems to me that you're still ignoring my
> > point quitly without proper counter-argumentation and I think it's an
> > important want, and since it's so hard to keep things consistent across
> > the wide Git codebase, we should do all we can to keep it.
> 
> I pretty much agree with everything you said in this thread.  In addition,
> I wonder if we would want to be able to say:
> 
> 	960 bps
>         0.9 KiB/s
> 	2.3 MiB/s

I dont hink it would be a big deal to say bytes/s or B/s (which is as
long as bps).

quoted text
> IOW, I do not think it is a good idea to have the list of "prefixes" in
> this function and force callers to _append_ unit.  You might be better off
> by making the interface to the function to pass something like this:
> 
> 	struct human_unit {
> 		char *unitname;
>                 unsigned long valuescale;
> 	} bps_to_human[] = {
>         	{ "bps", 1 },
>                 { "KiB/s", 1024 },
>                 { "MiB/s", 1024 * 1024 },
>                 { NULL, 0 },
> 	};
> 
> and perhaps give canned set of unit list for sizes and throughputs as
> convenience.
> 
> By doing so, you could even do this:
> 
> 	struct human_unit bits_to_human[] = {
>         	{ "bits", 1 },
>                 { "bytes", 8 },
>                 { "Kbytes", 8 * 1024 },
>                 { "Mbytes", 8 * 1024 * 1024 },
>                 { NULL, 0 },
> 	};

Frankly, my gut feeling here is that we are overengineering the whole
thing quite a bit, which is the same reason I dislike maxlen.

If it turns out we really do need to have custom prefixes somewhere, we
would have to go with something like this, but on the other hand this
goes against the consistency of output, and I have a bit of trouble
imagining a convincing use-case. So far we have two fairly different
users of such a code and just tailoring it to these two seems to make it
general enough for now.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html