threads / patch / 14990

patchcount-objects: Add total pack size to verbose output

Subject: [PATCH] count-objects: Add total pack size to verbose output

## tl;dr

18 messages between Aug 13, 2008 and Aug 18, 2008. Diffs are folded; open one to read it.

replies: 17people: 8as markdown or json

Marcus Griep· Aug 13, 2008, 20:05 UTC · lore

Adds the total pack size (including indexes) the verbose count-objects output, floored to the nearest kilobyte.

Signed-off-by: Marcus Griep <marcus@griep.us>
---
 I used the pack size including the size of the associated indexes in
 computing total pack size since it more closely represents the disk
 usage of each pack. If separate reporting is preferred, they can be
 split apart.
 builtin-count-objects.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
Show changes to builtin-count-objects.c +3 −0
diff --git a/builtin-count-objects.c b/builtin-count-objects.c
index 91b5487..249040b 100644
--- a/builtin-count-objects.c
+++ b/builtin-count-objects.c
@@ -104,6 +104,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
 	if (verbose) {
 		struct packed_git *p;
 		unsigned long num_pack = 0;
+		unsigned long size_pack = 0;
 		if (!packed_git)
 			prepare_packed_git();
 		for (p = packed_git; p; p = p->next) {
@@ -112,12 +113,14 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
 			if (open_pack_index(p))
 				continue;
 			packed += p->num_objects;
+			size_pack += p->pack_size + p->index_size;
 			num_pack++;
 		}
 		printf("count: %lu\n", loose);
 		printf("size: %lu\n", loose_size / 2);
 		printf("in-pack: %lu\n", packed);
 		printf("packs: %lu\n", num_pack);
+		printf("size-pack: %lu\n", size_pack / 1024);
 		printf("prune-packable: %lu\n", packed_loose);
 		printf("garbage: %lu\n", garbage);
 	}
-- 
1.6.0.rc2.6.g8eda3
Marcus Griep· Aug 14, 2008, 04:21 UTC · re: Marcus Griep · lore

[PATCH 2] count-objects: add human-readable size option

Adds a human readable size option to the verbose output of count-objects for loose and pack object size totals.

Updates documentation to match.
Signed-off-by: Marcus Griep <marcus@griep.us>
---
 I thought that this would be a nice addition to 'git count-objects'.
 This patch depends upon my earlier patch to count-objects, but this
 patch should be easily separable from its dependency should that one
 not be accepted.
 Documentation/git-count-objects.txt |   13 +++++++---
 builtin-count-objects.c             |   41 +++++++++++++++++++++++++++++++---
 2 files changed, 46 insertions(+), 8 deletions(-)
Show changes to 2 files +46 −8

Documentation/git-count-objects.txt, builtin-count-objects.c

diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
index 75a8da1..291bc5e 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -7,7 +7,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption
 
 SYNOPSIS
 --------
-'git count-objects' [-v]
+'git count-objects' [-v [-H]]
 
 DESCRIPTION
 -----------
@@ -21,9 +21,14 @@ OPTIONS
 --verbose::
 	In addition to the number of loose objects and disk
 	space consumed, it reports the number of in-pack
-	objects, number of packs, and number of objects that can be
-	removed by running `git prune-packed`.
-
+	objects, number of packs, disk space consumed by those packs
+	and number of objects that can be removed by running
+	`git prune-packed`.
+
+-H::
+--human-sizes::
+	Displays sizes reported by `--verbose` in a more
+	human-readable format. (e.g. 22M or 1.5G)
 
 Author
 ------
diff --git a/builtin-count-objects.c b/builtin-count-objects.c
index 249040b..1eb73be 100644
--- a/builtin-count-objects.c
+++ b/builtin-count-objects.c
@@ -67,13 +67,30 @@ static void count_objects(DIR *d, char *path, int len, int verbose,
 }
 
 static char const * const count_objects_usage[] = {
-	"git count-objects [-v]",
+	"git count-objects [-v [-H]]",
 	NULL
 };
 
