new module "mpsort" for faster sorting

2007-01-28 Thread Paul Eggert
For quite some time Djamel Belazzougui has been suggesting speed improvements to glibc's qsort function. I'm not sure yet that this is a good idea, but it does seem to me that there is use for a function that can sort a vector of pointers to data (as opposed to qsort, which sorts an array of data)

Re: build failures: string.h vs. HP-UX

2007-01-28 Thread Jim Meyering
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> If you're serious about merging back to glibc, it'll help >> (name space cleanliness) to add the "__" prefix: i.e., change >> your Restrict to __Restrict. > > But the prefix _R suffices, no? As far as the standa

Re: build failures: string.h vs. HP-UX

2007-01-28 Thread Paul Eggert
Jim Meyering <[EMAIL PROTECTED]> writes: > If you're serious about merging back to glibc, it'll help > (name space cleanliness) to add the "__" prefix: i.e., change > your Restrict to __Restrict. But the prefix _R suffices, no? As far as the standard C name space rules are concerned, _R* is in t

Re: build failures: string.h vs. HP-UX

2007-01-28 Thread Jim Meyering
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> Avoid a compile error from HP-UX's ia64 cc: s/__restrict\>/restrict/ >> * lib/regex.h: Use "restrict", not "__restrict", since only the >> former works with 'config.h's "#define restrict ...". >>

Re: build failures: string.h vs. HP-UX

2007-01-28 Thread Paul Eggert
Jim Meyering <[EMAIL PROTECTED]> writes: > Avoid a compile error from HP-UX's ia64 cc: s/__restrict\>/restrict/ > * lib/regex.h: Use "restrict", not "__restrict", since only the > former works with 'config.h's "#define restrict ...". > Problem reported by Bob Proulx. > Arg

Re: build failures: string.h vs. HP-UX

2007-01-28 Thread Paul Eggert
[EMAIL PROTECTED] (Bob Proulx) writes: > The problem is that regex.h is defining "__restrict" to be "restrict"! > ... > And of course config.h is defining "restrict" to be "__restrict". > > #define restrict __restrict > > That combination is obviously not good. Thanks for reporting that. I ins

Re: build failures: string.h vs. HP-UX

2007-01-28 Thread Jim Meyering
[EMAIL PROTECTED] (Bob Proulx) wrote: > Bob Proulx wrote: >> That seemed to mostly work. It is still failing under ia64 though. I >> think the compiler there has no support for restrict. If I define >> restrict to be nothing to disable it completely then the compilation >> succeeds. >> ... >> So

Re: avoid creating sys/time.h replacement when possible

2007-01-28 Thread Jim Meyering
Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> - use $(SYS_TIME_H) also in the definition of MOSTLYCLEANFILES > > This is not a good change. Suppose a user does in the same directory > - first, a "./configure; make" for a deficient platform, > - then, a "./configure" for a g

Re: avoid creating sys/time.h replacement when possible

2007-01-28 Thread Bruno Haible
Jim Meyering wrote: > - use $(SYS_TIME_H) also in the definition of MOSTLYCLEANFILES This is not a good change. Suppose a user does in the same directory - first, a "./configure; make" for a deficient platform, - then, a "./configure" for a glibc platform - then he notices that he forgot t

Re: avoid creating sys/time.h replacement when possible

2007-01-28 Thread Jim Meyering
Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Paul, Jim, > > Most developers are using glibc systems nowadays. When gnulib creates many > replacement header files on such systems, it makes look gnulib a bit > ridiculous. So can we avoid to create a header file when it's easy to do so? > Here is a pr

avoid creating sys/time.h replacement when possible

2007-01-28 Thread Bruno Haible
Hi Paul, Jim, Most developers are using glibc systems nowadays. When gnulib creates many replacement header files on such systems, it makes look gnulib a bit ridiculous. So can we avoid to create a header file when it's easy to do so? Here is a proposed patch. 2007-01-28 Bruno Haible <[EMAIL PR

simplification of unistd.h creation

