On Tue, Mar 09, 2010 at 10:53:25AM +0100, Bruno Haible wrote:
> > I've released a new stable snapshot. See attached NEWS.stable for details.
>
> Thanks for doing this. It's time to advertise your stable releases a little
> more. Here's a proposed doc change:
Thanks!
[snip]
> +We also make stable
On 11/03/10 17:10, Chen Guo wrote:
> Hi Padraig,
> Thanks for the _unlikely insight, that explains why it's not slower
> but the speed up is still quite mysterious. When I ran with the line
> lengths you wanted, with check it is no longer faster, but something
> else I don't quite understand po
Hi Padraig,
Thanks for the _unlikely insight, that explains why it's not slower
but the speed up is still quite mysterious. When I ran with the line
lengths you wanted, with check it is no longer faster, but something
else I don't quite understand pops up.
The file I usually test on is 1M
Bruno Haible wrote:
...
> This should fix it:
>
> 2010-03-11 Bruno Haible
>
> Fix problems with overloaded C++ definitions of memchr, strpbrk, etc.
> * build-aux/c++defs.h (_GL_CXXALIAS_SYS_CAST2): Make it work regardless
> whether the system provides one variant or multiple va
On 10/03/10 07:05, Chen Guo wrote:
Hi Bruno,
I tried with the checks for the presence of that last NUL byte like you
suggested,
> and to my surprise on the remote machine I was testing on it was consistently
> (as in every run for 20 runs) faster, and thus I've included it in the patch.
> This
Hi Jim,
> Here's a much easier way to reproduce the problem,
> using only gnulib. The key is to test the string
> module with another, like memchr:
>
> $ ./gnulib-tool --test --with-tests string memchr
>
> Here's the output I see:
Thanks. This is much easier. It is in fact the first thing
Hello,
Simon Josefsson writes:
> Recently gnulib added some self-tests written in C++ for otherwise
> C-only modules. When imported into libidn (otherwise a strictly C
> library), this leads to an error message:
>
> /bin/bash ../libtool --preserve-dup-deps --mode=link g++ -o
> test-fcntl-