+void human_readable_size(char *buf, int buf_size, double size /* in bytes */)
+{
+	char human_readable_prefixes[10] = "BKMGTPEZY";
+	if (buf_size < 5)
+		die("insufficient buffer size");
+	int i = 0;
+	for (; i < 8 && size >= 1000 ; ++i, size = size / 1024)
+		;
+	if (size >= 1000)
+		die("size greater than 999Y");
+	sprintf(buf, "%.*f%c",
+		size < 10 ? 1 : 0,
+		size,
+		human_readable_prefixes[i]
+		);
+}
+
 int cmd_count_objects(int argc, const char **argv, const char *prefix)
 {
-	int i, verbose = 0;
+	int i, verbose = 0, human_readable = 0;
 	const char *objdir = get_object_directory();
 	int len = strlen(objdir);
 	char *path = xmalloc(len + 50);
@@ -81,6 +98,8 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
 	unsigned long loose_size = 0;
 	struct option opts[] = {
 		OPT__VERBOSE(&verbose),
+		OPT_BOOLEAN('H', "--human-sizes", &human_readable,
+			"displays sizes in human readable format"),
 		OPT_END(),
 	};
 
@@ -117,10 +136,24 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
 			num_pack++;
 		}
 		printf("count: %lu\n", loose);
-		printf("size: %lu\n", loose_size / 2);
+		printf("size: ");
+		if (human_readable) {
+			char buf[sizeof("999Y")];
+			human_readable_size(buf, sizeof(buf), loose_size * 512);
+			printf("%s\n", buf);
+		}
+		else
+			printf("%lu\n", loose_size / 2);
 		printf("in-pack: %lu\n", packed);
 		printf("packs: %lu\n", num_pack);
-		printf("size-pack: %lu\n", size_pack / 1024);
+		printf("size-pack: ");
+		if (human_readable) {
+			char buf[sizeof("999Y")];
+			human_readable_size(buf, sizeof(buf), size_pack);
+			printf("%s\n", buf);
+		}
+		else
+			printf("%lu\n", size_pack / 1024);
 		printf("prune-packable: %lu\n", packed_loose);
 		printf("garbage: %lu\n", garbage);
 	}
-- 
1.6.0.rc2.6.g8eda3
Shawn O. Pearce· Aug 14, 2008, 04:38 UTC · re: Marcus Griep · lore

Re: [PATCH 2] count-objects: add human-readable size option

Marcus Griep <marcus@griep.us> wrote:
Show 5 quoted lines
> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
> index 75a8da1..291bc5e 100644
> --- a/Documentation/git-count-objects.txt
> +++ b/Documentation/git-count-objects.txt
> +++ b/builtin-count-objects.c
...
> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */)

Hmm. This probably should be static. Or if it really is meant to be a utility for use elsewhere in Git, moved to someplace where string handling is done. Its not strbuf related, but maybe strbuf.c is a better location for this sort of library function.

If you do move this to strbuf.c, how about having it take a strbuf in and appending the formatted text onto it? You'll neer have to worry about the buffer being too small and it fits into the whole strbuf.c module thing.

If you keep this static here in builtin-count-objects.c, how about making the char *buf static scoped to the function, so you don't need to pass the buffer, its size, nor check its size?

Show 5 quoted lines
> +{
> +	char human_readable_prefixes[10] = "BKMGTPEZY";
> +	if (buf_size < 5)
> +		die("insufficient buffer size");
> +	int i = 0;

We don't declare variables after statements. Please declare all variables at the start of the block as not all compilers we support support this C99 syntax.

Oh, and welcome to Git. I saw your SVN patches. Glad to see you hacking. ;-)

Show 11 quoted lines
> +	for (; i < 8 && size >= 1000 ; ++i, size = size / 1024)
> +		;
> +	if (size >= 1000)
> +		die("size greater than 999Y");
> +	sprintf(buf, "%.*f%c",
> +		size < 10 ? 1 : 0,
> +		size,
> +		human_readable_prefixes[i]
> +		);
> +}
> +
-- 
Shawn.
Marcus Griep· Aug 14, 2008, 04:44 UTC · re: Shawn O. Pearce · lore

Re: [PATCH 2] count-objects: add human-readable size option

