Sven Joachim wrote:
On 2010-03-08 07:51 +0100, Jim Meyering wrote:
There is a new mailing list: coreut...@gnu.org
We will soon hook up a debbugs-based bug tracker to the existing,
bug-coreutils list, and it will create a new ticket for each
seemingly-new thread.
We will then prefer to keep
Jim Meyering wrote:
Sven Joachim wrote:
As for the group name, gmane.comp.gnu.core-utils.general seems to be a
reasonable choice.
Like Bob, I would have preferred to spell it coreutils, but I think
we're stuck with gmane's existing/legacy spelling.
Legacy like this?
Hi, Dear Sir,
I use the command: date +%Y%m%d%H -d 1990-04-13 12 36 hours
But I get the result: 1990041501 ! The correct one should be 1990041500.
date +%Y%m%d%H -d 1990-04-13 12 118799 seconds
the result is: 1990041500.
But,
date +%Y%m%d%H -d 1990-04-13 12 118800 seconds
the result is:
On 2010-03-08 08:59 +0100, Jim Meyering wrote:
Sven Joachim wrote:
I would like to subscribe this new list to Gmane¹ if nobody has done
Thanks! That would be useful.
this yet. I suppose address encryption² could be turned off (makes it
somewhat more convenient to reply) ?
Personally I
On 2010-03-08, Pádraig Brady p...@draigbrady.com wrote:
Also what about the case where a command usually
behaves normally and exits when it gets a TERM,
but sometimes it hangs and needs a KILL which
you specify with timeout. You wouldn't want to
change the TERM into a KILL in that case.
Bob Proulx wrote:
Jim Meyering wrote:
Sven Joachim wrote:
As for the group name, gmane.comp.gnu.core-utils.general seems to be a
reasonable choice.
Like Bob, I would have preferred to spell it coreutils, but I think
we're stuck with gmane's existing/legacy spelling.
Legacy like this?
On Mon, 8 Mar 2010, gaosh wrote:
I use the command: date +%Y%m%d%H -d 1990-04-13 12 36 hours
But I get the result: 1990041501 ! The correct one should be 1990041500.
The result depends on your system's local timezone, which I assume is
set to Asia/Shanghai or equivalent Chinese location.
On 08/03/10 07:17, Jim Meyering wrote:
Pádraig Brady wrote:
Perhaps we could handle all cases with
the equivalent of:
if (sig==TERM user_sig==KILL) {
send(sig); /* give chance to term gracefully */
sleep(1);
send(KILL); /* nuke it from orbit */
}
If the child program's
On 08/03/10 09:11, Chen Guo wrote:
The following runs are conducted on an idle Intel Xeon X5460, 2 dies of 4 cores
each. All values are averages of 20 runs.
T=1: 5.10s
T=2: 2.87s
T=3: 2.71s
T=4: 1.75s
T=5: 1.66s
T=6: 1.65s
T=7: 1.67s
T=8: 1.31s
Nice results!
A few quick questions:
Any
2010/3/8 Pádraig Brady p...@draigbrady.com:
On 08/03/10 07:17, Jim Meyering wrote:
Pádraig Brady wrote:
Perhaps we could handle all cases with
the equivalent of:
if (sig==TERM user_sig==KILL) {
send(sig); /* give chance to term gracefully */
sleep(1);
send(KILL); /* nuke it from
On 05/03/10 01:31, Pádraig Brady wrote:
On 04/03/10 20:05, jida...@jidanni.org wrote:
On (info (coreutils) cut invocation) please add:
cut has no way to specify a group of blanks as a field demarcator.
If you want that, use perl -a. Also use perl's split if you want
regexp demarcators, etc.
If
On 08/03/10 10:14, Kim Hansen wrote:
2010/3/8 Pádraig Bradyp...@draigbrady.com:
An alternative would be to add a new --kill-wait option
which could be used to specify an additional timeout before a KILL was sent
That would be a general mechanism to terminate normally after the timeout
or when
Hi Padraig,
T=1: 5.10s
T=2: 2.87s
T=3: 2.71s
T=4: 1.75s
T=5: 1.66s
T=6: 1.65s
T=7: 1.67s
T=8: 1.31s
Nice results!
A few quick questions:
Any thoughts on the interesting jump at T=8?
Say we're sorting 32 lines with 8 threads, each thread would get 4 lines to
sort. If we
Pádraig Brady wrote:
On 05/03/10 01:31, Pádraig Brady wrote:
On 04/03/10 20:05, jida...@jidanni.org wrote:
On (info (coreutils) cut invocation) please add:
cut has no way to specify a group of blanks as a field demarcator.
If you want that, use perl -a. Also use perl's split if you want
tr -s '[:blank:]' '\t' | cut -f5
And perhaps mention less painful
tr -s \ \\t | cut -f5
and perl -anwle 'print $F[4]'
if the user's input permits such simplification...
On 2010-03-08 09:57 +0100, Jim Meyering wrote:
Bob Proulx wrote:
Legacy like this?
http://dir.gmane.org/gmane.comp.gnu.coreutils.announce
Good point. Forgot about that. And that's the one *I* requested.
It's just that I don't use that one as much and had
become inured to the
Hi Padraig,
From: Chen Guo cheng...@yahoo.com
Any thoughts on the interesting jump at T=8?
Say we're sorting 32 lines with 8 threads, each thread would get 4 lines to
sort. If we sort with 7 threads, then 6 threads would get 4 lines, and the
last
thread would get 8 to sort. Thus,
I should have included some information about the system that we are
using:
miw...@avalanche:/home/miwarn uname -a
Linux avalanche.corp.acxiom.net 2.6.9-89.0.11.ELlargesmp #1 SMP Mon Aug
31 11:05:24 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
miw...@avalanche:/home/miwarn more
We came across something that appears to be a bug as opposed to an
unintended design feature.
If you consider the following source file (named sort.txt in my
example):
M=L
MIK
M-
M-K
M=
MIK
M-A
miw...@avalanche:/home/miwarn sort sort.txt
M=
M-
M-A
MIK
MIK
M-K
M=L
Warner Mike - miwarn wrote:
We came across something that appears to be a bug as opposed to an
unintended design feature.
Thank you for the bug report. However what you are seeing is intended
behavior. It isn't something sort has control over. The character
collation sequence is chosen by
On 03/08/2010 03:39 PM, Warner Mike - miwarn wrote:
We came across something that appears to be a bug as opposed to an
unintended design feature.
Most likely, it is neither a bug nor an unintended feature, but a
documented feature of locale specifications.
I am expecting the output to come
21 matches
Mail list logo
