Jim Meyering wrote:
http://bugzilla.redhat.com/249315
It occurs to me that a test would help to catch this problem and
prevent it from recurring. Following this message is a proposed patch
to add test coverage for sort -R for non-C locales.
Bob
00:00:00 2001
From: Bob Proulx [EMAIL PROTECTED]
Date: Thu, 26 Jul 2007 02:19:49 -0600
Subject: [PATCH] sort: Improve sort --random-sort test.
* tests/misc/sort-rand: If locale is available pick a random
non-C locale and check sort --random-sort behavior using it.
Signed-off-by: Bob Proulx [EMAIL
Proulx [EMAIL PROTECTED]
+
+ sort: Improve sort --random-sort test.
+ * tests/misc/sort-rand: If locale is available pick a random
+ non-C locale and check sort --random-sort behavior using it.
Thanks!
Applied and pushed.
___
Bug-coreutils
[EMAIL PROTECTED] (Bob Proulx) wrote:
* tests/misc/sort-rand: If locale is available pick a random
non-C locale and check sort --random-sort behavior using it.
Signed-off-by: Bob Proulx [EMAIL PROTECTED]
---
ChangeLog|6 ++
tests/misc/sort-rand | 13 +
2
* tests/misc/sort-rand: If locale is available pick a random
non-C locale and check sort --random-sort behavior using it.
Signed-off-by: Bob Proulx [EMAIL PROTECTED]
---
ChangeLog|6 ++
tests/misc/sort-rand | 13 +
2 files changed, 19 insertions(+), 0 deletions
FYI, I've filed this bug report:
http://bugzilla.redhat.com/249315
If someone fixes it before I do (e.g. for another distro),
please let me know.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Jim Meyering [EMAIL PROTECTED] writes:
FYI, I've filed this bug report:
http://bugzilla.redhat.com/249315
If someone fixes it before I do (e.g. for another distro),
please let me know.
If they use the same i18n patch, then this should work (will appear soon
in openSUSE Factory):
---
Frederik Eaton [EMAIL PROTECTED] writes:
By the way, here is a patch corresponding to my current version of the
code.
Thanks, I installed that. I'll look into merging some of my proposed
changes later.
___
Bug-coreutils mailing list
Paul Eggert [EMAIL PROTECTED] wrote: Frederik Eaton
[EMAIL PROTECTED] writes: By the way, here is a patch
corresponding to my current version of the code.Thanks, I
installed that. I'll look into merging some of my proposed
changes later. Thanks for handling that. I've added a new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for handling that. I've added a new test:
* tests/misc/sort-rand: New file: basic tests for the new options.
sort --random-sort should probably be mentioned in NEWS.
- --
Life is short - so eat dessert first!
Eric Blake
Eric Blake [EMAIL PROTECTED] wrote:
Thanks for handling that. I've added a new test:
* tests/misc/sort-rand: New file: basic tests for the new options.
sort --random-sort should probably be mentioned in NEWS.
Thanks. It was on the list.
I've just done
Frederik Eaton [EMAIL PROTECTED] writes:
I still think what I sent is ready to apply.
I took a look at the patch quoted in that email and have some comments
and suggestions.
It's more conservative to minimize the changes to the ISAAC code. The
simplest thing to do for now is to put it into a
Paul,
Thank you for submitting a patch of your own.
I still think what I sent is ready to apply.
I took a look at the patch quoted in that email and have some comments
and suggestions.
It's more conservative to minimize the changes to the ISAAC code. The
simplest thing to do for now
Paul Eggert [EMAIL PROTECTED] wrote:
...
As a documentation issue, I'd feel more comfortable calling this a
hashed sort rather than a random sort. Using the word random
has the wrong connotations, since the sort doesn't generate a random
permutation of the input. So I would prefer option
By the way, here is a patch corresponding to my current version of the
code.
Frederik
diff -N -ur -x '*.in' -x Makefile -x configure -x dircolors.h -x groups -x '*~'
-x wheel.h -x 'localedir.*' -x 'stamp-*' -x wheel-size.h -x alloca.h -x .deps
-x charset.alias -x getdate.c -x ref-add.sed -x
Hi Jim,
The discussion following my most recent patch has been a rehash of
things we've already covered, or complaints (Andreas') about existing
coreutils code which I just moved from one place to another. I still
think what I sent is ready to apply. The other issues can be addressed
in separate
Frederik Eaton [EMAIL PROTECTED] wrote:
On Tue, Nov 29, 2005 at 07:31:45AM +0100, Jim Meyering wrote:
Frederik Eaton [EMAIL PROTECTED] wrote:
Maybe we need an option to trade off speed for quality,
if it makes such a big difference.
Hmm. Maybe there will be a difference. Well, why don't
On Tue, Nov 29, 2005 at 07:31:45AM +0100, Jim Meyering wrote:
Frederik Eaton [EMAIL PROTECTED] wrote:
Maybe we need an option to trade off speed for quality,
if it makes such a big difference.
Hmm. Maybe there will be a difference. Well, why don't I make
ISAAC_LOG or ISAAC_WORDS part of
On Wed, Nov 30, 2005 at 11:55:29AM +0100, Jim Meyering wrote:
Frederik Eaton [EMAIL PROTECTED] wrote:
On Tue, Nov 29, 2005 at 07:31:45AM +0100, Jim Meyering wrote:
Frederik Eaton [EMAIL PROTECTED] wrote:
Maybe we need an option to trade off speed for quality,
if it makes such a big
Jim Meyering [EMAIL PROTECTED] writes:
If someone (Paul :-) contributes a module that reads /dev/urandom
but reverts to rand-isaac.c-like code as a fall-back source, we can
always switch later.
Yes, thanks, that was the sort of thing I had in mind (no pun intended...).
But obviously it can
Hello Paul and others listening,
I'm puzzled as to why, in this day and age, shred (and any other
programs that might need lots of hard-to-guess random numbers) needs
to have its own random number generator. Why can't such programs just
read /dev/urandom? Is it because they need to fall
Frederik Eaton [EMAIL PROTECTED] wrote:
Maybe we need an option to trade off speed for quality,
if it makes such a big difference.
Hmm. Maybe there will be a difference. Well, why don't I make
ISAAC_LOG or ISAAC_WORDS part of isaac_state so that shred and sort
can use different values? I
I'm puzzled as to why, in this day and age, shred (and any other
programs that might need lots of hard-to-guess random numbers) needs
to have its own random number generator. Why can't such programs just
read /dev/urandom? Is it because they need to fall back on something
on hosts that lack
Frederik Eaton [EMAIL PROTECTED] wrote:
...
This is my second (or third? or fourth?) attempt at a patch to sort to
introduce shuffling behavior. However, I encourage people to take a
Thanks for persevering.
good look at it because it's much more polished than the others.
I've included
Jim Meyering [EMAIL PROTECTED] writes:
+ memcpy (s, rand_state, sizeof (struct isaac_state));
Please do this instead:
memcpy (s, rand_state, sizeof *s);
*s = *rand_state should work just fine.
...
+ else if (key-random_hash)
+{
+ char diga[HASH_SIZE];
+
- The second patch changes a constant ISAAC_LOG in isaac.h from 8 to
3. The code explicitly says that this can be done, so, going by that
I'm leery of this change.
Won't such a reduction in the size of the state array
have a detrimental effect on quality of the random numbers?
Maybe we
Hi all,
This is my second (or third? or fourth?) attempt at a patch to sort to
introduce shuffling behavior. However, I encourage people to take a
good look at it because it's much more polished than the others.
I've included everything I think should be included - documentation,
ChangeLog
Actually, here is a new version which should hopefully fix some
indentation problems.
Frederik
On Sat, Nov 26, 2005 at 07:03:31AM +, Frederik Eaton wrote:
Hi all,
This is my second (or third? or fourth?) attempt at a patch to sort to
introduce shuffling behavior. However, I encourage
28 matches
Mail list logo