Shawn O. Pearce wrote:
Show 13 quoted lines
> Hmm.  This probably should be static.  Or if it really is meant
> to be a utility for use elsewhere in Git, moved to someplace where
> string handling is done.  Its not strbuf related, but maybe strbuf.c
> is a better location for this sort of library function.
> 
> If you do move this to strbuf.c, how about having it take a strbuf
> in and appending the formatted text onto it?  You'll neer have to
> worry about the buffer being too small and it fits into the whole
> strbuf.c module thing.
> 
> If you keep this static here in builtin-count-objects.c, how about
> making the char *buf static scoped to the function, so you don't
> need to pass the buffer, its size, nor check its size?

I'll take this into account. Though I didn't plan it to be a cross-git utility function, it probably could be, so I'll look at putting it in strbuf.c.

> We don't declare variables after statements.  Please declare all
> variables at the start of the block as not all compilers we support
> support this C99 syntax.

This is the first time I've hacked on vanilla-C in about 5 years, so I'm quite rusty. Much less my first time hacking on perl, ever, in the case of git-svn. Thanks for the pointers.

> Oh, and welcome to Git.  I saw your SVN patches.  Glad to see
> you hacking.  ;-)
Glad to be a part.
-- 
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
Junio C Hamano· Aug 14, 2008, 05:22 UTC · re: Shawn O. Pearce · lore

Re: [PATCH 2] count-objects: add human-readable size option

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 13 quoted lines
> Marcus Griep <marcus@griep.us> wrote:
>> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
>> index 75a8da1..291bc5e 100644
>> --- a/Documentation/git-count-objects.txt
>> +++ b/Documentation/git-count-objects.txt
>> +++ b/builtin-count-objects.c
> ...
>> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */)
>
> Hmm.  This probably should be static.  Or if it really is meant
> to be a utility for use elsewhere in Git, moved to someplace where
> string handling is done.  Its not strbuf related, but maybe strbuf.c
> is a better location for this sort of library function.

Yes, with customizable precision (so that the caller can control "1.6k" vs "1.62k"), and perhaps cutomizable unit (so that you can use this for "3.6kB" and "2.6Mbps"), this kind of thing is a good candidate to be a library function in strbuf.c.

>> +{
>> +	char human_readable_prefixes[10] = "BKMGTPEZY";

This enumerates suffix if I am not mistaken. Do you have to say "10" here, or does the compiler counts them for you?

>> +	for (; i < 8 && size >= 1000 ; ++i, size = size / 1024)
>> +		;
I do not think you would need to use the magic number "8" here.

I have this suspicion that the caller, if this is made into a generic library, would want to pass in a list of units, not magnitude suffixes, like this:

    extern int human_readable(struct strbuf *,
    			      double value, int precision,
                              const char **unit);
    static const char **size_unit = {
    	"byte", "KB", "MB", "GB", NULL,
    };
    static const char **throughput_unit = {
    	"bps", "Kbps", "Mbps", "Gbps", NULL,
    };
    human_readble(&sb, (double) bytes_transferred, 0, size_unit);
    human_readble(&sb, (double) throughput, 2, throughput_unit);
Johannes Schindelin· Aug 14, 2008, 14:05 UTC · re: Junio C Hamano · lore

Re: [PATCH 2] count-objects: add human-readable size option

Hi,
On Wed, 13 Aug 2008, Junio C Hamano wrote:
Show 20 quoted lines
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Marcus Griep <marcus@griep.us> wrote:
> >> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
> >> index 75a8da1..291bc5e 100644
> >> --- a/Documentation/git-count-objects.txt
> >> +++ b/Documentation/git-count-objects.txt
> >> +++ b/builtin-count-objects.c
> > ...
> >> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */)
> >
> > Hmm.  This probably should be static.  Or if it really is meant
> > to be a utility for use elsewhere in Git, moved to someplace where
> > string handling is done.  Its not strbuf related, but maybe strbuf.c
> > is a better location for this sort of library function.
> 
> Yes, with customizable precision (so that the caller can control "1.6k" vs
> "1.62k"), and perhaps cutomizable unit (so that you can use this for
> "3.6kB" and "2.6Mbps"), this kind of thing is a good candidate to be a
> library function in strbuf.c.

Or, should it ever be merged into git.git, the strbuf_vaddf() routine I wrote.

Ciao, Dscho

