#2054: Grep-2.5.3
------------------------------------------+---------------------------------
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: enhancement | Status: assigned
Priority: normal | Milestone: 7.0
Component: Book | Version: SVN
Severity: normal | Resolution:
Keywords: |
------------------------------------------+---------------------------------
Comment (by [EMAIL PROTECTED]):
There are a couple of obscure bugs reported against debian :
[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294367] and
[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406259] which are both
reproducible with the LFS version of 2.5.1a and fixed in 2.5.3. This is
good.
But then I found an uncomfortable testcase - in multibyte locales,
grepping through a big file takes a lot longer (on my example file, 6.4
seconds for en_US.UTF-8, <0.02s for en_US and C (typical values, some
variation across runs). There are a whole series of debian bugs about
this, all the way back to 2.5.1. This is based on [http://bugs.debian.org
/cgi-bin/bugreport.cgi?bug=442882] but using a different text file about
150KB long which has zero matches and lets me omit the pipe to /dev/null.
In our 2.5.1a with the redhat fixes, this problem is not present
Back to playing with the patches - discovered that the mandriva 2.5.1a-
mbcset patch plus debian patches 55,60-1,63-67 (everything except the
mandriva patch to the testscript and the patches to the man pages to drop
references to "not-free" texinfo) has the best test results I've seen (42
failures in foad1, 2 in fmbtest, 3 in yesno). It also runs my big file
test in <0.020s in all three locales.
The down-side to that is that debian seems to have stopped using patch 65
(maybe I'm misreading), and in any case it makes use of 'dfa' (an
algorithm) optional in multibyte locales - you have to set an environment
variable to a non-zero integer to use it). If I set that variable, I'm
back to 48 failures (better than vanilla) in foad 1, 14 in fmbtest (much
worse), and 3 in yesno (same). Setting the environment variable also
makes my test in en_US.UTF-8 take more than 6 seconds again. **thinks,
looks at the 2.5.1a-redhat_fixes-2 patch ** : ok, we were already using
egf-speedup (64) and dfa-optional (65) in some form.
I think this is close to what I'm going to use, even though the "headline"
test failures (3/14) are unchanged. Might as well look at adding the
'new' test for -w from 2.5.1a, and take another look at mandriva's patch
to the testsuite.
Also, time to look at the individual fedora patches for 2.5.1a, in case
any are still useful. I don't know, I thought I was only going to do
minimal patching to this. AfI think this is close to what I'm going to
use, even though the "headline" test failures (3/14) are unchanged. Might
as well look at adding the 'new' test for -w from 2.5.1a, and take another
look at mandriva's patch to the testsuite.
After all, only 3 tests failed, and at best I can reduce that to 2!
/me hopes the next release will be more friendly to multi-byte locales.
--
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2054#comment:15>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
