Re: [PATCH] New sol10priv module

On Fri, May 1, 2009 at 4:35 AM, Bruno Haible wrote: > David Bartley wrote: >> I've attached updated patches that hopefully >> address your and Bruno's concerns. > > Looks quite fine. Only a couple of minor points: > >  - m4/priv-set.m4 should do an AC_REQUIRE([AC_C_INLINE]) >    because the .h fil

Re: GNU libunistring 0.9 released

Hi Ralf, > When building this package from git, and in a VPATH build, some gperf > products will be output in the build tree. Indeed. This situation was not tested, because "gnulib --create-testdir" creates the gperf output files in the source directory. > Note that in a VPATH build, > whether

Re: Use automake *-local hooks as prerequisites only

Hi Ralf, > a limitation in that this strategy is not extensible: two > sets of commands for one rule produce an error from 'make'. This can > be avoided by creating module-private targets for the actual rule with > commands Good point. I wasn't aware about this subtle point when I wrote the rule

Re: [Patch] faster fnmatch

Hello Ondrej, * Ondrej Bilka wrote on Fri, May 01, 2009 at 09:36:39PM CEST: > +#define NULTEST(...) if (__builtin_expect(!(__VA_ARGS__),0)) return NULL; > +#define NULTEST2(...) if (__builtin_expect(!(__VA_ARGS__),0)) return -1; [...] > +static fnmatch_state * > +initfnmatchstate () > +{ > + fn

Re: [Patch] faster fnmatch

I send new version according to your comments On Fri, May 01, 2009 at 02:51:48PM +0200, Bruno Haible wrote: > > Hmm, well, users are expecting a speedup through your module always. If it > some (not too rare) cases the glibc fnmatch is faster, it's difficult to > convince people to use your functio

Use automake *-local hooks as prerequisites only

Hello Bruno, all, I noticed that the localcharset module defines a couple of automake hook rules including commands to update the hooks. While not a bug, it creates a limitation in that this strategy is not extensible: two sets of commands for one rule produce an error from 'make'. This can be a

Re: [bug-libunistring] two ways to use submodules for gnulib

Hello, if I may add my two cents, * Bruno Haible wrote on Fri, May 01, 2009 at 07:02:29PM CEST: > - The git history would become nonlinear and confusing, with releases > occurring on a particular branch only. a nonlinear history is not bad per se! On the contrary, a nonlinear history can,

Re: [bug-libunistring] two ways to use submodules for gnulib

Paolo Bonzini wrote: > at least it allows me to reconstruct the public tarballs. That is all that you want? I'll store the reference like this: *** version.sh.orig 2009-05-01 18:46:48.0 +0200 --- version.sh 2009-05-01 18:46:32.0 +0200 *** *** 1,3 --- 1,6

Re: Broken isnan(3) and/or DQNAN on Tru64

Ludovic Courtès wrote: > On `alphaev56-dec-osf5.1b', NaN handling seems to be deeply broken. > Consider this piece of code: > > --8<---cut here---start->8--- > #include > > extern unsigned int DQNAN[2]; > > int > main (int argc, char *argv[]) > { > return i

Re: [PATCH] getdate add a week when the wday is the same as the current one

On Fri, May 1, 2009 at 09:57, Pádraig Brady wrote: > Jim Meyering wrote: >> I expect to push this shortly. >> Thank you! > >>>From 372c3b4a79def664b8fa73316c35caf39bf93e2c Mon Sep 17 00:00:00 2001 >> From: Giuseppe Scrivano >> Date: Fri, 1 May 2009 09:23:20 +0200 >> Subject: [PATCH] getdate: corr

Re: Compiler error of m4-1.4.13 on AIX using xlc

Eric Blake wrote: > > I tried to do the update to m4-1.4.13 (using PkgSrc) on AIX and got > > following error: > > > >> CC regex.o > >> "regex_internal.c", line 320.48: 1506-280 (W) Function argument assignment > >> between types "char** restrict" and "int*" is not allowed. > >> "regex_internal.c

avoid warnings from gettext.h

On Solaris, when GNU gettext has installed its , and when an older Solaris cc is in use, and when NLS is disabled (as in m4-1.4.13), the compiler gives the following warnings: "./gettext.h", line 66: warning: macro redefined: gettext "./gettext.h", line 67: warning: macro redefined: dgettext "./ge

Re: [PATCH] getdate add a week when the wday is the same as the current one

Hello, I fixed the regression you found and added some new tests. $ ./date -d "fri" +%a.%F ven.2009-05-01 $ date -d "fri" +%a.%F ven.2009-05-01 and: $ ./date -d "next fri" +%a.%F ven.2009-05-08 $ date -d "next fri" +%a.%F ven.2009-05-01 Regards, Giuseppe >From 0e1af7775a82aed00331a535ddadee

Broken isnan(3) and/or DQNAN on Tru64

Hello, On `alphaev56-dec-osf5.1b', NaN handling seems to be deeply broken. Consider this piece of code: --8<---cut here---start->8--- #include extern unsigned int DQNAN[2]; int main (int argc, char *argv[]) { return isnan (* (double *) DQNAN); } --8<--

