Re: Please do not install a charset.alias file under Mac OS X

Hi, On 2008-11-14 21:11:56 -0700, Eric Blake wrote: > You are better off filing this report against gettext, which is the > source of this file, and/or gnulib, which ships the latest version > of this file even in packages (such as m4) that have not yet > undergone the I18n conversion to use gette

Re: [PATCH 0/4] faster gnulib-tool

It is robust and may now be ubiquitous enough for our needs. Since automake has always been implemented in Perl, I don't see a problem there. The gnulib-tool user population is a subset of the automake user population, to a first approximation, seems to me. I'd much rather endure Per

Re: [PATCH] gnulib-tool: fix sed-based filtering

Hi Jim, > contained an error that made gnulib-tool fail with shells > that use the fast_func_remove_prefix=false (sed-using) code path. Thanks for the fix. My mistake. I did test both code paths, but only with bash. Bruno

[PATCH] gnulib-tool: fix sed-based filtering

Part of this change, Speed up gnulib-tool by doing more string processing through shell built-ins. contained an error that made gnulib-tool fail with shells that use the fast_func_remove_prefix=false (sed-using) code path. That probably includes most shells other than bash and zsh. I noticed i

Re: bash, sed, SIGPIPE

Bruno Haible wrote: > Eric Blake wrote in > : >> > After 'trap - SIGPIPE', sed should get a fatal SIGPIPE signal in these >> > conditions. >> > Quoting >> >

Re: [PATCH 0/4] faster gnulib-tool

Bruno Haible wrote: > Unfortunately, I don't see a better choice as an implementation language > of gnulib-tool: > - Python is good for text processing but does incompatible changes > in the language definition every couple of years. > - Perl is excluded because of the misdesigned syntax,

Re: strftime updates

Bruno Haible wrote: > Also, the test for mempcpy is redundant since nothing uses it. Proposed patch: That looks fine, and you're welcome to apply it. I'm generally in favor of clean-up changes in strftime.c, as long as they're not too invasive. Thinking of merge work, I see that there are some

Re: [PATCH 0/4] faster gnulib-tool

> Nice info thanks. > I tested stuff like this previously, and found it highly shell dependent: > http://www.pixelbeat.org/programming/shell_script_mistakes.html#performance Here are my tests: http://www.mail-archive.com/autoc...@gnu.org/msg17892.html > In summary I noticed that dash forked twi

Re: [PATCH 0/4] faster gnulib-tool

Paolo Bonzini wrote: > > A while ago I made a lot of timings regarding the speed of various shell > constructs; you can find them on the Autoconf list. Here are the > relevant ones: > >$ time sh -c 'for i in `seq 1 1000`; do :; done' >user0m0.034s >sys 0m0.024s > >$ time

Re: [PATCH 0/4] faster gnulib-tool

Bruno Haible wrote: > Hello Ralf, > > Thank you for your speedups to gnulib-tool. At first I was, of course, > excited about the 2x speedup. But when looking at the maintainability > of the code that you propose, I'm not fine with all of it any more. > > My four objections are: > > 1) You observ

Re: Conflicting types for mblen on Solaris 2.6

"Tom G. Christensen" wrote: > On Thu, Jan 01, 2009 at 10:11:11PM +0100, Jim Meyering wrote: >> [resend after bounce (my problem)] >> "Tom G. Christensen" wrote: >> > The current daily snapshot is failing to build fprintftime: >> > depbase=`echo fprintftime.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\