Re: fpurge on z/OS

Bruno Haible wrote: > Actually, the only places where bash-4.0 calls fpurge is directly after fflush > on the same stream, and only on output streams: > > fflush (stdout); > fpurge (stdout); > > Does someone understand the purpose of this code? IMO fpurge is a nop, > right after fflush (assu

Re: [PATCH] maintainer-makefile: (PO_DOMAIN): New variable, allows overriding of gettext domain.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 4/17/2009 1:22 AM: >> However, note that it downloads all .po files every time. Have you >> considered adjusting that rule to work like the code in bootstrap, that >> uses rsync and a cache? That avoids not only the wa

Re: fpurge on z/OS

Juergen Weber wrote in : > I am a bit appalled of having to implement all those low-level non-portable > functions to get bash running. I can understand this feeling... > Or what about writing an generic implementation of the ci

Re: faster fnmatch

Hello Ondrej, > > Hello. I am writing partial fnmatch to speed up locate et al. Cool! We know for some time already that this is a bottleneck [1]. I find it also interesting that you go for a two-step approach, preprocess the pattern once and use it for matching often - the same approach that we

realloc documentation

I was looking at what was provided by the realloc module in gnulib and was a bit confused. There was no texi info on it and the description in modules/realloc just says "realloc() function that is glibc compatible". For me, that wasn't enough info to infer how I should use realloc(). The module ch

Re: faster fnmatch

[ CC += bug-findutils, bug-gnulib; bug-coreutils moved to BCC ] On Thu, Apr 16, 2009 at 8:09 PM, Ondrej Bilka wrote: > Hello. I am writing partial fnmatch to speed up locate et al. Please note that locate is part of GNU findutils, not GNU coreutils. I have CC'ed this email to the correct list.

Re: maint.mk sync

Simon Josefsson wrote: >>> The only thing that is missing is to make it easy for maintainers to put >>> something in cfg.mk that disables some checks they don't care about, >>> alternatively list the checks they do care about. >> >> That's already possible. >> Just add names of unwanted checks to t

Re: maint.mk sync

Jim Meyering writes: > Simon Josefsson wrote: > ... >> But the checks aren't turned on by default, are they? The maintainer >> needs to invoke the specific rules manually. > > Yes, they are run as part of "make syntax-check", by default. Ah, right. >> I'd like something like that: I think mult

Re: maint.mk sync

Simon Josefsson wrote: ... > But the checks aren't turned on by default, are they? The maintainer > needs to invoke the specific rules manually. Yes, they are run as part of "make syntax-check", by default. >> Also, the diagnostic-checking rules are insufficiently general. At the >> very least,

Re: maint.mk sync

Jim Meyering writes: > Simon Josefsson wrote: >> I'm beginning to think that incremental syncing of maint.mk will never >> finish, the sync targets are moving too quickly. >> >> I propose to just import the coreutils maint.mk into gnulib, and then >> move forward from there on. The patch below t

Re: maint.mk sync

Simon Josefsson wrote: > I'm beginning to think that incremental syncing of maint.mk will never > finish, the sync targets are moving too quickly. > > I propose to just import the coreutils maint.mk into gnulib, and then > move forward from there on. The patch below takes coreutils' maint.mk, > an

Re: [PATCH] maintainer-makefile: (PO_DOMAIN): New variable, allows overriding of gettext domain.

Jim Meyering writes: > Simon Josefsson wrote: >> This is useful in gnutls, which uses a different gettext domain than the >> top-level package name. Pushed. > > Hi Simon, > > That looks fine. > > However, note that it downloads all .po files every time. Have you > considered adjusting that rule

Re: [PATCH] maintainer-makefile: (PO_DOMAIN): New variable, allows overriding of gettext domain.

Simon Josefsson wrote: > This is useful in gnutls, which uses a different gettext domain than the > top-level package name. Pushed. Hi Simon, That looks fine. However, note that it downloads all .po files every time. Have you considered adjusting that rule to work like the code in bootstrap, t

maint.mk sync

I'm beginning to think that incremental syncing of maint.mk will never finish, the sync targets are moving too quickly. I propose to just import the coreutils maint.mk into gnulib, and then move forward from there on. The patch below takes coreutils' maint.mk, and keeps the current coverage+gette