Re: [Patch] faster fnmatch

Hello Ondrej, Nice work already! > *abc* > en_US.UTF-8 > user: 2.71 > user: 0.23 > ... > *ab[a-z]* > en_US.UTF-8 > user: 2.85 > user: 3.32 > C > user: 0.86 > user: 1.25 Hmm, well, users are expecting a speedup through your module always. If it some (not too rare) cases the glibc fnmatch is

Re: [PATCH] getdate add a week when the wday is the same as the current one

Giuseppe Scrivano wrote: > This patch includes all your suggestions and new tests for > test-getdate.c. Thanks for the quick test addition! I want the summary line to start with "getdate: " and do be "high-level descriptive" so I moved your "add a week..." sentence into the body of the log. Also,

Re: Compiler error of m4-1.4.13 on AIX using xlc

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding bug-gnulib] According to Jens Rehsack on 5/1/2009 5:32 AM: > Hi Eric, Hi Jens, > > Thomas told me, you're the best person to ask for assistance regarding the > problem below. Well, actually 'm4 --help' (or even './configure --help', since

Re: [PATCH] New sol10priv module

David Bartley wrote: > I've attached updated patches that hopefully > address your and Bruno's concerns. Looks quite fine. Only a couple of minor points: - m4/priv-set.m4 should do an AC_REQUIRE([AC_C_INLINE]) because the .h file uses 'static inline'. - In priv-set.c, maybe add comments

Re: [PATCH] getdate add a week when the wday is the same as the current one

Hello, This patch includes all your suggestions and new tests for test-getdate.c. Giuseppe Bruno Haible writes: > Jim Meyering wrote: >>tm.tm_mday += ((pc.day_number - tm.tm_wday + 7) % 7 >> + + 7 * (pc.day_ordinal >> ++ (0 < pc.day_ordi

Re: [PATCH] getdate add a week when the wday is the same as the current one

Jim Meyering wrote: > tm.tm_mday += ((pc.day_number - tm.tm_wday + 7) % 7 > + + 7 * (pc.day_ordinal > + + (0 < pc.day_ordinal > +&& tm.tm_wday == pc.day_number) > + - (0 < pc.day_ord

Re: [Patch] faster fnmatch

Hello Ondrej, * Ondrej Bilka wrote on Thu, Apr 30, 2009 at 10:41:49PM CEST: > I here attach compiled fnmatch I wrote as gnulib module. I haven't read your patch closely, but it fails to check the return value from all of the malloc/realloc... functions, opening up several opportunities for segme

Re: [PATCH] getdate add a week when the wday is the same as the current one

Jim Meyering wrote: > I expect to push this shortly. > Thank you! >>From 372c3b4a79def664b8fa73316c35caf39bf93e2c Mon Sep 17 00:00:00 2001 > From: Giuseppe Scrivano > Date: Fri, 1 May 2009 09:23:20 +0200 > Subject: [PATCH] getdate: correctly interpret "next monday" when run on a > Monday > > *

Re: [PATCH] getdate add a week when the wday is the same as the current one

Giuseppe Scrivano wrote: > what do you think of the following patch? When the same day as the > current one is provided then a week is added. It doesn't change the > behaviour for days in the past. > > It closes coreutils #25406. > > diff --git a/lib/getdate.y b/lib/getdate.y > index 877b264..815