Re: HighlighterTest failure

2005-04-25 Thread Chuck Williams
Erik Hatcher wrote:
On Apr 25, 2005, at 10:02 PM, Chuck Williams wrote:
Erik Hatcher wrote:
I get a failure running HighlighterTest from the Subversion trunk. 
Below are the details.

What's the fix?

I don't have the code here to run, but the problem is that 
MultiSearcher.rewrite(line 298) is calling Query.combine, which 
requires all the combined queries to be equal. Obviously they will 
not be equal in general for multi-term queries (PrefixQuery's in this 
case) since those queries expand into different terms for the 
different searchers. Just above the failing line in 
MultiSearcher.rewrite() it rewrites the query it was passed from the 
parser in the HighlighterTest. This should be a PrefixQuery, which 
should rewrite into two BooleanQuery's, which should then lead to 
BooleanQuery.combine() and not Query.combine(). So it appears that 
either the query parser did not produce a PrefixQuery, or you don't 
have the current code?

Could you step through it and find out what kind of query is passes 
to MultiSearcher.rewrite() and what comes back from the 2 rewrite() 
calls made there for the two searchers?

PrefixQuery being passed to MultiSearcher.rewrite()... and the 2 
rewrites each rewrite to the expanded Query (an optimized TermQuery in 
this case).

I've got the current trunk code.
*shrugs*
Erik, this patch will fix the problem. It passes all Lucene and 
Highlighter tests, except for Otis's TestSort issue, which as I noted 
earlier is a bug in the test. (It is hard for me to setup contrib 
modules in my ide because it doesn't like the fact that they are 
subfolders of trunk with independent build files so I have not tested 
the other contribs). Change Query.combine() to this:

/** Expert: called when re-writing queries under MultiSearcher.
*
* Only implemented by derived queries, with no
* [EMAIL PROTECTED] #createWeight(Searcher)} implementatation.
*/
public Query combine(Query[] queries) {
for (int i = 0; i < queries.length; i++) {
if (!this.equals(queries[i])) {
BooleanQuery result = new BooleanQuery(true);
for (int j = 0; j < queries.length; j++)
result.add(queries[j], BooleanClause.Occur.SHOULD);
return result;
}
}
return this;
}
Analysis: the root problem is that the current Query.combine(), which is 
only used by MultiSearcher, requires that all queries rewrite to either 
a) the same thing, or b) a combinable container type such as 
BooleanQuery. This is incompatible with the single-clause optimization 
that occurs in BooleanQuery.rewrite(). The fix is to have 
Query.combine() combine distinct queries into an OR rather to reject 
them. This is a reversal of the earlier optimizations in the rewrites 
that is required to make sure the same query is distributed to each 
sub-searcher -- this is exaclty what BooleanQuery.combine() and the 
other custom combine() methods do. I would have liked to call rewrite() 
on the result of the above inner loop, but unfortunately there is no 
longer a pointer to the reader available. This deficiency could be 
changed by modifying the API and updating all of the overriding methods 
in the container types. There may be a better fix than the above, but I 
think this is correct and it passes all the tests.

Doug and Wolf should review this.
Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: HighlighterTest failure

2005-04-25 Thread Erik Hatcher
On Apr 25, 2005, at 10:02 PM, Chuck Williams wrote:
Erik Hatcher wrote:
I get a failure running HighlighterTest from the Subversion trunk. 
Below are the details.

What's the fix?
I don't have the code here to run, but the problem is that 
MultiSearcher.rewrite(line 298) is calling Query.combine, which 
requires all the combined queries to be equal. Obviously they will not 
be equal in general for multi-term queries (PrefixQuery's in this 
case) since those queries expand into different terms for the 
different searchers. Just above the failing line in 
MultiSearcher.rewrite() it rewrites the query it was passed from the 
parser in the HighlighterTest. This should be a PrefixQuery, which 
should rewrite into two BooleanQuery's, which should then lead to 
BooleanQuery.combine() and not Query.combine(). So it appears that 
either the query parser did not produce a PrefixQuery, or you don't 
have the current code?

