Test Failures Latest CVS

Test Failures Latest CVS

[Vin Shelton]

It's probably a good thing that our test suites are starting to catch
more regressions:

/usr/local/src/zsh-2001-07-05/Test/D04parameter.ztst: starting.
*** /tmp/zsh.ztst.out.2596	Thu Jul  5 23:19:53 2001
--- /tmp/zsh.ztst.tout.2596	Thu Jul  5 23:19:53 2001
***************
*** 1,4 ****
  wre is the white windmill, whispered walter wisely
  wly
  where is the white windmill, wred walter wisely
! where is the white windmill, wly
--- 1,4 ----
  wre is the white windmill, whispered walter wisely
  wly
  where is the white windmill, wred walter wisely
! wly
Test /usr/local/src/zsh-2001-07-05/Test/D04parameter.ztst failed: output differs from expected as shown above for:
  # it's not quite clear that these are actually right unless you know
  # the algorithm:  search along the string for the point at which the
  # first (last) match occurs, for ## (%%), then take the shortest possible
  # version of that for # (%).  it's as good a definition as anything.
  string='where is the white windmill, whispered walter wisely'
  print ${(S)string#h*e}
  print ${(S)string##h*e}
  print ${(S)string%h*e}
  print ${(S)string%%h*e}
Was testing: ${(S)...#...} etc.
/usr/local/src/zsh-2001-07-05/Test/D04parameter.ztst: test failed.
/usr/local/src/zsh-2001-07-05/Test/D05array.ztst: starting.
/usr/local/src/zsh-2001-07-05/Test/D05array.ztst: all tests successful.
/usr/local/src/zsh-2001-07-05/Test/D06subscript.ztst: starting.
/usr/local/src/zsh-2001-07-05/Test/D06subscript.ztst: all tests successful.
/usr/local/src/zsh-2001-07-05/Test/E01options.ztst: starting.
/usr/local/src/zsh-2001-07-05/Test/E01options.ztst: all tests successful.
/usr/local/src/zsh-2001-07-05/Test/E02xtrace.ztst: starting.
/usr/local/src/zsh-2001-07-05/Test/E02xtrace.ztst: all tests successful.
/usr/local/src/zsh-2001-07-05/Test/V01zmodload.ztst: starting.
*** /tmp/zsh.ztst.err.4296	Thu Jul  5 23:20:01 2001
--- /tmp/zsh.ztst.terr.4296	Thu Jul  5 23:20:01 2001
***************
*** 0 ****
--- 1 ----
+ ZTST_execchunk:zsh/pcre:2: no setup function
Test /usr/local/src/zsh-2001-07-05/Test/V01zmodload.ztst failed: error output differs from expected as shown above for:
 for m in $mods
 do
   zmodload -i $m || mods[(r)$m]=()
 done
Was testing: Test loading of all compiled modules
/usr/local/src/zsh-2001-07-05/Test/V01zmodload.ztst: test failed.

The V01zmodload.ztst failure showed up on July 2nd, I believe.

This is all under:

Linux zion.rcn.com 2.4.6 #2 SMP Wed Jul 4 12:30:42 EDT 2001 i686 unknown

with gcc-3.0 and gcc-2.95.3.


TIA,
  - vin

RE: Test Failures Latest CVS

[Andrej Borsenkow]

> 
> /usr/local/src/zsh-2001-07-05/Test/D04parameter.ztst: starting.
> *** /tmp/zsh.ztst.out.2596	Thu Jul  5 23:19:53 2001
> --- /tmp/zsh.ztst.tout.2596	Thu Jul  5 23:19:53 2001
> ***************
> *** 1,4 ****
> ! where is the white windmill, wly
> --- 1,4 ----
> ! wly

That is due to Peter's 12566; test suite has to be updated.
> + ZTST_execchunk:zsh/pcre:2: no setup function

I guess, it was fixed in 15250 but never committed. Clint?

-andrej

Re: Test Failures Latest CVS

[Clint Adams]

> I guess, it was fixed in 15250 but never committed. Clint?

Ugh.  Sorry.

Re: Test Failures Latest CVS

[Bart Schaefer]

On Jul 5, 11:53pm, Vin Shelton wrote:
} Subject: Test Failures Latest CVS
}
} It's probably a good thing that our test suites are starting to catch
} more regressions:
} 
} /usr/local/src/zsh-2001-07-05/Test/D04parameter.ztst: starting.
} *** /tmp/zsh.ztst.out.2596	Thu Jul  5 23:19:53 2001
} --- /tmp/zsh.ztst.tout.2596	Thu Jul  5 23:19:53 2001
} ***************
} *** 1,4 ****
} ! where is the white windmill, wly
} --- 1,4 ----
} ! wly
} Test /usr/local/src/zsh-2001-07-05/Test/D04parameter.ztst failed: output differs from expected as shown above for:
}   print ${(S)string%%h*e}

