On 29/04/11 22:15, Pádraig Brady wrote:
> On 29/04/11 22:00, Jim Meyering wrote:
>> Eric Blake wrote:
>>> On a glibc system, Coverity gives this warning:
>>>
>>> Error: UNINIT:
>>> m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable "a
On 29/04/11 22:00, Jim Meyering wrote:
> Eric Blake wrote:
>> On a glibc system, Coverity gives this warning:
>>
>> Error: UNINIT:
>> m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable "action"
>> without initializer.
>> m4-1.4.16/lib/fatal-signal.c:198: uninit_use_in_call: Using unini
On 27/04/11 16:47, J.T. Conklin wrote:
> First some background.
>
> The continuous integration build framework I maintain at work uses
> timestamp files for "last_build", "last_success", etc. The contents
> of each file is the timestamp in ISO 8601 format (the inode mtime is
> set to the same v
On 09/04/11 01:14, Bruno Haible wrote:
> Hi Paul,
>
>>> +# if 0 && defined __cplusplus
>>> +# define HAVE_STATIC_ASSERT 1
>>> +# endif
>>
>> That "0 &&" looks wrong: did you put it in for debugging,
>> and intend to remove it before installing?
>
> The intent of this "0" condition was to be a pl
On 05/04/11 03:26, Paul Eggert wrote:
> This gnulib patch modifies "verify" to use C1X's _Static_assert if
> running GCC 4.6.0 or later, which generates easier-to-read
> diagnostics. I haven't pushed this yet because I thought it wouldn't
> hurt to get more pairs of eyes to look at it.
So C++0x s
On 06/04/11 12:03, Karel Zak wrote:
> On Tue, Apr 05, 2011 at 03:18:02PM +0100, Pádraig Brady wrote:
>> On 05/04/11 13:36, Philipp Thomas wrote:
>>> GNU find will not recognize file systems of type autofs on newer Linux
>>> kernels as autofs entries are only listed in /
On 05/04/11 13:36, Philipp Thomas wrote:
> GNU find will not recognize file systems of type autofs on newer Linux
> kernels as autofs entries are only listed in /proc/mounts and mountlist.c
> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
> is /etc/mtab.
>
> After a lo
On 31/03/11 15:20, Eric Blake wrote:
> Sounds to me like the gnulib fallback should be made smarter. Which
> systems lack linkat() but have the capability to set timestamps? BSD?
> But the original report was about opensuse, which is Linux based, and my
> recollection is that Linux handles hardli
On 24/03/11 17:17, Eric Blake wrote:
> C99 requires realloc(p,0) to either successfully allocate a 0-sized
> array (just like malloc(0)) or to return NULL and leave p unchanged.
>
> glibc treats realloc(p,0) like free(p) (as permitted by C89), and using
> C99 compliant code would thus result in a
On 11/03/11 13:50, Eric Blake wrote:
> On 03/11/2011 02:32 AM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>>> A recent change to dd in coreutils triggered this issue,
>>> which is avoided with the attached.
>>
>>>
On 11/03/11 09:32, Jim Meyering wrote:
> Pádraig Brady wrote:
>> A recent change to dd in coreutils triggered this issue,
>> which is avoided with the attached.
>
> Thanks!
> I've pushed that.
Cool, thanks.
I have gnulib commit access BTW
I had a local tweak to
A recent change to dd in coreutils triggered this issue,
which is avoided with the attached.
cheers,
Pádraig.
>From 3d1a414c90c49f3b4d9e427e4024f511adff154c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Fri, 11 Mar 2011 01:12:56 +
Subject: [PATCH] maint.mk: suppress a
On 02/03/11 17:10, Paul Eggert wrote:
> On 03/02/2011 07:09 AM, Jim Meyering wrote:
>> - struct argv_iterator *ai = malloc (sizeof *ai);
>> + struct argv_iterator *ai;
>> + struct stat st;
>> +
>> + if (fstat (fileno (fp),&st) == 0&& S_ISDIR (st.st_mode))
>> +{
>> + errno = EISDIR;
>>
On 04/02/11 18:23, Bruno Haible wrote:
> Hi Pádraig,
>
>> There was lots of heap interaction going on,
>> and by using the attached patch (only illustrative, may leak,
>> is not thread safe, ...) to cache the PRINTF_PARSE result
>> it increases the throughput to 5.8MB/s
>
> Adding a global cache
Sorry, just getting back to this now...
To recap, od using xprintf gives this throughput:
$ timeout 2 od -Ax -tx1z -v /dev/zero | pv >/dev/null # 1.58MB/s
There was lots of heap interaction going on,
and by using the attached patch (only illustrative, may leak,
is not thread safe, ...) to cache t
On 03/02/11 11:18, Bruno Haible wrote:
> Hello Pádraig,
>
>> The reason is because xprintf pulls in the whole gnulib vasnprintf
>> implementation, and then it does a huge number of reallocs.
>
> Did a profiling reveal where in vasnprintf the speed problems are?
All I did was narrow it down to re
I noticed od was very slow and traced it to it using xprintf:
$ timeout 2 od-xprintf -Ax -tx1z -v /dev/zero | pv >/dev/null
3.66MB 0:00:02 [1.86MB/s]
$ timeout 2 od-printf -Ax -tx1z -v /dev/zero | pv >/dev/null
19.6MB 0:00:02 [9.96MB/s]
The reason is because xprintf pulls in the whole gnulib vasn
sh: line 5: 24325 Alarm clock EXEEXT='' srcdir='.'
> MAKE='make' ${dir}$tst
> FAIL: test-u32-strstr
Yes I was being a bit lazy here.
Eek, can you attached your updated test-u-strstr.h
> So, the first part that can go in is this:
>
>
> 201
commit a00e384e1d7bbf0d4961b6f355307fd78b7536dd
Author: Pádraig Brady
Date: Fri Jan 21 08:47:51 2011 +
test-malloca: unset MALLOC_PERTURB_ to speed up test
* tests/test-malloca.c (main): Unset the environment variable
to greatly speed up the test.
* tests/init.sh: Don&#
commit b10e578396a2fd33e898b23d31fe49998c88c643
Author: Pádraig Brady
Date: Fri Jan 21 08:17:07 2011 +
ignore-value: remove dependency on stdint
Since commit 939dedd9, 06-01-2011,
"ignore-value: support aggregate types"
we no longer need stdint (intptr_t).
On 20/01/11 20:25, Eric Blake wrote:
> On 01/20/2011 01:16 PM, Pádraig Brady wrote:
>> On 31/07/10 20:48, Bruno Haible wrote:
>>> Hi Pádraig,
>>>
>>>>> the u8_strstr function.
>>>>
>>>> I wonder could we speed that up for UTF-
On 31/07/10 20:48, Bruno Haible wrote:
> Hi Pádraig,
>
>>> the u8_strstr function.
>>
>> I wonder could we speed that up for UTF-8
>> by just deferring to strstr() ?
>
> This is a good idea, because the naïve implementation of u8_strstr is
> quadratic (O(n²)), whereas for strstr we now have an O(
That looks much better, thanks!
How about the follow on patch to fixup comments?
I'll update coreutils to your commit now...
cheers,
Padraig.
commit 693a832795d6c63584db16baf163bccdc725dab6
Author: Pádraig Brady
Date: Fri Jan 7 01:25:06 2011 +
ignore-value: clarify some comments
On 05/01/11 11:22, Jim Meyering wrote:
> Pádraig Brady wrote:
> ...
>> Cool, thanks for doing that.
>> It probably needs this too:
>>
>> #ifndef __attribute__
>> /* The __attribute__((__deprecated__) feature
>>is available in gcc versions 3.1 and la
On 23/06/10 01:39, Pádraig Brady wrote:
> On 22/06/10 15:42, Eric Blake wrote:
>> On 06/22/2010 08:41 AM, Eric Blake wrote:
>>> On 06/22/2010 08:34 AM, Pádraig Brady wrote:
>>>> Cool, that's what I expected from the names.
>>>> So do w
On 21/11/10 01:31, Bruno Haible wrote:
>> 2010-11-20 Bruno Haible
>>
>> Port to uClibc.
>> ...
>
> Oops, that patch and its ChangeLog entry were incomplete.
>
> Here is the corrected ChangeLog:
>
> 2010-11-20 Bruno Haible
>
> Port to uClibc.
> * build-aux/link-warning.h (
On 14/12/10 07:04, Ralf Wildenhues wrote:
> Trying out gold (no LTO) on GCC's cc1, a log shows that the single
> biggest part (20%) of user time for such a medium sized program may be
> spent in SHA1 computation for the build id. I think the SHA1 code in
> libiberty would benefit from an SSE imple
On 13/12/10 17:50, Paul Eggert wrote:
> On 12/13/10 02:09, Pádraig Brady wrote:
>> * Keep allocation to multiples of BUFSIZ which may be more efficient
>
> I don't see how the patch accomplishes this.
> If alloc starts off being BUFSIZ, and the assignment
> "allo
On 25/10/10 01:26, Pádraig Brady wrote:
> I noticed large realloc()s still being done by fread_file() for the
> common case of a regular file. As well as being inefficient,
> it could needlessly fail for large files.
>
> $ truncate -s1M t.f
> $ ltrace ./a.out <
On 15/11/10 07:03, Paul Eggert wrote:
> On 11/14/2010 03:22 PM, Joel E. Denny wrote:
>> To keep things simple, could we just extend the existing bootstrap script
>> so that, once it has fetched gnulib sources and before doing anything
>> else, it updates itself and re-exec's itself if there are a
On 12/11/10 10:57, Bruno Haible wrote:
> Hi,
>
> On a stock Linux/x86 machine I observe these test failures:
>
> test-nanosleep.c:78: assertion failed
> FAIL: test-nanosleep
> test-sleep.c:53: assertion failed
> FAIL: test-sleep
>
> It's a "Red Hat Enterprise Linux ES release 4 (Nahant U
On 03/11/10 09:13, Jim Meyering wrote:
> glibc's snprintf is next-to-useless in an application that must accept
> arbitrary inputs and/or arbitrary format strings, and that cannot afford
> to allocate 2GiB of heap.
>
> Did you know that glibc's snprintf can fail due to ENOMEM? Your reaction
> to
I noticed large realloc()s still being done by fread_file() for the
common case of a regular file. As well as being inefficient,
it could needlessly fail for large files.
$ truncate -s1M t.f
$ ltrace ./a.out < t.f
__libc_start_main(0x8048624, 1, 0xbfd86c34, 0x8048940, 0x8048930
fileno(0x7b7420)
On 18/10/10 18:29, Paul Eggert wrote:
> On 10/18/10 04:53, Pádraig Brady wrote:
>
>> /* Like sizeof, except that it treats a variable sized array
>>as a pointer rather than determining the size at runtime. */
>> #define CT_SIZEOF(x) (__builtin_constant_p(size
On 18/10/10 21:15, Ben Pfaff wrote:
> Paul Eggert writes:
>
>> On 10/18/10 04:53, Pádraig Brady wrote:
>>
>>> /* Like sizeof, except that it treats a variable sized array
>>>as a pointer rather than determining the size at runtime. */
>>> #defin
On 17/10/10 20:58, Bruno Haible wrote:
> +/* When, on glibc systems, -D_FORTIFY_SOURCE=1 or -D_FORTIFY_SOURCE=2 is
> used,
> + enable extra bounds checking, based on the object bounds analysis done by
> + GCC.
> + The user can disable this bounds checking by defining _GL_NO_FORTIFY.
> + __
On 05/10/10 15:22, Eric Blake wrote:
> On 10/05/2010 08:13 AM, Eric Blake wrote:
>> @@ -351,7 +351,7 @@ check_versions() {
>> app=libtoolize
>> fi
>> # Honor $APP variables ($TAR, $AUTOCONF, etc.)
>> -appvar=`echo $app | tr '[a-z]' '[A-Z]'`
>> +appvar=`echo $app | tr '-a
On 05/10/10 02:51, Bruno Haible wrote:
> Joachim Schmitz writes:
>> Doesn't work here, same problem:
>> Read 68 from /etc/resolv.conf...
>> FAIL: test-read-file
>>
>> And to clarify: the problem is not the symlink, it is the different
>> personalities in NonStop. A symlink inside the OSS personalit
I was testing multi-byte enhancements to coreutils/join with:
LC_ALL=en_US.utf8 join -i <(env printf '1\x00\n') <(env printf '2\x00\n')
and noticed it spun the CPU because of the NUL char.
The attached fixes the issue for me. This function is supposed
to skip over NUL chars like this right?
cheers
On 20/09/10 07:21, Paul Eggert wrote:
> On 09/19/2010 07:43 PM, Gary V. Vaughan wrote:
>> my system headers have no pthread_spinlock_t definition, but
>> gnulib sees /usr/include/pthread.h and uses that instead of generating it's
>> own,
>> ...
>> I don't know enough about pthreads to tell whethe
On 09/08/10 15:46, Eric Blake wrote:
> On 06/10/2010 08:12 AM, Pádraig Brady wrote:
>> On 10/06/10 14:32, Eric Blake wrote:
>>> On 06/10/2010 07:22 AM, Callahan, Patrick M. wrote:
>>>> if ((errno == ENOSYS || errno == EOPNOTSUPP)
>>>> ...
>
On 29/07/10 10:26, Paolo Bonzini wrote:
> On 07/29/2010 11:05 AM, Pádraig Brady wrote:
>>> I would better recommend to use
>>> the u8_strstr function.
>>
>> I wonder could we speed that up for UTF-8
>> by just deferring to strstr() ?
>> I'
On 28/07/10 22:32, Bruno Haible wrote:
> Pádraig Brady wrote:
>> I would suggest a new function due to the
>> way I see this function called most often.
>>
>> /* definitely not sure of this name */
>> uint8_t *
>> u8_str_u8_chr (const uint8_t *s, const ui
On 27/07/10 19:14, Paolo Bonzini wrote:
> On 07/27/2010 06:06 PM, Pádraig Brady wrote:
>>
>> I would suggest a new function due to the
>> way I see this function called most often.
>> I.E. repeatedly with the same character.
>
> Is this really a bottleneck? i
On 23/07/10 13:03, Paolo Bonzini wrote:
> On 07/23/2010 09:21 AM, Bruno Haible wrote:
>> Otherwise fine, please commit. I can add comments that prove the
>> validity of
>> the code later, after you committed it.
>
> v2 already had large comments that detail the algorithm used and do
> include all
On 26/07/10 19:53, Paul Eggert wrote:
> I noticed thirteen "inline"s in coreutils/src/sort.c. Just for fun, I
> removed them all. In ten cases, removing "inline" made no difference to
> the generated machine code on my platform (RHEL 5, x86-64, GCC 4.1.2,
> compiled with the typical gcc -O2). In
On 23/07/10 07:53, bonz...@gnu.org wrote:
> From: Paolo Bonzini
>
> v2 of the patch, now including strchr operations too and with the
> changes suggested by Bruno. Padraig, can you test it on your
> cases too?
Cool. There was no measurable change for the 2 byte case,
but there was another 6% im
On 18/07/10 16:23, Bruno Haible wrote:
> Hi Pádraig,
>
>> However, the first byte of a multibyte
>> UTF-8 char is the same for a lot of characters
>
> Yes. The last byte is equidistributed across the range 0x80..0xBF, whereas
> the first byte is often the same. I'm applying the commit below to ex
On 14/07/10 00:01, Paul Eggert wrote:
> On 07/13/10 02:07, Pádraig Brady wrote:
>
>> The coreutils build just failed on our integration server
>> as it doesn't have
>
> Ah. A dinosaur, or a purposeful torture-test?
I'm not sure TBH as I don't have a
On 25/03/09 20:04, Paul Eggert wrote:
> This patch is to add multithread support for coreutils. The code was
> written by Glen Lenker, who has filed papers with the GNU project.
> The pthread emulation (for platforms that lack pthreads) is very minimal,
> just enough for coreutils to get by.
The
On 11/07/10 15:20, Paolo Bonzini wrote:
> On 07/07/2010 03:44 PM, Pádraig Brady wrote:
>> Subject: [PATCH] unistr/u8-strchr: speed up searching for ASCII
>> characters
>>
>> * lib/unistr/u8-strchr.c (u8_strchr): Use strchr() for
>> the single byte case as it was
On 21/04/10 11:20, Bruno Haible wrote:
> Hi Chen,
>
>> I mailed my signature off a good month ago, it should be. Bruno,
>> did you get anything from the FSF yet?
>
> No, I didn't get a notification from the FSF so far, and the copyright.list
> on FSF machines (which was last modified yesterday) d
On 07/07/10 23:49, Pádraig Brady wrote:
> On 07/07/10 17:07, Simon Josefsson wrote:
>> Pádraig Brady writes:
>>
>>> +/* The following is equivalent to:
>>> + return memmem (s, strlen(s), c, csize);
>>> + but faster for long S with matchi
On 08/07/10 04:24, Ralf Wildenhues wrote:
> Hi Pádraig,
>
> * Pádraig Brady wrote on Wed, Jul 07, 2010 at 03:44:29PM CEST:
>> Subject: [PATCH] unistr/u8-strchr: speed up searching for ASCII characters
>
>> --- a/lib/unistr/u8-strchr.c
>> +++ b/lib/uni
On 07/07/10 17:07, Simon Josefsson wrote:
> Pádraig Brady writes:
>
>> +/* The following is equivalent to:
>> + return memmem (s, strlen(s), c, csize);
>> + but faster for long S with matching UC near the start,
>> + and also memmem is s
On 06/07/10 22:18, Pádraig Brady wrote:
> I just noticed that I need to manually update $scriptversion.
I also forgot to manually update the Changelog. Grr.
Updated patch attached.
>From 94fb13ea255a9542bf4bff55841d9b8c11426135 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?=
multibyte case.
---
ChangeLog |4
lib/unistr/u8-strchr.c | 19 +++
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index afcae28..8ca0bd7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2010-07-07 Pádraig Brady
On 06/07/10 20:12, Ralf Wildenhues wrote:
> Hi Pádraig,
>
> * Pádraig Brady wrote on Tue, Jul 06, 2010 at 11:02:06AM CEST:
>> >From 3c537222dd86cdd62f21e085f0a8c43d6fc9707c Mon Sep 17 00:00:00 2001
>> From: =?utf-8?q?P=C3=A1draig=20Brady?=
>> Date: Tue, 6 Jul
In coreutils there were some stale po files distributed lately.
The following patch ensures that only po files from the translation project
are actually distributed.
cheers,
Pádraig.
>From 3c537222dd86cdd62f21e085f0a8c43d6fc9707c Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?=
Da
On 02/07/10 20:17, Jim Meyering wrote:
> Thanks again for the report.
> However, while I was able to reproduce it (on Paul's system)
> and debug it, it appears to be due to a miscompilation of di-set.o
> when using a private copy of gcc-4.5.0. When I recompiled
> that one file with gcc-Ubuntu 4.4.
On 22/06/10 15:42, Eric Blake wrote:
> On 06/22/2010 08:41 AM, Eric Blake wrote:
>> On 06/22/2010 08:34 AM, Pádraig Brady wrote:
>>> Cool, that's what I expected from the names.
>>> So do we just need to move a docs around a little like:
>>>
>>
>&g
On 22/06/10 15:09, Eric Blake wrote:
> On 06/22/2010 03:18 AM, Pádraig Brady wrote:
>>
>> Note the docs for "memmem" say it fixes
>>
>> "This function returns incorrect values in some cases, such as when
>>given an empty needle: glibc <= 2.
On 22/06/10 00:30, Eric Blake wrote:
> Meanwhile, glibc bug 11607 already complains that the time spent on
> factorization is extremely noticeable for short strings. I have not
> benchmarked things myself (partly because I don't know how cache-line
> effects would play into a benchmark), but do w
On 10/06/10 14:32, Eric Blake wrote:
> On 06/10/2010 07:22 AM, Callahan, Patrick M. wrote:
>> if ((errno == ENOSYS || errno == EOPNOTSUPP)
>> ...
>> You could get in a debugger and determine where
>> to add "|| errno == 252" to solve what appears to be
>> an HP-UX-and/or-cvfs-specific probl
On 08/06/10 21:51, Jim Meyering wrote:
> Callahan, Patrick M. wrote:
>> Pádraig Brady wrote:
>>> Callahan, Patrick M. wrote:
>>>> When using coreutils binaries either built from sources or installed
>>>> from the Porting And Archive Centre for HP-UX
On 27/04/10 13:15, Jim Meyering wrote:
> I've just pushed the patch below.
> It exposed a few unnecessary #if tests in coreutils:
Very nice check.
> Hence the compromise of searching for all of them at once,
> with the downside that occasionally you'll be warned about
> a line like this one (from
On 23/04/10 23:51, Paul Eggert wrote:
I believe there is a bunch of places in gnulib which uses memset(P, 0,
sizeof(P)) to initialize structures containing pointers, which wouldn't
be OK if this is not the case.
>>>
>>> However, GNU Coding Standards states that we can assume that all
On 14/03/10 14:24, Bruno Haible wrote:
> Hi Chen,
>
>> ... it was consistently (as in every run for 20 runs) faster, and thus I've
>> included it in the patch.
>
> Thanks. I'll wait for the FSF notification that the legal papers have arrived.
Hi Chen, The copyright stuff is sorted now I presume
On 12/04/10 17:51, Eric Blake wrote:
> On 04/11/2010 03:31 AM, Jim Meyering wrote:
>> This patch does something I've wanted for a while.
>> It prints the elapsed time for each individual syntax-check rule.
>>
>> I don't particularly like the fact that each new rule
>> - uses a temporary .sc-start
On 10/04/10 19:43, Paolo Bonzini wrote:
> On 04/10/2010 05:43 PM, Pádraig Brady wrote:
>> Thanks Paolo.
>> That's a nice feature to have.
>> I.E. statically link the lib when not present on the system.
>> It would be useful when one wanted to build a standalone se
On 10/04/10 13:53, Jim Meyering wrote:
> Here's a rule I'm adding to coreutils' cfg.mk.
> However, I would like to use it several other projects,
> so rather than duplicating it in each, I'm thinking of
> putting it in gnulib's maint.mk.
>
> Opinions?
>
> I know that at least Bruno likes to retai
On 10/04/10 12:24, Paolo Bonzini wrote:
> This series adds a libunistring-optional module. The purpose of the
> module is to allow using a system libunistring whenever present, while
> leaving the source code in the package too for the case when it is absent.
Thanks Paolo.
That's a nice feature t
On 24/03/10 08:56, Simon Josefsson wrote:
> This syntax-check warning appears to fail:
>
> j...@mocca:~/src/libidn master$ make sc_Wundef_boolean
> Wundef_boolean
> grep: : No such file or directory
> j...@mocca:~/src/libidn master$
>
> Any reason we can't use the normal VC_LIST_EXCEPT instead?
On 11/03/10 17:10, Chen Guo wrote:
> Hi Padraig,
> Thanks for the _unlikely insight, that explains why it's not slower
> but the speed up is still quite mysterious. When I ran with the line
> lengths you wanted, with check it is no longer faster, but something
> else I don't quite understand po
On 10/03/10 07:05, Chen Guo wrote:
Hi Bruno,
I tried with the checks for the presence of that last NUL byte like you
suggested,
> and to my surprise on the remote machine I was testing on it was consistently
> (as in every run for 20 runs) faster, and thus I've included it in the patch.
> This
On 22/02/10 15:08, jema...@gnu.org wrote:
Would it be better to just add /dev/null as a parameter to grep?
I.E. like:
@grep -nE 'error \(EXIT_SUCCESS,' \
$$($(VC_LIST_EXCEPT) /dev/null | grep -E '\.[chly]$$')&&
\
On 21/02/10 13:43, jema...@gnu.org wrote:
Hi.
Just another little patch to avoid some of the sc_* rules to freeze if
the filtering of VC_LIST_EXCEPT gives an empty string (for example,
'make sc_error_exit_success' freezes if there are not source files in
${srcdir}/).
I found this problem due t
On 25/01/10 11:51, Jim Meyering wrote:
Pádraig Brady wrote:
Subject: [PATCH] syntax-check: detect incorrect boolean macro values in config.h
* modules/maintainer-makefile (configure.ac): Parameterize the location
of config.h. The logic is from Eric Blake and the location indicated
by Jim
On 22/01/10 17:09, Jim Meyering wrote:
Eric Blake wrote:
According to Jim Meyering on 1/22/2010 6:17 AM:
However, it'd sure be nice to use something more generic than
lib/config.h. IMHO, autoconf should make configure AC_SUBST its
currently-internal-only CONFIG_HEADERS variable. While we wait
On 10/01/10 10:32, Bruno Haible wrote:
Pádraig Brady wrote:
So what about a possible work around?
How about doing this in nproc(1):
if (num_processors(NPROC_ALL) == 1)
return num_processors(NPROC_CURRENT_OVERRIDABLE)
It should be NPROC_CURRENT, not NPROC_CURRENT_OVERRIDABLE, I think
On 10/01/10 01:14, Giuseppe Scrivano wrote:
when --all fails for any reason, I think we should try with the number
of available processing units, at least it is a more accurate value than
return 1 (and document this behaviour).
Bruno, Jim, what do you think?
Just to summarize what's happening
On 24/12/09 23:21, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 12/24/2009 1:08 PM:
Either way we create macros.h and put ASSERT there
Done this this big commit, now.
Hmm. macros.h defines SIZEOF, and test-argv-iter.c defines
ARRAY_CARDINALIT
On 10/12/09 14:33, Simon Josefsson wrote:
Bruno Haible writes:
Simon Josefsson wrote:
Is there a need to modify how 'indent' works here? Or document how to
make indent do the right thing? When making substantial changes to
gnulib code, I tend to run 'indent' on the code to make sure I'm
fol
Bruno Haible wrote:
> Hi,
>
> I see that some of you are starting to untabify C source code (Jim in
> lib/userspec.c, Eric in lib/pipe-safer.c). Is this a signal that we can
> finally put those annoying TAB characters at rest? [1] I would love it.
>
> Just 2 questions:
>
> - Since GNU Emacs de
Eric Blake wrote:
> According to Pádraig Brady on 12/4/2009 6:20 PM:
>>> + /* Remove pair-wise duplicates, as well as any duplicate of the
>> ? + first element. Rather than do a full O(n log n) duplicate
>>> + removal, this only visits the most common dupl
Eric Blake wrote:
> The first was a bug I introduced when moving mgetgroups from coreutils to
> gnulib (comparing a gid_t with -1 will fail on platforms where gid_t is
> uint16_t; the coreutils version only used the gid argument in the getugroups
> case, so the bug came from my new code for the
Bruno Haible wrote:
> Hi Jim,
>
>> Ok to apply the patch below?
>> Without it, anyone can make nearly any coreutils program segfault
>> with this simple recipe:
>>
>> printf '%s\n' '#include ' 'int main(int c, char**v)' \
>> '{ execve (v[1], 0, 0); }' > k.c && gcc k.c && ./a.out /bin/cat
Eric Blake wrote:
> I'd like to push this as the fix. However, it would be nicer to credit a
> full name, rather than just "Scott", for listing you in THANKS.
The fix looks fine, thanks.
whois says it's: Scott Harrison
cheers,
Pádraig.
Jim Meyering wrote:
> with F12's 5.10.0, I see this:
>
> $ perl -le 'print $]'
> 5.01
I didn't use $] in the adjusted get_version() I sent :)
> So $^V appears to be out.
>
> Want to write the patch?
> There must be something canonical and "easy" in Perl itself, considering
> the pre
Jim Meyering wrote:
> Pádraig Brady wrote:
>> Jim Meyering wrote:
>>> I've built and have been experimenting with perl 5.11.2+
>>> and hit a little snag: bootstrap was unable to extract
>>> the version number from its new --version output.
>>>
Jim Meyering wrote:
> I've built and have been experimenting with perl 5.11.2+
> and hit a little snag: bootstrap was unable to extract
> the version number from its new --version output.
> To address that, I've changed bootstrap to special-case perl:
That looks good, the caveat being that all pro
Jim Meyering wrote:
> Jim Meyering wrote:
> ...
>>> execve("/root/bin/no_such", ["no_such"], [/* 57 vars */]) = -1 EACCES
>>> (Permission denied)
>> ...
>>> /root/bin/ directory is not created in koji buildroot (it is not created by
>>> default at all) - so that might be the difference.
>> Thanks
I think the last check in timeout-parameters needs
the same treatment?
cheers,
Pádraig.
commit 05327326c6f66650c685e26b777140782d300233
Author: Pádraig Brady
Date: Fri Nov 13 22:52:14 2009 +
tests: avoid a spurious failure on a loaded system
* tests/misc/timeout-parameters: This
Jim Meyering wrote:
> FYI,
>
>>From 9efa515cee4d1a40a41bdcd20e29932f8e2e5102 Mon Sep 17 00:00:00 2001
> From: Jim Meyering
> Date: Thu, 12 Nov 2009 09:49:39 +0100
> Subject: [PATCH] bootstrap: sync from coreutils
>
> * build-aux/bootstrap (bootstrap_epilogue): New function.
> Use git_modules_con
Eric Blake wrote:
> According to Eric Blake on 11/13/2009 11:35 AM:
>>> Are you approaching a good cut-off point?
>> I've almost got chown working; expect patches later today.
>
> Here's my candidate under testing. It passed FreeBSD 7.2, but I still
> need to check it on Solaris 9.
>
Wow the te
Giuseppe Scrivano wrote:
> Subject: [PATCH] nproc: A new program to count the number of processors
s/number of/available/
>
> * AUTHORS: Add my name.
> * NEWS: Mention it.
> * README: Likewise.
> * bootstrap.conf (gnulib_modules): Add nproc.
> * doc/coreutils.texi (nproc invocation): Add nproc i
Paolo Bonzini wrote:
> On 11/04/2009 01:24 AM, Pádraig Brady wrote:
>> BTW, it wouldn't be ambiguous to the program, nor would it
>> be different than the existing meaning, but as you say,
>> users could mistakenly do -P0 when they meant -0P.
>> So I'll make
Ralf Wildenhues wrote:
> * Pádraig Brady wrote on Tue, Nov 03, 2009 at 12:35:05PM CET:
>> --- a/doc/find.texi
>> +++ b/doc/find.texi
>> @@ -3521,6 +3521,15 @@ Use at most @var{max-args} arguments per command
>> line. Fewer than
>> option) is exceeded, unless
Pádraig Brady wrote:
> Paolo Bonzini wrote:
>> Maybe we want a --parallel option (too bad -p is taken) for xargs that
>> forces the creation of the number of processes passed with -P or taken
>> from nproc (for example by starting "md5sum $1 $5 $9 ...", "md5s
Paolo Bonzini wrote:
>>> I was thinking of an additional option that would automatically decrease
>>> -n so that the requested number of processes is started (then of course
>>> the load may not be well balanced).
>>
>> So you mean, rather than the current situation of:
>>
>> $ yes . | head -n13 |
701 - 800 of 856 matches
Mail list logo
