Re: vc-mtime: Add API for more efficient use of git

Bruno Haible writes: >> Did this implementation work fast enough while avoiding the library >> dependency? Or was there another reason to not use it? > > libgit2 has a lot of dependencies, see > . Therefore relying on > this library needs a good j

Re: vc-mtime: Add API for more efficient use of git

Hi Collin, > > The 'vc-mtime' module that I added in February turns out to be slower than > > expected by users, when they use it on thousands of files under git version > > control. > > I saw this gettext bug report when it was reported and thought the > libgit2 license issue you noticed was fix

Re: vc-mtime: Add API for more efficient use of git

Hi Bruno, Bruno Haible via Gnulib discussion list writes: > The 'vc-mtime' module that I added in February turns out to be slower than > expected by users, when they use it on thousands of files under git version > control. I saw this gettext bug report when it was reported and thought the libg

Re: Improving support for find_shared_library_fullname (module 'relocatable')

Hi Reuben, > I just ran into the problem that this function does nothing on macOS. > Indeed, it only works on Linux with glibc or uClibc, and Cygwin. (There's > equivalent but separate code for native Windows, of course.) > > A little investigation suggests that macOS and other platforms could us

Re: [PATCH] doc: Clarify "nearly forever".

G. Branden Robinson wrote: > References: > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sys/types.h An archaeologically interesting archive :) > --- > doc/gnulib-readme.texi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/doc/gnulib-readme.texi b/doc

vc-mtime: Add API for more efficient use of git

The 'vc-mtime' module that I added in February turns out to be slower than expected by users, when they use it on thousands of files under git version control. This patch speeds it up by running 'git ls-files' on many files at once, 'git diff' on many files at once, and 'git log -1' on many files

javacomp: Fix resource leak

The javacomp module has a resource leak in case of (unlikely) failure. This patch fixes it. 2025-05-01 Bruno Haible javacomp: Fix resource leak. * lib/javacomp.c (execute_and_read_line): Upon failure, close the stream and wait for the child process to terminate. diff

Re: [PATCH] regex: Add \A and \z synonyms to \` and \'

On 2025-05-01 08:15, Eric Blake wrote: If POSIX were to try to standardize \` and \' instead of \A and \z, it would have the benefit of existing practice (glibc), but the drawback of less familiarity (lots more languages would have to adapt, whereas now \A is fairly common and \` is rare). I do

Improving support for find_shared_library_fullname (module 'relocatable')

I just ran into the problem that this function does nothing on macOS. Indeed, it only works on Linux with glibc or uClibc, and Cygwin. (There's equivalent but separate code for native Windows, of course.) A little investigation suggests that macOS and other platforms could use dladdr to get this i

Re: [PATCH] regex: Add \A and \z synonyms to \` and \'

On Sat, Apr 26, 2025 at 10:54:19AM -0700, Paul Eggert wrote: > On 2025-04-24 09:13, Eric Blake wrote: > > > case '\'': > > +case 'z': > > Python uses \Z for this and Python's \A ... \Z is cleaner and easier to > remember than Perl's \A ... \z, so how about if we follow Python's lead >

Re: configure --enable-systemd

On Thu, Apr 24, 2025 at 10:55:39AM +0100, Pádraig Brady wrote: 2) The option --enable-systemd is off by default. On systems like Ubuntu 25.04 (without /var/run/utmp support) this leads to a dysfunctional 'who' program by default. What can be done about this? Ad 1) (a) One should add a coreutils

Re: [PATCH] manywarnings: omit -Wdisabled-optimization

Hi Paul, > > Does gcc's warning message give a hint how the compiler options could > > be adjusted, so as to enable the optimization? > > Unfortunately not, at least not to me. Here's the diagnostic: > > bytecode.c: In function ‘exec_byte_code’: > bytecode.c:1792:1: error: fold-mem-offsets: 419

Re: obstack.in.h license

Paul Eggert wrote: > >> (I would not bet that code like this: > >>#if 0 > >># if @FOOBAR@ > >># endif > >>#endif > >> works for all C and C++ compilers. Better avoid that.) > > I always wondered if a compiler would fail with that. > > The C standard has required it to work ever sin