On Mon, Dec 12, 2016 at 5:58 PM, Bruno Haible wrote:
> Hi Jim,
>
> On Windows with MSVC, the 'fpending' module does not pass its test,
> because config.h defines
>
> #define PENDING_OUTPUT_N_BYTES 1
>
> In order to get this right, the expression should be
>
> ((struct { unsigned char *_ptr; un
Hi Jim,
On Windows with MSVC, the 'fpending' module does not pass its test,
because config.h defines
#define PENDING_OUTPUT_N_BYTES 1
In order to get this right, the expression should be
((struct { unsigned char *_ptr; unsigned char *_base; } *) fp)->_ptr -
((struct { unsigned char *_ptr;
Trevor Cordes wrote:
On 2016-12-12 Paul Eggert wrote:
grep should just work. It is
not working now and we need to fix that
By that rationale, the commit that causes the problems for me should be
backed out as a first step, and then a proper solution should be
found.
But it may be better to i
Gisle Vanem wrote:
> Seems this file supports every archaic target in existence, but
> not MSVC. I've patched it like:
>
> --- a/lib/fseeko.c 2016-01-30 20:42:16
> +++ b/lib/fseeko.c 2016-01-31 10:25:06
> @@ -100,7 +100,7 @@
> #elif defined EPLAN9/* Plan9 */
>if (fp->rp == fp-
On 2016-12-12 Paul Eggert wrote:
> grep should just work. It is
> not working now and we need to fix that
By that rationale, the commit that causes the problems for me should be
backed out as a first step, and then a proper solution should be
found. If you look at the commit in isolation, it:
- a
On 12/12/2016 02:36 AM, Trevor Cordes wrote:
If a user bothered to
specify fgrep or -F then that user knows what they are doing!
Here I have to disagree, and to agree with Bruno. The user should not
have to know what grep's algorithm is. grep should just work. It is not
working now and we nee
On 2016-12-12 Norihiro Tanaka wrote:
> > On my box the above runs for >2m (never completes before I ^C) on
> > the version **AFTER** the commits (v2.22). On the test build just
> > *BEFORE* the commits (2.21.73-8058), it runs in <2s. So for me, I
> > had a working command (-F -w -f) that used to
On Sun, 11 Dec 2016 18:55:32 +0100
Bruno Haible wrote:
> Norihiro Tanaka wrote:
> > dfa matcher is not always slower than kws matcher. ...
> > It's a trade-off. Can you have any idea to select the better
> > matcher for both two cases?
>
> There are at least two approaches.
>
> 1) If you have
Hi Paul,
> Before installing anything like that, I'd first like to look into improving
> the
> DFA performance, along the lines suggested by Norhiro Tanaka. Part of the
> problem appears to be that position-set merging, even with his latest
> proposed
> changes, is O(N**2) where N is the patt
Seems this file supports every archaic target in existence, but
not MSVC. I've patched it like:
--- a/lib/fseeko.c 2016-01-30 20:42:16
+++ b/lib/fseeko.c 2016-01-31 10:25:06
@@ -100,7 +100,7 @@
#elif defined EPLAN9/* Plan9 */
if (fp->rp == fp->buf
&& fp->wp == fp->buf)
-
10 matches
Mail list logo
