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_S
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?=
Date: Tue, 30 Jun 2009 00:52
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
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
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 s
Pádraig Brady wrote:
>>From 75bb07bb620d37d26467ab86ffcf73d47479b358 Mon Sep 17 00:00:00 2001
> From: Michael Speer
> 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
> * doc/coreutils.texi (sort
Jim Meyering wrote:
> Pádraig Brady wrote:
>> Eric Blake wrote:
>>> Pádraig Brady 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, [
Pádraig Brady wrote:
> Eric Blake wrote:
>> Pádraig Brady 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,
>> +
On May 21, 2009 5:07pm, Giuseppe Scrivano 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 readable options th
Pádraig Brady 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 normalize values using
Eric Blake wrote:
> Pádraig Brady 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)
> +{
> + st
Pádraig Brady 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]
knome@gmail.com wrote:
> On Apr 27, 2009 11:27am, Pádraig Brady 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 distributio
On Apr 27, 2009 11:41am, Ondřej Vašík 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 the code in add
knome@gmail.com wrote:
> On Apr 27, 2009 11:41am, Ondřej Vašík 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
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 inte
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() a
Michael Speer wrote:
> 2009/4/25 Pádraig Brady :
>> 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
Michael Speer wrote:
> 2009/4/25 Pádraig Brady :
>> 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
2009/4/25 Pádraig Brady :
>
> 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. It will still l
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.
>> Som
2009/4/24 Pádraig Brady :
> 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 v
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
>
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 coreu
24 matches
Mail list logo