: I want to use the PorterStemmer class, but as it is not visible to
: outside the package I am unable to use it.
I believe it's not intended for direct use -- that's what the
PorterStemFilter is for.
-Hoss
-
To unsubscribe,
[
http://issues.apache.org/jira/browse/LUCENE-605?page=comments#action_12416719 ]
Hoss Man commented on LUCENE-605:
-
> The point is that adding by adding a match indicator to Explanation,
> Explanation becomes less useful
> to explain a subformula of a (mat
[
http://issues.apache.org/jira/browse/LUCENE-398?page=comments#action_12416734 ]
Christian Kohlschuetter commented on LUCENE-398:
The NullPointerException is probably caused by a broken implementation of
ParallelTermEnum.next().
The method
[ http://issues.apache.org/jira/browse/LUCENE-398?page=all ]
Christian Kohlschuetter updated LUCENE-398:
---
Attachment: patch-next.diff
Patches broken implementation of ParallelTermEnum.next()
> ParallelReader crashes when trying to merge into
Thanks Hoss. I submitted a JIRA issue:
http://issues.apache.org/jira/browse/INFRA-852
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Monday, June 19, 2006 2:11 AM
To: Lucene Dev
Cc: general@incubator.apache.org
Subject: RE: Lucene.NET Jira Emails?
: If this i
[ http://issues.apache.org/jira/browse/LUCENE-398?page=all ]
Christian Kohlschuetter updated LUCENE-398:
---
Attachment: ParallelReaderTest1.java
JUnit Testcase that triggers the bug.
> ParallelReader crashes when trying to merge into a new index
[
http://issues.apache.org/jira/browse/LUCENE-561?page=comments#action_12416738 ]
Christian Kohlschuetter commented on LUCENE-561:
Chuck: Unfortunately, the NPE in seek/next can still be triggered.
See [#LUCENE-398] for Testcase and a suggest
Change behavior of ParallelReader.document(int)
---
Key: LUCENE-606
URL: http://issues.apache.org/jira/browse/LUCENE-606
Project: Lucene - Java
Type: Improvement
Components: Index
Versions: 2.0.0
Reporter:
[ http://issues.apache.org/jira/browse/LUCENE-606?page=all ]
Christian Kohlschuetter updated LUCENE-606:
---
Attachment: patch-allfields.diff
Patch to ParallelReader. Implementation of the proposed parameter.
> Change behavior of ParallelReade
[ http://issues.apache.org/jira/browse/LUCENE-606?page=all ]
Christian Kohlschuetter updated LUCENE-606:
---
Attachment: ParallelReaderTest2.java
Testcase demonstrating the new feature.
> Change behavior of ParallelReader.document(int)
> ---
On 6/17/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
Ray Tsang wrote on 06/17/2006 06:29 AM:
> I think the problem right now isn't whether we are going to have 1.5
> code or not. We will eventually have to have 1.5 code anyways. But
> we need a sound plan that will make the transition easy.
[
http://issues.apache.org/jira/browse/LUCENE-398?page=comments#action_12416782 ]
Christian Kohlschuetter commented on LUCENE-398:
Files:
http://issues.apache.org/jira/secure/attachment/12335614/patch-next.diff
http://issues.apache.org/jira/
Ray Tsang wrote:
We have statistics of number of users between 1.4 vs. 1.5 (which btw
didn't present a significant polarization)
Does 63% for 1.5, a nearly 2:1 ratio, really represent an insignificant
polarization? (As of this writing, 88/140 reported using 1.5).
but how about actual numbe
Ray Tsang wrote on 06/19/2006 09:06 AM:
> On 6/17/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
>>
>> Ray Tsang wrote on 06/17/2006 06:29 AM:
>> > I think the problem right now isn't whether we are going to have 1.5
>> > code or not. We will eventually have to have 1.5 code anyways. But
>> > we
On 6/19/06, Steven Rowe <[EMAIL PROTECTED]> wrote:
Ray Tsang wrote:
> We have statistics of number of users between 1.4 vs. 1.5 (which btw
> didn't present a significant polarization)
Does 63% for 1.5, a nearly 2:1 ratio, really represent an insignificant
polarization? (As of this writing, 88/1
[
http://issues.apache.org/jira/browse/LUCENE-605?page=comments#action_12416788 ]
paul.elschot commented on LUCENE-605:
-
The purpose of Explanation is to explain all the "mysteries" of query search,
so it would be worthwhile to use an extra class for th
On 6/19/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
Ray Tsang wrote on 06/19/2006 09:06 AM:
> On 6/17/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
>>
>> Ray Tsang wrote on 06/17/2006 06:29 AM:
>> > I think the problem right now isn't whether we are going to have 1.5
>> > code or not. We wil
Why not just make 2.1 use 1.5, and if there are enough 1.4 people they can
back-port the changes into 2.0 using JDK 1.4 only code? If they decide it is
too much work, they can move forward to JDK 1.5, stick with Lucene 2.0
release X, or find another search project.
Although I agree with Doug that
[
http://issues.apache.org/jira/browse/LUCENE-561?page=comments#action_12416790 ]
Chuck Williams commented on LUCENE-561:
---
Christian,
That is a different bug than this one. This bug has been fixed.
Chuck
> ParallelReader fails on deletes and on se
On 6/19/06, Robert Engels <[EMAIL PROTECTED]> wrote:
Why not just make 2.1 use 1.5, and if there are enough 1.4 people they can
back-port the changes into 2.0 using JDK 1.4 only code? If they decide it is
too much work, they can move forward to JDK 1.5, stick with Lucene 2.0
release X, or find an
[
http://issues.apache.org/jira/browse/LUCENE-605?page=comments#action_12416792 ]
Hoss Man commented on LUCENE-605:
-
Hmmm... a subclass relationship might make a lot of sense here ... if we add an
isMatch() method to the existing "Explanation" which infers
Chris Hostetter wrote:
2) SpanScorer.explain HACK fix
NearSpans.skipTo is broken (see LUCENE-569). This apparently doesn't
affect too many people (or if it does, they haven't been filing bugs about
it) but it does make SpanScorer.explain lie. I don't understand
SpanQueries enough to feel co
[
http://issues.apache.org/jira/browse/LUCENE-398?page=comments#action_12416798 ]
Chuck Williams commented on LUCENE-398:
---
Christian,
I think you can make this more efficient by caching the field iterator. You
only need to generate it at the first t
On Monday 19 June 2006 21:07, Grant Ingersoll wrote:
>
> Chris Hostetter wrote:
> > 2) SpanScorer.explain HACK fix
> >
> > NearSpans.skipTo is broken (see LUCENE-569). This apparently doesn't
> > affect too many people (or if it does, they haven't been filing bugs about
> > it) but it does make
Ray Tsang wrote on 06/19/2006 09:06 AM:
> Don't get me wrong. My point is _not_ not to accept 1.5 code. By all
> means we should accept it. But it'll be better if there is a simple
> way to accept it while at least majority of lucene-core.jar is
> compatible w/ 1.4 at bytecode level, while, say
: > > Should This HACK be commited, or is it better to leave explanations for
: > > SpanNear queries broken untill someone has the confidence to fix
LUCENE-569?
: > I think it would be all right as long as you make a note of it on the
: > 569 issue and in the code so that people know why the cha
>>One point that I feel keeps getting ignored is that we are talking
about the _future_ releases.
>>My guess is that we won't see a major new Lucene release before 2007,
and by that time the latest JVM will probably be 1.6.
I think that's a non-argument as it is common practice for people to
w
There is a new Lucene sub-project named Lucy. It will focus on building
a C-based core for Lucene, to facilitate ports of Lucene to other
languages, such as Perl and Ruby.
For more information, please visit:
http://lucene.apache.org/lucy/
Doug
---
I don't think this should be dismissed as a non-argument. You want to live on
the edge of Lucene, but at the same time don't want to (probably can't, I know)
use the current JVM that's been out for a long time now (a year or more, I
think, didn't check). You can look at the "but I want the lat
> I think Chuck's suggestion was the best one so far:
> - allow 1.5 in trunk
> - those who want/need 1.4 can back-port it
Hmmm, seems a lot like just kissing off 1.4 users.
Just-an-interested-bystander-here,
Bill
-
To unsubscri
I am getting really tired of the tone by some of "comments".
Nothing that is being proposed here is ANY DIFFERENT than any other software
package or library. As software progresses the requirements change - whether
it is hardware needed, or software needed.
No one is kissing off 1.4 users - 1.4 u
[ http://issues.apache.org/jira/browse/LUCENE-557?page=all ]
Hoss Man resolved LUCENE-557:
-
Resolution: Fixed
Based on my gut feelings and some limited feedback from the list, i've commited
the additions to CheckHits, the patches for BooleanQuery and F
[ http://issues.apache.org/jira/browse/LUCENE-569?page=all ]
Hoss Man updated LUCENE-569:
Attachment: SpanScorer.explain.testcase.patch
Attitional test case patch that should work if this bug is fixed. (orriginally
from LUCENE-557 but uncommited)
> NearSp
[ http://issues.apache.org/jira/browse/LUCENE-451?page=all ]
Hoss Man updated LUCENE-451:
Attachment: bq.containing.clause.with.zero.boost.tests.patch
some test cases demonstrating discrepencies when a BooleanQuery has clauses of
various types with boosts o
[
http://issues.apache.org/jira/browse/LUCENE-398?page=comments#action_12416837 ]
Chuck Williams commented on LUCENE-398:
---
Christian,
I'm going to open a new issue on this in order to rename it, post a revised
patch, and hopefully get the attention o
ParallelTermEnum is BROKEN
--
Key: LUCENE-607
URL: http://issues.apache.org/jira/browse/LUCENE-607
Project: Lucene - Java
Type: Bug
Components: Index
Versions: 2.0.0
Reporter: Chuck Williams
Priority: Critical
Attachments
[ http://issues.apache.org/jira/browse/LUCENE-607?page=all ]
Chuck Williams updated LUCENE-607:
--
Attachment: ParallelTermEnum.patch
> ParallelTermEnum is BROKEN
> --
>
> Key: LUCENE-607
> URL: http://issues.apac
[
http://issues.apache.org/jira/browse/LUCENE-398?page=comments#action_12416838 ]
Chuck Williams commented on LUCENE-398:
---
Revised patch posted in LUCENE-607
> ParallelReader crashes when trying to merge into a new index
> ---
Just got back from a long weekend vacation without any net access.
Talk about withdrawal:)
I have just gotten through reading this entire thread... Whew.
On Jun 19, 2006, at 8:48 PM, Robert Engels wrote:
People making these arguments against 1.5 sound really ill-
informed, or
lazy. Neith
I think my comment is being taken in a way that was not totally intended.
The "lazy" refers to the ability/desire of the 1.4 "users & developers" to
devote their resources to back-porting the code to the 2.0.X release. Rather
than having the 1.5 developers having to waste their time "thinking" in
40 matches
Mail list logo