Marcus Griep· Aug 14, 2008, 14:26 UTC · re: Junio C Hamano · lore

Re: [PATCH 2] count-objects: add human-readable size option

Junio C Hamano wrote:
Show 13 quoted lines
>     extern int human_readable(struct strbuf *,
>     			      double value, int precision,
>                               const char **unit);
> 
>     static const char **size_unit = {
>     	"byte", "KB", "MB", "GB", NULL,
>     };
>     static const char **throughput_unit = {
>     	"bps", "Kbps", "Mbps", "Gbps", NULL,
>     };
> 
>     human_readble(&sb, (double) bytes_transferred, 0, size_unit);
>     human_readble(&sb, (double) throughput, 2, throughput_unit);
Here's what I'm looking at as a new signature:
extern int strbuf_add_human_readable(struct strbuf *,
				double value, int maxlen,
				int scale, const char *suffix,
				int flags);

where 'maxlen' specifies the longest string that should be returned. That will make it easier for any pretty-ish formatting like ls and du use. A value of 0 is unlimited length.

'scale' is used to specify a boundary, above which value should be
reduced, and below which it should be reported. Commonly this is
1000.  If 0, then it will find a scale that best fits into 'maxlen'.
If both 'maxlen' and 'scale' are 0, then it will use the default
of 1000.

'suffix' is appended onto every formatted string. This would often be "", "B", "bps".

'flags' would provide the ability to switch between a binary (1024) and an si (1000) period. Also, adding a space between number and unit.

On success, would return 0. If maxlen is specified and there is not enough space given the scale or an inordinately large value, return -n, where n is the amount of additional length that would have been needed.

Does this sound appropriate?
-- 
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
Alex Riesen· Aug 14, 2008, 06:45 UTC · re: Marcus Griep · lore

Re: [PATCH 2] count-objects: add human-readable size option

Marcus Griep, Thu, Aug 14, 2008 06:21:24 +0200:
Show 5 quoted lines
>  SYNOPSIS
>  --------
> -'git count-objects' [-v]
> +'git count-objects' [-v [-H]]
>  
GNU ls and du use "-h", with du using -H for SI units.
Marcus Griep· Aug 14, 2008, 14:03 UTC · re: Alex Riesen · lore

Re: [PATCH 2] count-objects: add human-readable size option

Alex Riesen wrote:
> GNU ls and du use "-h", with du using -H for SI units.

git's parse options plays interference here and injects the usage and exits if it finds the '-h' option. Is there a way to get around that?

-- 
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
Alex Riesen· Aug 14, 2008, 18:51 UTC · re: Marcus Griep · lore

Re: [PATCH 2] count-objects: add human-readable size option

Marcus Griep, Thu, Aug 14, 2008 16:03:22 +0200:
Show 6 quoted lines
> Alex Riesen wrote:
> > GNU ls and du use "-h", with du using -H for SI units.
> 
> git's parse options plays interference here and injects the usage
> and exits if it finds the '-h' option.  Is there a way to get around
> that?

AFAICS - no. I'd suggest removing "-h" from the unconditionally reserved list of options (untested patch attached). "--help" is well known (which could be a reason why coreutils uses just it).

On somewhat similar note, how about be a bit _less_ user-friendly in the text messages? IOW, make things like "something didn't work, please try doing 'git something-else'" configurable (ok, active by default, by deactivatable). These take an awful lot of screen space. The builtin fetch, checkout, add (the most often used commands) are the chattiest. The text in commit buffer takes almost half of screen, too.

