From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Sun, 29 Jan 2006 01:15:27 +0900 (JST)
The patch proposed on Mon, 23 Jan 2006 has been cancelled,
and here is another patch.
Hopefully improved.
TODO:
This patch cannot make the following test pass.
/^(b+?|a){1,2}?c/
bbac
0: bbac
1: a
/b+?/
The patch proposed on Mon, 23 Jan 2006 has been cancelled,
and here is another patch.
TODO:
This patch cannot make the following tests pass.
/(([a-c])b*?\2)*/
ababbbcbc
0: ababb
1: bb
2: b
gnu.regexp finds ababbbcbc instead of ababb.
/^(b+?|a){1,2}?c/
bbc
0: bbc
1: b
gnu.regexp
Ito == Ito Kazumitsu [EMAIL PROTECTED] writes:
Ito I am beginning to think that gnu.regexp is doing more than is
Ito expected:
Ito Find all possible matches and select the best match.
[...]
Ito If we can simplufy the work of getMatchImpl(), we will be
Ito getting the same results as other
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Tue, 24 Jan 2006 07:25:29 +0900 (JST)
This is an ad hoc fix and not carefully designed. I can think of problems
such as
How should we compare an stingy match and a non-stingy match?
I am beginning to think that gnu.regexp is doing more than is
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Tue, 24 Jan 2006 23:37:52 +0900 (JST)
If we can simplufy the work of getMatchImpl(), we will be
getting the same results as other implementations as well as
improved performance.
In that case, when matches() call getMatchImpl(), an implicit
Another fix of gnu.regexp package.
After checkin this in, I will move some more Mauve testcases of
gnu/testlet/java/util/regex/Pattern/testdata2
to
gnu/testlet/java/util/regex/Pattern/testdata1
In my local environment, 436 cases in testdata1 pass.
Remained in testdata2 are:
(1)
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Mon, 23 Jan 2006 23:06:42 +0900 (JST)
--- classpath/gnu/regexp/REMatch.java 22 Jan 2006 02:22:21 - 1.3
+++ classpath/gnu/regexp/REMatch.java 23 Jan 2006 13:43:12 -
+Vector repeats; // number of repeats of each stingy repeated token
