[
http://issues.apache.org/jira/browse/LUCENE-700?page=comments#action_12444811 ]
kaineci commented on LUCENE-700:
loop may be rewriten :while((bucket!=null) && (fisrst || (bucket !=
firstElem))) where firstElem stores the first elements of buck
endless loop when querying using BooleanQuery.
--
Key: LUCENE-700
URL: http://issues.apache.org/jira/browse/LUCENE-700
Project: Lucene - Java
Issue Type: Bug
Components: Search
: I don't recall any commits in the lucene_2_0 branch, I think everything
: since 2.0 has been getting committed in the trunk, and my guess is those
: are just human errors in JIRA. But I think your interpretation of how
: Fix Versions should be read is correct.
this is the past thread i was thi
[
http://issues.apache.org/jira/browse/LUCENE-682?page=comments#action_12444776 ]
Otis Gospodnetic commented on LUCENE-682:
-
I like this and have a question. The createLocalizedTokenMap() method is
called from that new setter method.
Si
[
http://issues.apache.org/jira/browse/LUCENE-489?page=comments#action_12444774 ]
Otis Gospodnetic commented on LUCENE-489:
-
Q: why is this property called "allowZeroLengthPrefixQuery"? Because instead
of XXX*YYY, one can now have just
[ http://issues.apache.org/jira/browse/LUCENE-694?page=all ]
Otis Gospodnetic resolved LUCENE-694.
-
Resolution: Duplicate
Eric, I think this is a duplicate of LUCENE-372.
> Query parser doesn't warn about unmatched ')'
> ---
[ http://issues.apache.org/jira/browse/LUCENE-657?page=all ]
Otis Gospodnetic resolved LUCENE-657.
-
Resolution: Fixed
Applied in the trunk, thanks.
> FuzzyQuery should not be final
> --
>
> Key: LUCENE-657
I think we want to keep things as simple, yet organized.
Assigning issues to oneself is really useful for issues that require more time,
so it's clear who's working on them.
I probably made a mistake assigning myself that one issue just to commit it. I
wanted to signal I'd take care of it, but I
[
http://issues.apache.org/jira/browse/LUCENE-693?page=comments#action_12444770 ]
Yonik Seeley commented on LUCENE-693:
-
conjunction.patch.nosort1 is a slightly more elegant solution that does
not require any initial setup of the scorers (no
Steven,
I don't recall any commits in the lucene_2_0 branch, I think everything since
2.0 has been getting committed in the trunk, and my guess is those are just
human errors in JIRA. But I think your interpretation of how Fix Versions
should be read is correct.
Otis
- Original Message -
[ http://issues.apache.org/jira/browse/LUCENE-693?page=all ]
Yonik Seeley updated LUCENE-693:
Attachment: conjunction.patch.nosort1
> ConjunctionScorer - more tuneup
> ---
>
> Key: LUCENE-693
>
[
http://issues.apache.org/jira/browse/LUCENE-686?page=comments#action_12444766 ]
Ning Li commented on LUCENE-686:
But removing TermDocs.close() will leave IndexInput.close() in a
similar half-in/half-out situation: e.g. close() will not be call
[ http://issues.apache.org/jira/browse/LUCENE-697?page=all ]
Doron Cohen reassigned LUCENE-697:
--
Assignee: Doron Cohen
> Scorer.skipTo affects sloppyPhrase scoring
> --
>
> Key: LUCENE-697
>
[
http://issues.apache.org/jira/browse/LUCENE-686?page=comments#action_12444758 ]
Steven Parkes commented on LUCENE-686:
--
Well, this has been a nice example to drive me into some of the internals.
It seems like close() methods are around in
[
http://issues.apache.org/jira/browse/LUCENE-697?page=comments#action_12444756 ]
Yonik Seeley commented on LUCENE-697:
-
> Yonik, this is uassigned, are you working on a fix for this?
Nope, feel free to grab it :-)
> Scorer.skipTo affects s
[
http://issues.apache.org/jira/browse/LUCENE-697?page=comments#action_12444744 ]
Doron Cohen commented on LUCENE-697:
I can reproduce this by uncommenting this line.
Interesting to notice that:
(1) the sequence to next() next() skip() ski
[
http://issues.apache.org/jira/browse/LUCENE-686?page=comments#action_12444742 ]
Doron Cohen commented on LUCENE-686:
An example of how current Lucene code relies on not having to close resoures,
in PhraseQuery:
...
scorer(IndexRead
One thing that may be causing problems is that "cooc" is not summing on the
various cases that the "ignore case equality" holds. Since you are ignoring
cases I assume the analyzer being used is not a lower casing one, so in
this case if you have terms f:a and f:A you would get a count of 1 instead
I was wondering about that. Oh, well, figures I'd get it wrong the first
time ...
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 11:17 AM
To: java-dev@lucene.apache.org
Subject: RE: [jira] Commented: (LUCENE-657) FuzzyQuery should not
[ http://issues.apache.org/jira/browse/LUCENE-657?page=all ]
Steven Parkes updated LUCENE-657:
-
Attachment: LUCENE-657.patch
This version of the patch omits making the member variables public. FuzzyQuery
is no longer final and some of the nested classes
[ http://issues.apache.org/jira/browse/LUCENE-657?page=all ]
Steven Parkes updated LUCENE-657:
-
Attachment: (was: fuzzy.patch)
> FuzzyQuery should not be final
> --
>
> Key: LUCENE-657
> URL
: I was in the middle of updating it.
Ah . i *really* don't think we should ever replace one patch with
another ... it makes it impossible to compare the pros/cons of the two
approaches.
: -Original Message-
: From: Chris Hostetter [mailto:[EMAIL PROTECTED]
: Sent: Wednesday, Octob
I was in the middle of updating it.
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 11:10 AM
To: java-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENE-657) FuzzyQuery should not be
final
what happend to the patch for this
what happend to the patch for this issue? ... there doesn't seem to be
anything attached to it in Jira.
: Date: Wed, 25 Oct 2006 11:02:28 -0700
: From: Andreas Neumann <[EMAIL PROTECTED]>
: Reply-To: java-dev@lucene.apache.org
: To: java-dev@lucene.apache.org
: Subject: Re: [jira] Commented: (LU
Two comments:
1. In this particular case, all I need is the ability to override base
class method
getEnum(). No need to access or change member variables. As the class already
defines getters for the members, the members can remain private.
2. I noticed that many members have package (defaul
: There a number of resolved Jira issues that spec the Fix Version/s as
: 2.0.1. I'm wondering if I'm interpreting this correctly: to me, this
: would mean that the changes have been checked into branches/lucene_2_0,
: not trunk. But these were actually checked into trunk. As far as the
I believe
svn annotates the jira logs, which is more than a comment, but still not
navigable
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:37 AM
To: java-dev@lucene.apache.org
Subject: RE: jira workflow
: Since that's not the case now, I'
A question about releases, mostly with respect to Jira, I guess.
There a number of resolved Jira issues that spec the Fix Version/s as
2.0.1. I'm wondering if I'm interpreting this correctly: to me, this
would mean that the changes have been checked into branches/lucene_2_0,
not trunk. But these w
: Since that's not the case now, I'd suggest it's reasonable for a
: committer to commit w/o changing the assignee, only changing the state
: to resolved. Facilitates communication on issues that might arise later
: and helps gauge individual involvement.
I guess it depends on how we want to defi
[ http://issues.apache.org/jira/browse/LUCENE-699?page=all ]
Hoss Man resolved LUCENE-699.
-
Resolution: Invalid
Please do not post questions in Jira -- questions and general discussion about
using Lucene should take place on the java-user mailing list.
Jir
Follow up on the workflow stuff:
With a larger group of people able to work at the Jira level, do we want
to have an approach to assignee? Otis was getting ready to commit a
patch I had shepherded through and assigned the issue to himself in the
process. This is what's always been done in the past
Hello, this is BM25 algorithm I implement in Lucene.
it doen't work because I have compaired my results with the results of MG4J
(with the same documents set)
I don't know if I have a wrong formule or there are another mistake
Could you help me ?
---
-- Forwarded message --
From: John Fawcett <[EMAIL PROTECTED]>
Date: Wed, 25 Oct 2006 08:39:23 -0400
Subject: Client-Server Lucene - DocumentWriter
To: [EMAIL PROTECTED]
Hi,
I have a design challenge in my own application's use of Lucene, which
triggered an idea for distributed L
question in BooleanScorer
-
Key: LUCENE-699
URL: http://issues.apache.org/jira/browse/LUCENE-699
Project: Lucene - Java
Issue Type: Wish
Components: Search
Reporter: kaineci
when studying the l
34 matches
Mail list logo
