[jira] Commented: (LUCENE-700) endless loop when querying using BooleanQuery.

2006-10-25 Thread kaineci (JIRA)
[ 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

[jira] Created: (LUCENE-700) endless loop when querying using BooleanQuery.

2006-10-25 Thread kaineci (JIRA)
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

Re: releases

2006-10-25 Thread Chris Hostetter
: 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

[jira] Commented: (LUCENE-682) QueryParser with Locale Based Operators (French included)

2006-10-25 Thread Otis Gospodnetic (JIRA)
[ 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

[jira] Commented: (LUCENE-489) Allow QP subclasses to support Wildcard Queries with leading "*"

2006-10-25 Thread Otis Gospodnetic (JIRA)
[ 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

[jira] Resolved: (LUCENE-694) Query parser doesn't warn about unmatched ')'

2006-10-25 Thread Otis Gospodnetic (JIRA)
[ 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 ')' > ---

[jira] Resolved: (LUCENE-657) FuzzyQuery should not be final

2006-10-25 Thread Otis Gospodnetic (JIRA)
[ 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

Re: jira workflow

2006-10-25 Thread Otis Gospodnetic
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

[jira] Commented: (LUCENE-693) ConjunctionScorer - more tuneup

2006-10-25 Thread Yonik Seeley (JIRA)
[ 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

Re: releases

2006-10-25 Thread Otis Gospodnetic
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 -

[jira] Updated: (LUCENE-693) ConjunctionScorer - more tuneup

2006-10-25 Thread Yonik Seeley (JIRA)
[ 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 >

[jira] Commented: (LUCENE-686) Resources not always reclaimed in scorers after each search

2006-10-25 Thread Ning Li (JIRA)
[ 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

[jira] Assigned: (LUCENE-697) Scorer.skipTo affects sloppyPhrase scoring

2006-10-25 Thread Doron Cohen (JIRA)
[ 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 >

[jira] Commented: (LUCENE-686) Resources not always reclaimed in scorers after each search

2006-10-25 Thread Steven Parkes (JIRA)
[ 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

[jira] Commented: (LUCENE-697) Scorer.skipTo affects sloppyPhrase scoring

2006-10-25 Thread Yonik Seeley (JIRA)
[ 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

[jira] Commented: (LUCENE-697) Scorer.skipTo affects sloppyPhrase scoring

2006-10-25 Thread Doron Cohen (JIRA)
[ 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

[jira] Commented: (LUCENE-686) Resources not always reclaimed in scorers after each search

2006-10-25 Thread Doron Cohen (JIRA)
[ 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

Re: wrong BM25 implementation in Lucene

2006-10-25 Thread Doron Cohen
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

RE: [jira] Commented: (LUCENE-657) FuzzyQuery should not be final

2006-10-25 Thread Steven Parkes
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

[jira] Updated: (LUCENE-657) FuzzyQuery should not be final

2006-10-25 Thread Steven Parkes (JIRA)
[ 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

[jira] Updated: (LUCENE-657) FuzzyQuery should not be final

2006-10-25 Thread Steven Parkes (JIRA)
[ 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

RE: [jira] Commented: (LUCENE-657) FuzzyQuery should not be final

2006-10-25 Thread Chris Hostetter
: 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

RE: [jira] Commented: (LUCENE-657) FuzzyQuery should not be final

2006-10-25 Thread Steven Parkes
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

Re: [jira] Commented: (LUCENE-657) FuzzyQuery should not be final

2006-10-25 Thread Chris Hostetter
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

Re: [jira] Commented: (LUCENE-657) FuzzyQuery should not be final

2006-10-25 Thread Andreas Neumann
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

Re: releases

2006-10-25 Thread Chris Hostetter
: 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

RE: jira workflow

2006-10-25 Thread Steven Parkes
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'

releases

2006-10-25 Thread Steven Parkes
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

RE: jira workflow

2006-10-25 Thread Chris Hostetter
: 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

[jira] Resolved: (LUCENE-699) question in BooleanScorer

2006-10-25 Thread Hoss Man (JIRA)
[ 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

RE: jira workflow

2006-10-25 Thread Steven Parkes
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

wrong BM25 implementation in Lucene

2006-10-25 Thread beatriz ramos
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 ? ---

Fwd: Client-Server Lucene - DocumentWriter

2006-10-25 Thread John Fawcett
-- 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

[jira] Created: (LUCENE-699) question in BooleanScorer

2006-10-25 Thread kaineci (JIRA)
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