Could you step through it and find out what kind of query is passes to 
MultiSearcher.rewrite() and what comes back from the 2 rewrite() calls 
made there for the two searchers?
PrefixQuery being passed to MultiSearcher.rewrite()... and the 2 
rewrites each rewrite to the expanded Query (an optimized TermQuery in 
this case).

I've got the current trunk code.
*shrugs*
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: SortTest failing

2005-04-25 Thread Erik Hatcher
On Apr 25, 2005, at 10:55 PM, Otis Gospodnetic wrote:
Hm, Erik is not alone with unit tests failing.  My HighlighterTest
passes (I didn't do svn update today yet)
Let me know what happens after you fully update and build the main 
Lucene JAR, then run the highlighter build.

, but I see SortTest failing:
[junit] Testcase:
testNormalizedScores(org.apache.lucene.search.TestSort):  FAILED
Line 365 is this:
assertSameValues (scoresA, getScores(multi.search(queryA,sort)));
And this makes me think that this broke during my last commit of Wolf's
patch for MultiSearcher and docFreq stuff.  However I did run 'ant
test' before commit and did see BUILD SUCCESSFUL, so I'm not 100% sure.
Anyone else seeing this error?
Yes, I see this same error.
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: svn commit: r164695 - in /lucene/java/trunk: CHANGES.txt src/java/org/apache/lucene/search/Hit.java src/java/org/apache/lucene/search/HitIterator.java src/java/org/apache/lucene/search/Hits.java s

2005-04-25 Thread Erik Hatcher
On Apr 25, 2005, at 10:36 PM, Otis Gospodnetic wrote:
Would it be better to explicitly check for out of bounds hitNumber
instead of catching ArrayIndexOutOfBoundsException?
if (hitNumber > hits.length()) {
  throw new NoSuchElementException();
}
Good eye.  I've added a test case that identified this issue since the  
out of bound exception could never have occurred and then fixed the  
issue.

Also, is "a future for a hit" a typo, or does that actually mean
something?  This makes me think of Python's "future", but I'm not sure
what this means in this context.
I've cleared this up.
Thanks,
Erik

Thanks,
Otis

--- [EMAIL PROTECTED] wrote:
Author: ehatcher
Date: Mon Apr 25 17:21:53 2005
New Revision: 164695
URL: http://svn.apache.org/viewcvs?rev=164695&view=rev
Log:
Add Hits.iterator and corresponding HitIterator and Hit classes.
Contributed by Jeremy Rayner
Added:
lucene/java/trunk/src/java/org/apache/lucene/search/Hit.java
lucene/java/trunk/src/java/org/apache/lucene/search/HitIterator.java
lucene/java/trunk/src/test/org/apache/lucene/TestHitIterator.java
Modified:
lucene/java/trunk/CHANGES.txt
lucene/java/trunk/src/java/org/apache/lucene/search/Hits.java
Modified: lucene/java/trunk/CHANGES.txt
URL:
http://svn.apache.org/viewcvs/lucene/java/trunk/CHANGES.txt? 
rev=164695&r1=164694&r2=164695&view=diff

=== 
===
--- lucene/java/trunk/CHANGES.txt (original)
+++ lucene/java/trunk/CHANGES.txt Mon Apr 25 17:21:53 2005
@@ -91,6 +91,11 @@
 which lets the caller get the Lucene version information
specified in
 the Lucene Jar.
 (Doug Cutting via Otis)
+
+15. Added Hits.iterator() method and corresponding HitIterator and
Hit objects.
+This provides standard java.util.Iterator iteration over Hits.
+Each call to the iterator's next() method returns a Hit object.
+(Jeremy Rayner via Erik)
 API Changes
Added: lucene/java/trunk/src/java/org/apache/lucene/search/Hit.java
URL:
http://svn.apache.org/viewcvs/lucene/java/trunk/src/java/org/apache/ 
lucene/search/Hit.java?rev=164695&view=auto

=== 
===
--- lucene/java/trunk/src/java/org/apache/lucene/search/Hit.java
(added)
+++ lucene/java/trunk/src/java/org/apache/lucene/search/Hit.java Mon
Apr 25 17:21:53 2005
@@ -0,0 +1,125 @@
+/**
+ * Copyright 2005 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions
and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.search;
+
+import java.io.IOException;
+
+import org.apache.lucene.document.Document;
+
+/**
+ * a lazy future for a hit, useful for iterators over instances of
Hits
+ *
+ * @author Jeremy Rayner
+ */
+public class Hit implements java.io.Serializable {
+
+  private float score;
+  private int id;
+  private Document doc = null;
+
+  private boolean resolved = false;
+
+  private Hits hits = null;
+  private int hitNumber;
+
+  /**
+   * Constructed from [EMAIL PROTECTED] HitIterator}
+   * @param hits Hits returned from a search
+   * @param hitNumber Hit index in Hits
+   */
+  Hit(Hits hits, int hitNumber) {
+this.hits = hits;
+this.hitNumber = hitNumber;
+  }
+
+  /**
+   * Returns document for this hit.
+   *
+   * @see [EMAIL PROTECTED] Hits#doc(int)}
+   */
+  public Document getDocument() throws IOException {
+if (!resolved) fetchTheHit();
+return doc;
+  }
+
+  /**
+   * Returns score for this hit.
+   *
+   * @see [EMAIL PROTECTED] Hits#score(int)}
+   */
+  public float getScore() throws IOException {
+if (!resolved) fetchTheHit();
+return score;
+  }
+
+  /**
+   * Returns id for this hit.
+   *
+   * @see [EMAIL PROTECTED] Hits#id(int)}
+   */
+  public int getId() throws IOException {
+if (!resolved) fetchTheHit();
+return id;
+  }
+
+  private void fetchTheHit() throws IOException {
+doc = hits.doc(hitNumber);
+score = hits.score(hitNumber);
+id = hits.id(hitNumber);
+resolved = true;
+  }
+
+  // provide some of the Document style interface (the simple stuff)
+
+  /**
+   * Returns the boost factor for this hit on any field of the
underlying document.
+   *
+   * @see [EMAIL PROTECTED] Document#getBoost()}
+   */
+  public float getBoost() throws IOException {
+return getDocument().getBoost();
+  }
+
+  /**
+   * Returns the string value of the field with the given name if
any exist in
+   * this document, or null.  If multiple fields exist with this
na

Re: SortTest failing

2005-04-25 Thread Chuck Williams
Otis Gospodnetic wrote:
Hm, Erik is not alone with unit tests failing.  My HighlighterTest
passes (I didn't do svn update today yet), but I see SortTest failing:
   [junit] Testcase:
testNormalizedScores(org.apache.lucene.search.TestSort):  FAILED
   [junit] expected:<0.375> but was:<0.392445>
   [junit] junit.framework.AssertionFailedError: expected:<0.375> but
was:<0.392445>
   [junit] at
org.apache.lucene.search.TestSort.assertSameValues(TestSort.java:560)
   [junit] at
org.apache.lucene.search.TestSort.testNormalizedScores(TestSort.java:365)
Line 365 is this:
assertSameValues (scoresA, getScores(multi.search(queryA,sort)));
And this makes me think that this broke during my last commit of Wolf's
patch for MultiSearcher and docFreq stuff.  However I did run 'ant
test' before commit and did see BUILD SUCCESSFUL, so I'm not 100% sure.
Anyone else seeing this error?
 

Otis, I think that is a bug in the test case that Wolf's patch has 
exposed. It creates an index consisting of two copies of "full". This 
should be equivalent to an index where every document is duplicated 
(occurs twice), not to an index where each document occurs only once. 
With the new correct idf normalizaiton, this increases all the docfreq's 
for the terms, which changes the score. Scores on the duplicated index 
should not be the same as scores on the unduplicated index.

Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


SortTest failing

2005-04-25 Thread Otis Gospodnetic
Hm, Erik is not alone with unit tests failing.  My HighlighterTest
passes (I didn't do svn update today yet), but I see SortTest failing:

[junit] Testcase:
testNormalizedScores(org.apache.lucene.search.TestSort):  FAILED
[junit] expected:<0.375> but was:<0.392445>
[junit] junit.framework.AssertionFailedError: expected:<0.375> but
was:<0.392445>
[junit] at
org.apache.lucene.search.TestSort.assertSameValues(TestSort.java:560)
[junit] at
org.apache.lucene.search.TestSort.testNormalizedScores(TestSort.java:365)


Line 365 is this:

assertSameValues (scoresA, getScores(multi.search(queryA,sort)));


And this makes me think that this broke during my last commit of Wolf's
patch for MultiSearcher and docFreq stuff.  However I did run 'ant
test' before commit and did see BUILD SUCCESSFUL, so I'm not 100% sure.
 

Anyone else seeing this error?

Otis


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: svn commit: r164695 - in /lucene/java/trunk: CHANGES.txt src/java/org/apache/lucene/search/Hit.java src/java/org/apache/lucene/search/HitIterator.java src/java/org/apache/lucene/search/Hits.java s

2005-04-25 Thread Otis Gospodnetic
Hello,

Would it be better to explicitly check for out of bounds hitNumber
instead of catching ArrayIndexOutOfBoundsException?

if (hitNumber > hits.length()) {
  throw new NoSuchElementException();
}

Also, is "a future for a hit" a typo, or does that actually mean
something?  This makes me think of Python's "future", but I'm not sure
what this means in this context.

Thanks,
Otis



--- [EMAIL PROTECTED] wrote:

> Author: ehatcher
> Date: Mon Apr 25 17:21:53 2005
> New Revision: 164695
> 
> URL: http://svn.apache.org/viewcvs?rev=164695&view=rev
> Log:
> Add Hits.iterator and corresponding HitIterator and Hit classes. 
> Contributed by Jeremy Rayner
> 
> Added:
> lucene/java/trunk/src/java/org/apache/lucene/search/Hit.java
>
> lucene/java/trunk/src/java/org/apache/lucene/search/HitIterator.java
> lucene/java/trunk/src/test/org/apache/lucene/TestHitIterator.java
> Modified:
> lucene/java/trunk/CHANGES.txt
> lucene/java/trunk/src/java/org/apache/lucene/search/Hits.java
> 
> Modified: lucene/java/trunk/CHANGES.txt
> URL:
>
http://svn.apache.org/viewcvs/lucene/java/trunk/CHANGES.txt?rev=164695&r1=164694&r2=164695&view=diff
>
==
> --- lucene/java/trunk/CHANGES.txt (original)
> +++ lucene/java/trunk/CHANGES.txt Mon Apr 25 17:21:53 2005
> @@ -91,6 +91,11 @@
>  which lets the caller get the Lucene version information
> specified in
>  the Lucene Jar.
>  (Doug Cutting via Otis)
> +
> +15. Added Hits.iterator() method and corresponding HitIterator and
> Hit objects.
> +This provides standard java.util.Iterator iteration over Hits.
> +Each call to the iterator's next() method returns a Hit object.
> +(Jeremy Rayner via Erik)
>  
>  API Changes
>  
> 
> Added: lucene/java/trunk/src/java/org/apache/lucene/search/Hit.java
> URL:
>
http://svn.apache.org/viewcvs/lucene/java/trunk/src/java/org/apache/lucene/search/Hit.java?rev=164695&view=auto
>
==
> --- lucene/java/trunk/src/java/org/apache/lucene/search/Hit.java
> (added)
> +++ lucene/java/trunk/src/java/org/apache/lucene/search/Hit.java Mon
> Apr 25 17:21:53 2005
> @@ -0,0 +1,125 @@
> +/**
> + * Copyright 2005 The Apache Software Foundation
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> + * See the License for the specific language governing permissions
> and
> + * limitations under the License.
> + */
> +
> +package org.apache.lucene.search;
> +
> +import java.io.IOException;
> +
> +import org.apache.lucene.document.Document;
> +
> +/**
> + * a lazy future for a hit, useful for iterators over instances of
> Hits
> + *
> + * @author Jeremy Rayner
> + */
> +public class Hit implements java.io.Serializable {
> +
> +  private float score;
> +  private int id;
> +  private Document doc = null;
> +
> +  private boolean resolved = false;
> +
> +  private Hits hits = null;
> +  private int hitNumber;
> +
> +  /**
> +   * Constructed from [EMAIL PROTECTED] HitIterator}
> +   * @param hits Hits returned from a search
> +   * @param hitNumber Hit index in Hits
> +   */
> +  Hit(Hits hits, int hitNumber) {
> +this.hits = hits;
> +this.hitNumber = hitNumber;
> +  }
> +
> +  /**
> +   * Returns document for this hit.
> +   *
> +   * @see [EMAIL PROTECTED] Hits#doc(int)}
> +   */
> +  public Document getDocument() throws IOException {
> +if (!resolved) fetchTheHit();
> +return doc;
> +  }
> +
> +  /**
> +   * Returns score for this hit.
> +   *
> +   * @see [EMAIL PROTECTED] Hits#score(int)}
> +   */
> +  public float getScore() throws IOException {
> +if (!resolved) fetchTheHit();
> +return score;
> +  }
> +
> +  /**
> +   * Returns id for this hit.
> +   *
> +   * @see [EMAIL PROTECTED] Hits#id(int)}
> +   */
> +  public int getId() throws IOException {
> +if (!resolved) fetchTheHit();
> +return id;
> +  }
> +
> +  private void fetchTheHit() throws IOException {
> +doc = hits.doc(hitNumber);
> +score = hits.score(hitNumber);
> +id = hits.id(hitNumber);
> +resolved = true;
> +  }
> +
> +  // provide some of the Document style interface (the simple stuff)
> +
> +  /**
> +   * Returns the boost factor for this hit on any field of the
> underlying document.
> +   *
> +   * @see [EMAIL PROTECTED] Document#getBoost()}
> +   */
> +  public float getBoost() throws IOException {
> +return getDocument().getBoost();
> +  }
> +
> +  /**
> +   * Returns the string value of the field with the given name if
> any e

Re: HighlighterTest failure

2005-04-25 Thread Chuck Williams
Erik Hatcher wrote:
I get a failure running HighlighterTest from the Subversion trunk. 
Below are the details.

What's the fix?
I don't have the code here to run, but the problem is that 
MultiSearcher.rewrite(line 298) is calling Query.combine, which requires 
all the combined queries to be equal. Obviously they will not be equal 
in general for multi-term queries (PrefixQuery's in this case) since 
those queries expand into different terms for the different searchers. 
Just above the failing line in MultiSearcher.rewrite() it rewrites the 
query it was passed from the parser in the HighlighterTest. This should 
be a PrefixQuery, which should rewrite into two BooleanQuery's, which 
should then lead to BooleanQuery.combine() and not Query.combine(). So 
it appears that either the query parser did not produce a PrefixQuery, 
or you don't have the current code?

Could you step through it and find out what kind of query is passes to 
MultiSearcher.rewrite() and what comes back from the 2 rewrite() calls 
made there for the two searchers?

Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 34585] - Contributing a High-performance single-document main memory Apache Lucene fulltext search index.

2005-04-25 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34585


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|lucene- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |m
 Status|ASSIGNED|NEW




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 34585] - Contributing a High-performance single-document main memory Apache Lucene fulltext search index.

2005-04-25 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34585


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 34585] - Contributing a High-performance single-document main memory Apache Lucene fulltext search index.

2005-04-25 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34585


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #14799|0   |1
is obsolete||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



HighlighterTest failure

2005-04-25 Thread Erik Hatcher
I get a failure running HighlighterTest from the Subversion trunk.   
Below are the details.

What's the fix?
Thanks,
Erik
[junit] Searching for: multi*
[junit] -  ---
[junit] Testcase:  
testMultiSearcher(org.apache.lucene.search.highlight.HighlighterTest):   
  Caused an ERROR
[junit] null
[junit] java.lang.IllegalArgumentException
[junit] at  
org.apache.lucene.search.Query.combine(Query.java:113)
[junit] at  
org.apache.lucene.search.MultiSearcher.rewrite(MultiSearcher.java:298)
[junit] at org.apache.lucene.search.Query.weight(Query.java:92)
[junit] at org.apache.lucene.search.Hits.(Hits.java:40)
[junit] at  
org.apache.lucene.search.Searcher.search(Searcher.java:40)
[junit] at  
org.apache.lucene.search.Searcher.search(Searcher.java:32)
[junit] at  
org.apache.lucene.search.highlight.HighlighterTest.testMultiSearcher(Hig 
hlighterTest.java:436)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native  
Method)
[junit] at  
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav 
a:39)
[junit] at  
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor 
Impl.java:25)

[junit] Test org.apache.lucene.search.highlight.HighlighterTest  
FAILED

Which comes from this code in HighlighterTest:
		IndexSearcher searchers[]=new IndexSearcher[2];
		searchers[0] = new IndexSearcher(ramDir1);
		searchers[1] = new IndexSearcher(ramDir2);
		MultiSearcher multiSearcher=new MultiSearcher(searchers);
		query = QueryParser.parse("multi*", FIELD_NAME, new  
StandardAnalyzer());
		System.out.println("Searching for: " + query.toString(FIELD_NAME));
		//at this point the multisearcher calls combine(query[])
		hits = multiSearcher.search(query);

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 34570] - A new Greek Analyzer for Lucene

2005-04-25 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34570


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-04-26 02:55 ---
Added.  Thanks for the contribution and the additional test case.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Lucene and Groovy...

2005-04-25 Thread Erik Hatcher
On Apr 25, 2005, at 2:56 PM, Doug Cutting wrote:
Erik Hatcher wrote:
There are two .java files attached that may not make it through to 
the list.  These are simple wrappers that do exactly what you'd 
expect.  The idea is to make dealing with Lucene Hits more "Java 
like" with an Iterator, which in turn makes this much more amenable 
to Groovy.
+1, but it needs more and better javadoc and unit tests.  Every public 
method should have a javadoc commment.  Also, there should be some 
cautions about blithely iterating through all hits.
Thanks for allowing this.  I've added javadoc comments to all public 
methods, made the constructors of HitIterator and Hit package scoped, 
added a unit test, and also added a warning about iterating over all 
hits.  If there is anything else that is needed to finish this off, let 
me know.

Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 31841] - [PATCH] MultiSearcher problems with Similarity.docFreq()

2005-04-25 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31841





--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 22:06 ---
I am now confused by the changes in Searcher.java.  Why is sometimes
query.weight(Searcher) called and other times query.createWeight()?  The latter
is meant only to only construct a Weight, and the former to construct and
initialize it.  Shouldn't it always be initialized?

Also, it was difficult to apply your patch.  It uses CRLF instead of LF, which
confuses patch on Linux.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Fwd: Lucene and Groovy...

2005-04-25 Thread Doug Cutting
Erik Hatcher wrote:
There are two .java files attached that may not make it through to the 
list.  These are simple wrappers that do exactly what you'd expect.  The 
idea is to make dealing with Lucene Hits more "Java like" with an 
Iterator, which in turn makes this much more amenable to Groovy.
+1, but it needs more and better javadoc and unit tests.  Every public 
method should have a javadoc commment.  Also, there should be some 
cautions about blithely iterating through all hits.

Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 34570] - A new Greek Analyzer for Lucene

2005-04-25 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34570


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #14803|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 20:30 ---
Created an attachment (id=14834)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14834&action=view)
Updated the test case to use Unicode escape sequences

Updated the test case to use Unicode escape sequences. This way it should be
immune to different locale settings.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]