Re: [PATCH] parse-datetime: fix generated paths for coverage files

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 >>

[PATCH] parse-datetime: fix generated paths for coverage files

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

Re: copyright 2017 in synced files

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.

Re: Question about portability guidelines

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

copyright 2017 in synced files

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

[PATCH] maint.mk: support parallel execution of coverage

* 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

Re: Question about portability guidelines

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

[PATCH 2/2] dfa: prefer functions to FETCH_WC macro

* 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

[PATCH 1/2] dfa: narrow more local var scopes

* 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

Question about portability guidelines

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

Re: Test-lock hang (not 100% reproducible) on GNU/Linux

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].

Re: [PATCH] dfa: narrow the scope of many local variables

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:

Re: Test-lock hang (not 100% reproducible) on GNU/Linux

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;

Re: Test-lock hang (not 100% reproducible) on GNU/Linux

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);

Re: Test-lock hang (not 100% reproducible) on GNU/Linux

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

Re: suggested improvements to parse-datetime's debug messages ('date --debug')

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

Re: [PATCH] dfa: narrow the scope of many local variables

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

Re: [PATCH] dfa: narrow the scope of many local variables

Thanks.