--
Show changes to parse-options.c +0 −4
diff --git a/parse-options.c b/parse-options.c
index fd08bb4..7f85cd7 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -267,8 +267,6 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
 
 		if (arg[1] != '-') {
 			ctx->opt = arg + 1;
-			if (*ctx->opt == 'h')
-				return parse_options_usage(usagestr, options);
 			switch (parse_short_opt(ctx, options)) {
 			case -1:
 				return parse_options_usage(usagestr, options);
@@ -278,8 +276,6 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
 			if (ctx->opt)
 				check_typos(arg + 1, options);
 			while (ctx->opt) {
-				if (*ctx->opt == 'h')
-					return parse_options_usage(usagestr, options);
 				switch (parse_short_opt(ctx, options)) {
 				case -1:
 					return parse_options_usage(usagestr, options);
Pierre Habouzit· Aug 15, 2008, 09:22 UTC · re: Alex Riesen · lore

Re: [PATCH 2] count-objects: add human-readable size option

On Thu, Aug 14, 2008 at 06:51:31PM +0000, Alex Riesen wrote:
Show 11 quoted lines
> Marcus Griep, Thu, Aug 14, 2008 16:03:22 +0200:
> > Alex Riesen wrote:
> > > GNU ls and du use "-h", with du using -H for SI units.
> > 
> > git's parse options plays interference here and injects the usage
> > and exits if it finds the '-h' option.  Is there a way to get around
> > that?
> 
> AFAICS - no. I'd suggest removing "-h" from the unconditionally
> reserved list of options (untested patch attached). "--help" is well
> known (which could be a reason why coreutils uses just it).
  But --help is not as terse as -h is, and it would be going backwards
not having it anymore.
Show 7 quoted lines
> On somewhat similar note, how about be a bit _less_ user-friendly in
> the text messages? IOW, make things like "something didn't work,
> please try doing 'git something-else'" configurable (ok, active by
> default, by deactivatable). These take an awful lot of screen space.
> The builtin fetch, checkout, add (the most often used commands) are
> the chattiest. The text in commit buffer takes almost half of screen,
> too.
  We probably want to reorganize some of our options so that it's less
verbose, but FWIW I prefer the git foo -h wrt git foo --help because I
usually *know* there is an option, and git foo -h is way easier to grep
with the eye than the man page.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Alex Riesen· Aug 18, 2008, 17:28 UTC · re: Pierre Habouzit · lore

Re: [PATCH 2] count-objects: add human-readable size option

Pierre Habouzit, Fri, Aug 15, 2008 11:22:50 +0200:
> 
> But --help is not as terse as -h is, and it would be going backwards
> not having it anymore.
> 

BTW, ls-remote (which is not ported to the options handling code yet) also has "-h" (short for "--heads").

Johannes Sixt· Aug 14, 2008, 07:39 UTC · re: Marcus Griep · lore

Re: [PATCH 2] count-objects: add human-readable size option

Marcus Griep schrieb:
Show 10 quoted lines
> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */)
> +{
> +	char human_readable_prefixes[10] = "BKMGTPEZY";
> +	if (buf_size < 5)
> +		die("insufficient buffer size");
> +	int i = 0;
> +	for (; i < 8 && size >= 1000 ; ++i, size = size / 1024)
> +		;
> +	if (size >= 1000)
> +		die("size greater than 999Y");

No need to die here. Just make the buffer large enough, and you can have something that is as large as 18446744073709551615Y.

-- Hannes
Marcus Griep· Aug 14, 2008, 14:09 UTC · re: Johannes Sixt · lore

Re: [PATCH 2] count-objects: add human-readable size option

Johannes Sixt wrote:
> No need to die here. Just make the buffer large enough, and you can have
> something that is as large as 18446744073709551615Y.

In my initial rendition, the output was guaranteed not to be longer than 5 characters. However, you're right that there's no need to die, but perhaps just return a negative value equal to the size over the user's requested maxlen.

-- 
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
Petr Baudis· Aug 14, 2008, 15:14 UTC · re: Marcus Griep · lore

Re: [PATCH 2] count-objects: add human-readable size option

On Thu, Aug 14, 2008 at 12:21:24AM -0400, Marcus Griep wrote:
Show 16 quoted lines
> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */)
> +{
> +	char human_readable_prefixes[10] = "BKMGTPEZY";
> +	if (buf_size < 5)
> +		die("insufficient buffer size");
> +	int i = 0;
> +	for (; i < 8 && size >= 1000 ; ++i, size = size / 1024)
> +		;
> +	if (size >= 1000)
> +		die("size greater than 999Y");
> +	sprintf(buf, "%.*f%c",
> +		size < 10 ? 1 : 0,
> +		size,
> +		human_readable_prefixes[i]
> +		);
> +}

Are you aware of progress.c:throughput_string()? It would make sense to use the same code in both instances.

I'd prefer you to keep using binary units instead of the ambiguous prefixes, since we should keep our output consistent and I believe they usually end up to be the least confusing choice. (Otherwise, don't you want to use "bkM" instead of "BKM"? I never really know.)

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates
Marcus Griep· Aug 14, 2008, 16:26 UTC · re: Petr Baudis · lore

Re: [PATCH 2] count-objects: add human-readable size option

Petr Baudis wrote:
> Are you aware of progress.c:throughput_string()? It would make sense to
> use the same code in both instances.

I was not. After reviewing it, it is limited to its purposes (who's got transfer speeds in TiB/s?), but consolidating the human-readable-ness is a good idea.

> I'd prefer you to keep using binary units instead of the ambiguous
> prefixes, since we should keep our output consistent and I believe they
> usually end up to be the least confusing choice. (Otherwise, don't you
> want to use "bkM" instead of "BKM"? I never really know.)

In general, "b" would be supplied as a part of the suffix, so that is no longer in the prefix list. The distinction comes with kilo vs. kibi. In an earlier email reply, I mentioned a flag to denote SI versus binary periods. In common nomenclature, Kilo (1000) is designated 'k', while Kibi (1024) is designated 'K' (the 'i' after the 'K' is supplied by the suffix if desired). Thus, if the user wants binary, they'll get the capital 'K', and if they want SI, they'll get the lowercase 'k'.

Sound reasonable?
-- 
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
Petr Baudis· Aug 14, 2008, 16:34 UTC · re: Marcus Griep · lore

Re: [PATCH 2] count-objects: add human-readable size option

On Thu, Aug 14, 2008 at 12:26:49PM -0400, Marcus Griep wrote:
Show 6 quoted lines
> Petr Baudis wrote:
> > Are you aware of progress.c:throughput_string()? It would make sense to
> > use the same code in both instances.
> 
> I was not. After reviewing it, it is limited to its purposes, but
> consolidating the human-readable-ness is a good idea.

Of course, it would need an usage overhaul. But otherwise, it seems fine? Terabyte-sized objects in Git would be very troublesome venture for many reasons.

> (who's got transfer speeds in TiB/s?)
Maybe Dana Brown? ;-)
Show 14 quoted lines
> > I'd prefer you to keep using binary units instead of the ambiguous
> > prefixes, since we should keep our output consistent and I believe they
> > usually end up to be the least confusing choice. (Otherwise, don't you
> > want to use "bkM" instead of "BKM"? I never really know.)
> 
> In general, "b" would be supplied as a part of the suffix, so that is no
> longer in the prefix list.  The distinction comes with kilo vs. kibi.  In
> an earlier email reply, I mentioned a flag to denote SI versus binary
> periods.  In common nomenclature, Kilo (1000) is designated 'k', while
> Kibi (1024) is designated 'K' (the 'i' after the 'K' is supplied by the
> suffix if desired).  Thus, if the user wants binary, they'll get the capital
> 'K', and if they want SI, they'll get the lowercase 'k'.
> 
> Sound reasonable?

I'm confused - you didn't seem to really address my suggestion. Is there a good reason _not_ to go with the /.iB/ prefixes, and just forget about SI? Who is ever going to need SI?

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates
Marcus Griep· Aug 14, 2008, 16:42 UTC · re: Petr Baudis · lore

Re: [PATCH 2] count-objects: add human-readable size option

Petr Baudis wrote:
> I'm confused - you didn't seem to really address my suggestion. Is there
> a good reason _not_ to go with the /.iB/ prefixes, and just forget about
> SI? Who is ever going to need SI?

It's more of a not limiting support, but in the spirit of YAGNI, I can forget about SI until we find some reason to actually want it, and then add it at that point.

As for the /.iB/ prefixes, other than the actual magnitude prefix, 'iB', 'B', 'bps', etc. would be supplied as a suffix by the consumer so as not to assume that we will be formatting bytes or widgets, since conceivably you may want to know that there are 203k objects (which would be an SI use) or are transferring at a rate of 1.6k blobs/s.

In which case, it might be preferable to leave the SI in, since it would allow more than just bytes to be formatted in shorter, human-readable form.

-- 
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´

← back to recent threads