On 03/01/17 01:25, Pádraig Brady wrote:
> On 26/07/15 15:41, Rakesh Kumar wrote:
>> Hi All,
>>
>> While trying to generate HTML test coverage reports, I am facing an
>> error. Can anyone please advice on this. Help would be appreciated.
>>
>>
>> [00:36 rakesh@param
>> /home/rakesh/development/gnu_d
On 26/07/15 15:41, Rakesh Kumar wrote:
> Hi All,
>
> While trying to generate HTML test coverage reports, I am facing an
> error. Can anyone please advice on this. Help would be appreciated.
>
>
> [00:36 rakesh@param
> /home/rakesh/development/gnu_development/coreutils$] :
> lcov -t coreutils -
Karl Berry wrote:
Can the changes in these files be reverted please?
Thanks, I wish the copyright-update script didn't do that. I reverted those
changes.
Bruno Haible wrote:
I would vote for removing this sentence "Gnulib code can assume that standard
internal types like size_t are no wider than long." The fix is easy nowadays
(since MSVC now has ): Use intptr_t or ptrdiff_t or size_t as
appropriate.
It's not that easy for code that wants to pri
As usual, the copyright year update included all synced files (including
licenses), and so as usual everything is now out of sync.
Can the changes in these files be reverted please? --thanks, karl.
build-aux/config.guess Sun Jan 1 09:52:15 2017
build-aux/config.sub Sun Jan 1 09:52:15 2017
* top/maint.mk (coverage): Run dependencies serially,
thus supporting parallel processing of each one,
particularly build-coverage, which builds and runs tests.
---
ChangeLog| 7 +++
top/maint.mk | 5 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLo
Paul Smith wrote:
> > Gnulib code can assume that standard internal types like size_t are no
> > wider than long.
>
> Is that right? On a 64bit system compiling with Microsoft Visual C,
> long is only a 32bit integer. Is it saying that gnulib is specifically
> not intended to work with MS Visual
* lib/dfa.c (FETCH_WC): Remove, replacing with ...
(fetch_wc, bracket_fetch_wc): ... new functions. These store the
wint_t result into DFA->lex.wctok instead of to a separate arg.
All callers changed. Move more local decls closer to where
they're used.
---
ChangeLog | 7
lib/dfa.c | 107 +
* lib/dfa.c: Move more local decls to be more local.
---
ChangeLog | 3 +++
lib/dfa.c | 13 +
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 6ee2380..7a9edc1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,8 @@
2017-01-02 Paul Eggert
Looking at the portability guidelines[1] there is some confusion; early
on it says:
> Currently we assume at least a freestanding C89 compiler
But then later in that same section I see things like:
> The GNU coding standards allow one departure from strict C99
and:
> Hence Gnulib code should a
On 01/02/2017 05:37 PM, Pavel Raiskup wrote:
> On Monday, January 2, 2017 4:50:28 PM CET Bruno Haible wrote:
>> Especially since the problem occurs only on one architecture.
>
> I've been able to reproduce this on i686 in the meantime too, sorry -- I just
> reported what I observed :(. See [1].
Bruno Haible wrote:
I think you can now remove the 'invert = true;' statement (line 1022).
Thanks, done with the attached.
>From 89683adbc0b4c6c75727f25dcd417f0b15f3517f Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 2 Jan 2017 08:27:12 -0800
Subject: [PATCH] dfa: remove duplicate assig
On Monday, January 2, 2017 4:50:28 PM CET Bruno Haible wrote:
> Hi Pavel,
>
> > One thing I'm afraid of is that writers could finish too
> > early. Could we could artificially slow them down?
>
> In test_rwlock the test does this:
>
> /* Wait for the threads to terminate. */
> for (i = 0;
Hi Pavel,
> One thing I'm afraid of is that writers could finish too
> early. Could we could artificially slow them down?
In test_rwlock the test does this:
/* Wait for the threads to terminate. */
for (i = 0; i < THREAD_COUNT; i++)
gl_thread_join (threads[i], NULL);
set_atomic_int_v
On Saturday, December 24, 2016 6:52:07 PM CET Bruno Haible wrote:
> Wow, a 30x speed increase by using a lock instead of 'volatile'!
>
> Thanks for the testing. I cleaned up the patch to do less
> code duplication and pushed it.
Thanks, that's nice speedup! And sorry for the delay..
I still see
On 02/01/17 02:25, Assaf Gordon wrote:
> Hello,
>
> Attached are four small bug fixes and two additions to the debug messages in
> parse-datetime.y (used in 'date --debug').
> The commit message for each commit gives a detail example of how/when it is
> used.
> There are no changes to the parsin
Hi Paul,
> I found some more local vars whose scope could be narrowed, and
> installed the attached followup patch.
I think you can now remove the 'invert = true;' statement (line 1022).
Bruno
Thanks.
18 matches
Mail list logo
