Pádraig Brady wrote:
I was thinking that the mixed IEC/SI check
should be applied to each key separately rather
than globally. What do you think? Patch attached.
From ef06a30d122fc9ccac51a682a3abf6868d8832d6 Mon Sep 17 00:00:00 2001
...
-check_mixed_SI_IEC (char prefix)
+check_mixed_SI_IEC
I was thinking that the mixed IEC/SI check
should be applied to each key separately rather
than globally. What do you think? Patch attached.
cheers,
Pádraig.
From ef06a30d122fc9ccac51a682a3abf6868d8832d6 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date:
Pádraig Brady wrote:
Latest version attached.
...
* NEWS: Document the new option
* doc/coreutils.texi (sort invocation): ditto
* src/sort.c (main): handle the new --human-numeric-sort option (-h).
(human_numcompare): A new function to compare SI and IEC suffixes
before falling back to the
Jim Meyering wrote:
Please make one small change to that log message:
s/ -human/ --human/
And in the documentation,
+Sort numerically, as per the @option{--numeric-sort} option,
+and in addition handle IEC or SI suffixes like MiB, MB etc.
+Note a mixture of these suffixes
Jim Meyering wrote:
Maybe s/unambiguously/consistently/
or /uniformly/
and mention that it's the inconsistent precision that causes trouble.
J. Random Bystander (i.e. me) prefers consistently. (Consistent, as
in, using the same rules. Uniformly to me suggests maybe some
Pádraig Brady wrote:
Eric Blake wrote:
Pádraig Brady P at draigBrady.com writes:
...
+static int
+find_unit_order (const char *number)
+{
+ static const char orders [UCHAR_LIM] = {
+['K']=1, ['M']=2, ['G']=3, ['T']=4, ['P']=5, ['E']=6, ['Z']=7, ['Y']=8,
+['k']=1,
+ };
This
Jim Meyering wrote:
Pádraig Brady wrote:
Eric Blake wrote:
Pádraig Brady P at draigBrady.com writes:
...
+static int
+find_unit_order (const char *number)
+{
+ static const char orders [UCHAR_LIM] = {
+['K']=1, ['M']=2, ['G']=3, ['T']=4, ['P']=5, ['E']=6, ['Z']=7, ['Y']=8,
+
Pádraig Brady wrote:
From 75bb07bb620d37d26467ab86ffcf73d47479b358 Mon Sep 17 00:00:00 2001
From: Michael Speer knome...@gmail.com
Date: Mon, 27 Apr 2009 14:51:29 +0100
Subject: [PATCH] sort: new --human-numeric-sort option to sort KiB MB etc.
* NEWS: Document the new option
*
knome@gmail.com wrote:
On Apr 27, 2009 11:27am, Pádraig Brady p...@draigbrady.com wrote:
It seems like you'll need to go through the copyright assignment
I will start this process as soon as possible.
The -h seems to run faster than -n on my data, but only because I gave
an even
Pádraig Brady P at draigBrady.com writes:
Looks like your copyright assignment papers went through.
Attached is the latest patch rebased against master
and with a couple of extra whitespace fixups.
+static int
+find_unit_order (const char *number)
+{
+ static const char orders [UCHAR_LIM]
Eric Blake wrote:
Pádraig Brady P at draigBrady.com writes:
Looks like your copyright assignment papers went through.
Attached is the latest patch rebased against master
and with a couple of extra whitespace fixups.
+static int
+find_unit_order (const char *number)
+{
+ static const
Pádraig Brady p...@draigbrady.com writes:
+ Assume that numbers are properly abbreviated.
+ i.e. input will never have both 5000K and 6M. */
I think this is a too strong assumption. I wouldn't be surprised to
find, for example, both 1M and 1500K in a data set.
Are there problems to
On May 21, 2009 5:07pm, Giuseppe Scrivano gscriv...@gnu.org wrote:
I think this is a too strong assumption. I wouldn't be surprised to
find, for example, both 1M and 1500K in a data set.
I initiated this to patch sort primarily to support the data generated by
df, du and ls. The human
Michael Speer wrote:
2009/4/25 Pádraig Brady p...@draigbrady.com:
I've further modified your latest in the attached.
I refactored the suffix finding a bit and also added
support for --sort=human-numeric.
I refactored it again to handle some potential problems with how
separators and
Pádraig Brady wrote:
seconds to sort 1 million ints:
---
sort optiontime difference
---
-n 2.75
-h (ret 0) 3.10 +13%
-h 3.96 +44%
I removed a redundant to_uchar() and got
Pádraig Brady wrote:
Pádraig Brady wrote:
Attached is the full patch, which hopefully we can push soon.
I'm not objecting anything relevant in that patch, just the tab/spaces
mixing looks inconsistent with the rest of the code in added lines in
sort.c . Only cosmetic thing ... but is this
knome@gmail.com wrote:
On Apr 27, 2009 11:41am, Ondřej Vašík ova...@redhat.com wrote:
Pádraig Brady wrote:
Pádraig Brady wrote:
Attached is the full patch, which hopefully we can push soon.
I'm not objecting anything relevant in that patch, just the tab/spaces
mixing looks
On Apr 27, 2009 11:41am, Ondřej Vašík ova...@redhat.com wrote:
Pádraig Brady wrote:
Pádraig Brady wrote:
Attached is the full patch, which hopefully we can push soon.
I'm not objecting anything relevant in that patch, just the tab/spaces
mixing looks inconsistent with the rest of
Michael Speer wrote:
2009/4/25 Pádraig Brady p...@draigbrady.com:
I've further modified your latest in the attached.
I refactored the suffix finding a bit and also added
support for --sort=human-numeric.
I refactored it again to handle some potential problems with how
separators and
2009/4/24 Pádraig Brady p...@draigbrady.com:
Michael Speer wrote:
I wrote the following patch to the 7.2 branch of coreutils to allow
`sort` to sort by human readable byte sizes. I looked around a bit to
see what the status of previous attempts to integrate this
functionality were, but
Michael Speer wrote:
That's much more readable. I tacked in a size.
Good catch. The size is required or otherwise
one could get undefined results for some chars.
The standards do not
reference the lowercase letters you commented out, so I just deleted
them outright.
Fair enough.
2009/4/25 Pádraig Brady p...@draigbrady.com:
I've further modified your latest in the attached.
I refactored the suffix finding a bit and also added
support for --sort=human-numeric.
I refactored it again to handle some potential problems with how
separators and decimals points were handled.
I wrote the following patch to the 7.2 branch of coreutils to allow
`sort` to sort by human readable byte sizes. I looked around a bit to
see what the status of previous attempts to integrate this
functionality were, but didn't see any very recent activity. This is
my first interaction with
Michael Speer wrote:
I wrote the following patch to the 7.2 branch of coreutils to allow
`sort` to sort by human readable byte sizes. I looked around a bit to
see what the status of previous attempts to integrate this
functionality were, but didn't see any very recent activity. This is
my
24 matches
Mail list logo