This isn't a regression, it's an intentional change; but the test was
not brought up to date.

The question is, -should- it have been changed?  The effect of 15266 is
that, with the (S) flag, ## and %% are the same, unless you use (I::);
and I think the new meaning of (I::) is even more difficult to understand
than it was to explain.

Here's before 15266:

schaefer[501] foo='where I was standing lizards crawled here and there around'
schaefer[502] print ${(S)foo%%h*ere}
where I was standing lizards crawled here and t around
schaefer[503] print ${(I:2:S)foo%%h*ere}
where I was standing lizards crawled  around
schaefer[504] print ${(I:3:S)foo%%h*ere}
w around
schaefer[505] foo='where is the white windmill, whispered walter wisely'
schaefer[506] print ${(S)foo%%h*e}
where is the white windmill, wly
schaefer[507] print ${(I:2:S)foo%%h*e}
where is the wly
schaefer[508] print ${(I:3:S)foo%%h*e}
where is tly

Here's after 15266:

schaefer<501> foo='where I was standing lizards crawled here and there around'
schaefer<502> print ${(S)foo%%h*ere}
w around
schaefer<503> print ${(I:2:S)foo%%h*ere}
w and there around
schaefer<504> print ${(I:3:S)foo%%h*ere}
w I was standing lizards crawled here and there around
schaefer<505> foo='where is the white windmill, whispered walter wisely'
schaefer<506> print ${(S)foo%%h*e}
wly
schaefer<507> print ${(I:2:S)foo%%h*e}
wr wisely
schaefer<508> print ${(I:3:S)foo%%h*e}
wd walter wisely

This seems backwards to me.  Indices with % and %% should count from
the end of the string leftwards, not from the beginning of the string
rightwards, and always before it has been the case that the indices are
for the -start- of the match, not for the end of it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Test Failures Latest CVS

[Peter Stephenson]

"Bart Schaefer" wrote:
> The question is, -should- it have been changed?  The effect of 15266 is
> that, with the (S) flag, ## and %% are the same, unless you use (I::);
> and I think the new meaning of (I::) is even more difficult to understand
> than it was to explain.
> 
> Here's before 15266:
> 
> schaefer[501] foo='where I was standing lizards crawled here and there around
> '
schaefer[502] print ${(S)foo%%h*ere}
> where I was standing lizards crawled here and t around

Aha.  I leaped on this thinking it hadn't picked the longest match and was
therefore wrong.  You're saying that since it consistently searches
backwards using the *start* of the string, not the end, it is the longest
match from that point, and it won't be able to find a longer until the
start has moved back.

I already realised the change was incompatible with the way % worked, so
I'll back it out and instead think of something to upgrade the
documentation.  I'm just tackling this in the user guide, but tackling it
at 11 pm after working all day probably wasn't ideal.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Test Failures Latest CVS

[Peter Stephenson]

"Bart Schaefer" wrote:
> The question is, -should- it have been changed?
> ... difficult to understand ...
> ... This seems backwards to me. ...
> ... always before it has been the case ...

One real bug turned up here, at least.  This is after removing that patch.

