the prefix but java.util.regex for the actual matching
in order to have the best of both worlds.
I may have over-engineered it a bit, though I'm not sure. I'm in
the process of documenting beyond just the unit tests, and likely
will also document how to use regex queries along wit
g in order to have the best of
both worlds.
I may have over-engineered it a bit, though I'm not sure. I'm in the
process of documenting beyond just the unit tests, and likely will
also document how to use regex queries along with term rotation in
order to really minimize term r
Following up on the (Span)RegexQuery topic, I've started working on
moving this code to contrib/regex so that it can leverage various
regex implementations. I'm making a generic interface that currently
(though subject to change) has these methods:
void compile(String pattern);
boolean
On Friday 25 November 2005 11:14, Erik Hatcher wrote:
>
> On 24 Nov 2005, at 20:26, Erik Hatcher wrote:
> >> There are some older regex implementations in java, but I
> >> have no idea about the licences and the availabiility.
> >> Doesn't apache have one somewhere?
> >
> > Two actually! ORO and
On 24 Nov 2005, at 20:26, Erik Hatcher wrote:
There are some older regex implementations in java, but I
have no idea about the licences and the availabiility.
Doesn't apache have one somewhere?
Two actually! ORO and Regexp. Here's ORO - jakarta.apache.org/oro/> (link to Regexp from there)
On 24 Nov 2005, at 11:57, Paul Elschot wrote:
Capturing groups and special contexts need normal brackets ().
Maybe we have a terminology mismatch. I call these (parentheses) and
these [brackets].
Capturing groups are used for replacements, and I don't see a use
for that in a query langua
> enumeration a calculation of of the maximum non-regex piece is
> needed, including a calculation on whether the head and tail combined
> make a larger prefix. For example, using '$' to denote the end of
> the string, the rotated version of this should be:
>
> T
f this should be:
Total$ThisContainsTwo[abc]RegexPieces.*
With a regex parse tree, it should be possible to be wise about what
is a static prefix and to compute the size of all the static pieces
allowing for clever rotation to make regex queries as efficient as
possible. Now where is
On Thursday 24 November 2005 00:06, Erik Hatcher wrote:
>
> On 23 Nov 2005, at 15:42, Paul Elschot wrote:
> > I refactored it to have a few more tests, and all seems to work well.
> > It also includes the tests from TestSpanRegexQuery.java .
> >
...
>
> > To parse a regex query term, the surround
On 23 Nov 2005, at 15:42, Paul Elschot wrote:
I refactored it to have a few more tests, and all seems to work well.
It also includes the tests from TestSpanRegexQuery.java .
Two questions:
Can I assume the APL2 on Test{,Span}RegexQuery.java?
If so, I'll post the refactored version with it.
Y
Dear readers,
I'd like to add regex queries to the surround parser, so I had a look
at the test code for the regex queries.
I refactored it to have a few more tests, and all seems to work well.
It also includes the tests from TestSpanRegexQuery.java .
Two questions:
Can I assume the AP
11 matches
Mail list logo
