On Monday 22 September 2008 14:36:02 Eric Blake wrote:
> On the other hand, the fact that strverscmp provides a distinction based
> on leading zeros is nice, as it guarantees a stable sort (no two strings
> that differ on strcmp will compare equal with strverscmp).
Good point, thanks.
The function
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 9/22/2008 6:21 AM:
> Kamil, you may expect to use the new function in ls, too.
> The more I think of this, the more I'm convinced producing
> sensible results is what matters here. Being completely
> compatible with older
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Kamil,
>> New version of filevercmp.c is attached, now without copying of the input
>> strings. I've also made a simple performance test - the speed was about 7-8x
>> slower than original glibc strverscmp function, but the glibc's result is
>> mostly wro
Way back on Sep 06, you wrote:
> IMHO, changing sort -V to produce more intuitively-correct results
> is the way to go
Well, as the author and contributor of the ``sort -V'' hack
I do have to agree. Since changing glibc is not happening,
I recommend using the putative verrevcmp() in sort(1) inst
Ben Pfaff wrote:
> Ian Jackson is the author and maintainer of other GNU software
> (GNU adns), so he might be willing to assign copyright to that
> function to the FSF. Have you asked him?
Would you care to ask him? (Not always me :-))
Bruno
Bruno Haible <[EMAIL PROTECTED]> writes:
>Kamil Dudka <[EMAIL PROTECTED]> writes:
>> There was something like "Copyright (C) 1995 Ian Jackson" in original file,
>> but also "... under terms of GNU General Public License..." I am not lawyer
>> and don't understand such details :-)
>
> So it's not
Hi Kamil,
> New version of filevercmp.c is attached, now without copying of the input
> strings. I've also made a simple performance test - the speed was about 7-8x
> slower than original glibc strverscmp function, but the glibc's result is
> mostly wrong.
If you didn't get feedback from Jim,
On Wednesday 17 September 2008 13:13:03 you wrote:
> - Fix the obvious bugs, for example, you need to cast 'char' values to
> 'unsigned char' before passing them to functions.
> - Streamline the operation: Can't you get rid of copying the two strings?
> For example, by changing verrevc
Hello Bruno,
thanks for excellent review. When the function's behavior is definitely
accepted by people here, I will improve its implementation.
On Wednesday 17 September 2008 13:13:03 you wrote:
> There are still a few things to do before we can add it to gnulib:
> - Do you have a copyright a
Hello Kamil,
Kamil Dudka wrote:
> I ran a few series of tests with all implementations. I think the
> modified version of ververcmp (from dpkg) gives the best results - consider
> attached results of an example - results.tar.bz2
I agree, out-deb-patched matches most closely what one would expec
On Sunday 07 September 2008 08:28:11 Jim Meyering wrote:
> IMHO, changing sort -V to produce more intuitively-correct results
> is the way to go.
>
> With ls -v, I'm willing to make the change as well, *assuming*
> no one produces a counterargument.
>
> The question is what ordering function to use
Ondřej Vašík <[EMAIL PROTECTED]> wrote:
> as reported in RH bugzilla #253817
> (https://bugzilla.redhat.com/show_bug.cgi?id=253817), there is an issue
> with ls -v (and there will be same issue with sort -V soon). Problem is
> with sorting files with extensions or dist-tags (like .tar.gz)
> because
On Thursday 04 September 2008 00:52:08 you wrote:
> We cannot take this patch, as the gnulib strverscmp function is meant to be
> a substitute for the glibc function of the same name. (Sorry, the doc was
> not clear about it until today.) This means, gnulib's strverscmp needs to
> behave the same a
Ondřej Vašík wrote:
> > Does rpmvercmp have the above property?
>
> Similar. It separates name, epoch, version, release and architecture and
> compares those. Uses subsections of alphanum segments separated by
> non-alphanum chars. When same segment have different types, numeric is
> always consid
Kamil Dudka wrote:
> I propose a simple patch for gnulib/strverscmp, which make this function much
> more useful.
We cannot take this patch, as the gnulib strverscmp function is meant to be
a substitute for the glibc function of the same name. (Sorry, the doc was not
clear about it until today.)
I propose a simple patch for gnulib/strverscmp, which make this function much
more useful. Note that this patch is not related to any distribution. It just
cut off any postfix after version string.
Current version of coreutils uses strverscmp from gnulib, so if you want to
test this patch, you
Ondřej Vašík <[EMAIL PROTECTED]> writes:
> Bruno Haible wrote:
>> Ondřej Vašík wrote:
>> > 3) to use/create different function for handling version sort (like
>> > rpmvercmp in recommended in glibc strverscmp() bugzilla)
>>
>> Does rpmvercmp have the above property?
>
> Similar. It separates nam
Bruno Haible wrote:
> Ondřej Vašík wrote:
> > 3) to use/create different function for handling version sort (like
> > rpmvercmp in recommended in glibc strverscmp() bugzilla)
>
> Does rpmvercmp have the above property?
Similar. It separates name, epoch, version, release and architecture and
comp
Ondřej Vašík wrote:
> as reported in RH bugzilla #253817
> (https://bugzilla.redhat.com/show_bug.cgi?id=253817), there is an issue
> with ls -v (and there will be same issue with sort -V soon). Problem is
> with sorting files with extensions or dist-tags (like .tar.gz)
> because .tar.gz is more tha
19 matches
Mail list logo