% foo='where i walked lizards wandered here and there around'
% print ${(S)foo%%(#b)(h*e)} 
where i walked lizards wandered here and t around
% print ${foo[$mbegin,$mend]}
ere 
% print $mbegin
-10
% print $mend
-7

Those should always be positive; the fact they appear close to correct when
counting backwards is a coincidence.

Index: Src/glob.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/glob.c,v
retrieving revision 1.19
diff -u -r1.19 glob.c
--- Src/glob.c	2001/07/06 09:03:48	1.19
+++ Src/glob.c	2001/07/06 09:14:49
@@ -2236,16 +2236,17 @@
 	    break;
 
 	case (SUB_END|SUB_SUBSTR):
-	    /* Shortest at end with substrings */
-	    patoffset = ml;
-	    set_pat_start(p, l);
-	    if (pattry(p, s + l) && !--n) {
-		*sp = get_match_ret(*sp, l, l, fl, replstr);
-		patoffset = 0;
-		return 1;
-	    } /* fall through */
 	case (SUB_END|SUB_LONG|SUB_SUBSTR):
 	    /* Longest/shortest at end, matching substrings.       */
+	    patoffset = ml;
+	    if (!(fl & SUB_LONG)) {
+		set_pat_start(p, l);
+		if (pattry(p, s + l) && !--n) {
+		    *sp = get_match_ret(*sp, l, l, fl, replstr);
+		    patoffset = 0;
+		    return 1;
+		}
+	    }
 	    patoffset--;
 	    for (t = s + l - 1; t >= s; t--, patoffset--) {
 		if (t > s && t[-1] == Meta)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Test Failures Latest CVS

[Peter Stephenson]

Peter Stephenson wrote:
> "Bart Schaefer" wrote:
> > The question is, -should- it have been changed?
> > ... difficult to understand ...
> > ... This seems backwards to me. ...
> > ... always before it has been the case ...
> ... real bug ...
> ... removing that patch. ...

OK, have I got the description right this time?

Index: Doc/Zsh/expn.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/expn.yo,v
retrieving revision 1.31
diff -u -r1.31 expn.yo
--- Doc/Zsh/expn.yo	2001/07/06 09:03:48	1.31
+++ Doc/Zsh/expn.yo	2001/07/06 09:49:17
@@ -791,10 +791,26 @@
 This only applies when searching for substrings, either with the tt(S)
 flag, or with tt(${)...tt(/)...tt(}) (only the var(expr)th match is
 substituted) or tt(${)...tt(//)...tt(}) (all matches from the
-var(expr)th on are substituted).  The var(expr)th match is counted
-such that there is either one or zero matches from each starting
-position in the string, although for global substitution matches
-overlapping previous replacements are ignored.
+var(expr)th on are substituted).  The default is to take the first match.
+
+The var(expr)th match is counted such that there is either one or zero
+matches from each starting position in the string, although for global
+substitution matches overlapping previous replacements are ignored.  With
+the tt(${)...tt(%)...tt(}) and tt(${)...tt(%%)...tt(}) forms, the starting
+position for the match moves backwards from the end as the index increases,
+while with the other forms it moves forward from the start.
+
+Hence with the string
+example(which switch is the right switch for Ipswich?)
+substitutions of the form
+tt(${)LPAR()tt(SI:)var(N)tt(:)RPAR()tt(string#w*ch}) as var(N) increases
+from 1 will match and remove `tt(which)', `tt(witch)', `tt(witch)' and
+`tt(wich)'; the form using `tt(##)' will match and remove `tt(which switch
+is the right switch for Ipswich)', `tt(witch is the right switch for
+Ipswich)', `tt(witch for Ipswich)' and `tt(wich)'. The form using `tt(%)'
+will remove the same matches as for `tt(#)', but in reverse order, and the
+form using `tt(%%)' will remove the same matches as for `tt(##)' in reverse
+order.
 )
 item(tt(M))(
 Include the matched portion in the result.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Test Failures Latest CVS

[Bart Schaefer]

On Jul 6, 10:50am, Peter Stephenson wrote:
} Subject: Re: Test Failures Latest CVS
}
} OK, have I got the description right this time?
} 
} +The form using `tt(%)'
} +will remove the same matches as for `tt(#)', but in reverse order, and the
} +form using `tt(%%)' will remove the same matches as for `tt(##)' in reverse
} +order.

Yes, I think that's got it.  Treat yourself to a black pudding.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net