On Wed, Mar 22, 2017 at 2:58 PM, John P. Linderman wrote:
> I used to use LC_ALL=C, but, as I vaguely recall, it got in the way of
> dealing with UNICODE. I tried a couple LC values aimed at UNICODE and the
> US, but something always went pear-shaped. I finally give up. I am perfectly
> happy to s
I used to use LC_ALL=C, but, as I vaguely recall, it got in the way of
dealing with UNICODE. I tried a couple LC values aimed at UNICODE and the
US, but something always went pear-shaped. I finally give up. I am
perfectly happy to suffer a tiny bit of performance, to have most things
work without t
On 03/22/2017 05:44 AM, John P. Linderman wrote:
That puts the runtimes on equal footing:
In my measurements, P[0-9] is still a tiny bit slower if one is using
glibc regex, due to a performance problem in glibc. You can work around
it by configuring --with-included-regex. It's probably not wor
This does not change anything substantial; it merely simplifies
hypothetical merges back to glibc.
* lib/getopt.c, lib/getopt.in.h, lib/getopt1.c, lib/getopt_int.h:
Change copyright notice to match what is in glibc.
* lib/getopt.c: Reorder includes to match glibc. Remove uses of
USE_IN_LIBIO. Rem
Thanks, all. That puts the runtimes on equal footing:
+ wc conjectures
125441818 125441818 6249180939 conjectures
+ rusage /home/jpl/src/grep-3.0/src/grep P[[:digit:]] conjectures
A[21]=11{11}:22 wrote:
> On Tue, Mar 21, 2017 at 7:09 PM, Paul Eggert wrote:
> > John P. Linderman wrote:
> >>
> >