2007-01-28 Thread Bruno Haible
Hi, The AC_REQUIRE technique just developed for can also be used to simplify the autoconf macros for creating the replacement. I committed this. 2007-01-28 Bruno Haible <[EMAIL PROTECTED]> * m4/unistd_h.m4 (gl_HEADER_UNISTD_DEFAULTS): New macro. (gl_HEADER_UNISTD): Require it

Re: gnulib-tool and line length: gl_LIBOBJS

2007-01-28 Thread Bruno Haible
Ralf Wildenhues wrote: > > How small is this limit? > > Around 20kB: > OK, and since gnulib's LIBOBJs line is currently at most 2.4 KB, we can ignore the problem for quite some time. $ grep -h AC_LIBOBJ m4/*.m4

Re: gnulib-tool and line length: gl_LIBOBJS

2007-01-28 Thread Ralf Wildenhues
* Bruno Haible wrote on Sun, Jan 28, 2007 at 02:57:39PM CET: > Ralf Wildenhues wrote: > > The combined length of object names in gl_LIBOBJS can get pretty close > > to the line limit of some 'make' implementations, > > How small is this limit? Around 20kB:

Re: small gnulib-tool nits

2007-01-28 Thread Ralf Wildenhues
* Bruno Haible wrote on Sun, Jan 28, 2007 at 02:40:37PM CET: > Ralf Wildenhues wrote: > > 2007-01-28 Ralf Wildenhues <[EMAIL PROTECTED]> > > > > * gnulib-tool (func_emit_lib_Makefile_am, func_add_or_update) > > (func_create_testdir): Ensure C locale for `grep' and `tr' > > character

Re: gnulib-tool and line length: gl_LIBOBJS

2007-01-28 Thread Bruno Haible
Ralf Wildenhues wrote: > The combined length of object names in gl_LIBOBJS can get pretty close > to the line limit of some 'make' implementations, How small is this limit? > or, FWIW, the portable text file format limit. What is this limit? I can edit text files with 1 characters per line i

Re: small gnulib-tool nits

2007-01-28 Thread Bruno Haible
Ralf Wildenhues wrote: > 2007-01-28 Ralf Wildenhues <[EMAIL PROTECTED]> > > * gnulib-tool (func_emit_lib_Makefile_am, func_add_or_update) > (func_create_testdir): Ensure C locale for `grep' and `tr' > character ranges. > (func_create_megatestdir): Avoid one `grep'. Fix b

Re: some module inconsistencies

2007-01-28 Thread Bruno Haible
Hello Ralf, > gnulib-tool --with-tests --test > > currently gives me > | gnulib-tool: module utf8-ucs4-safe doesn't exist > | gnulib-tool: module utf16-ucs4-safe doesn't exist Fixed now. Thanks. > I suppose the renaming session isn't over yet? ;-) It was supposed to be over. ;-) I correcte

gnulib-tool and line length: gl_LIBOBJS

2007-01-28 Thread Ralf Wildenhues
The combined length of object names in gl_LIBOBJS can get pretty close to the line limit of some 'make' implementations, or, FWIW, the portable text file format limit. As Autoconf 2.60 allows newlines in substituted values, there's an easy fix for users of new Autoconf. WDYT? Cheers, Ralf 2007-

small gnulib-tool nits

2007-01-28 Thread Ralf Wildenhues
Some more bits in gnulib-tool depend upon the locale. The patch below fixes some of those. It also kills one superfluous grep, and avoids a misparse of the ACLOCAL_AMFLAGS. OK to apply? Cheers, Ralf 2007-01-28 Ralf Wildenhues <[EMAIL PROTECTED]> * gnulib-tool (func_emit_lib_Makefile

some module inconsistencies

2007-01-28 Thread Ralf Wildenhues
Hello Bruno, all, gnulib-tool --with-tests --test currently gives me | gnulib-tool: module utf8-ucs4-safe doesn't exist | gnulib-tool: module utf16-ucs4-safe doesn't exist I suppose the renaming session isn't over yet? ;-) (Wow, you're productive these days!) Cheers, Ralf