FYI this got just checked in:
https://issues.apache.org/jira/browse/LUCENE-9965.
I'd be curious to know if it helps with your problem, Mike.
On Wed, May 12, 2021 at 1:54 PM Adrien Grand wrote:
> Indeed this is code is ASL2 pre-7.10, but I wouldn't have expected any
> concerns regardless. Jack
Oh my god. is an invention going back to Netscape 4. I have no idea how
it came into HTML5, it has nothing to do with structuring documents in HTML
sense, it's from the time before there was Unicode.
The correct replacement is a zero-width-space (Unicode U+200B).
AMEN!
Uwe
-
Uwe
Hey all,
Quick update: I've removed the javax.annotation dependency declaration
that the build didn't like. Precommit and tests pass. I've pushed
the fix to branch_8_9. I'm currently running buildAndPushRelease.py +
smoke-tester and will give the all-clear once I see that pass.
Sorry to hold
Alan, I'd also like to comment on this:
The reason we have TokenStreamComponents and ReuseStrategies (as I
understand it) is not because they may have to load large resource
files or dictionaries or whatever, but it’s because building a
TokenStream is itself quite a heavy operation due to
Yes I'm using the term "Analyzer" in a generic sense, also concerned
about TokenStream init costs, garbage, etc.
There are a ton of uses here other than indexwriter,
AnalyzingSuggesters building FSTs, etc etc.
I don't think we need to try to add even more complexity because of
users implementing
Hey Robert,
Analyzers themselves can be heavy and load large data files, etc, I agree, but
I’m really talking about token stream construction. The way things are set up,
we expect the heavy lifting to be done when the Analyzer is constructed, but
these heavy resources should then be shared
just pushed fix; we should stop seeing this failure now
On Wed, Jun 9, 2021 at 3:51 AM Apache Jenkins Server
wrote:
>
> Build:
> https://ci-builds.apache.org/job/Lucene/job/Lucene-NightlyTests-main/297/
>
> 1 tests failed.
> FAILED:
>
