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

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_bu

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

On 4/26/05, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: > 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. My feeling originally was that as the obtaining of the document wa

Re: SortTest failing

Chuck Williams wrote: Otis Gospodnetic wrote: 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

Re: UnscoredRangeQuery

> ConstantScoreQuery would seem better, with the addition of the constant > score value as a constructor argument. OK, I changed the names to ConstantScoreQuery and ConstantScoreRangeQuery. Should I add a constantScore field to the class, or just rely on the boost (and have the user call setBoos

DO NOT REPLY [Bug 34629] New: - Play with term postings or .. to a easy way to update

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_bu

DO NOT REPLY [Bug 34629] - Play with term postings or .. to a easy way to update

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_bu

DO NOT REPLY [Bug 34629] - [PATHC] Play with term postings or .. to a easy way to update

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_bu

a new way to update without delete+add

Hy, i made a contribution in the bugzilla allowing to play with the posting lists: add, delete , replace relation term/document One of the pb in Lucene is the updating of document. With this patch, you can update documents very quickly. (see test case) http://issues.apache.org/bugzilla/show_

DO NOT REPLY [Bug 34629] - [PATCH] Play with term postings or .. to a easy way to update

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_bu

Re: a new way to update without delete+add

On Apr 26, 2005, at 1:38 PM, Nicolas Maisonneuve wrote: One of the pb in Lucene is the updating of document. With this patch, you can update documents very quickly. (see test case) http://issues.apache.org/bugzilla/show_bug.cgi?id=34563 This is not the link you meant. Here's the one you just s

Re: broken compilation

On Friday 22 April 2005 05:29, Erik Hatcher wrote: > I don't normally run this target, but one of our deprecated tests has a > Â compilation issue. ÂI haven't researched when this broke, but could > someone fix this please? I fixed it. TermInfosTest is, however, not a real JUnit test case, so I

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

On Tuesday 26 April 2005 02:21, [EMAIL PROTECTED] wrote: > + Âpublic String toString() { > + Â Âtry { > + Â Â Âreturn getDocument().toString(); > + Â Â} catch (IOException e) { > + Â Â Âreturn null; > + Â Â} > + Â} Wouldn't it be better here to re-throw the exception as a RuntimeException? Regar

Re: broken compilation

On Apr 26, 2005, at 2:02 PM, Daniel Naber wrote: On Friday 22 April 2005 05:29, Erik Hatcher wrote: I don't normally run this target, but one of our deprecated tests has a   compilation issue.  I haven't researched when this broke, but could someone fix this please? I fixed it. TermInfosTest is, h

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

On Apr 26, 2005, at 2:38 PM, Daniel Naber wrote: On Tuesday 26 April 2005 02:21, [EMAIL PROTECTED] wrote: +  public String toString() { +    try { +      return getDocument().toString(); +    } catch (IOException e) { +      return null; +    } +  } Wouldn't it be better here to re-throw the except

Re: broken compilation

Erik Hatcher wrote: I fixed it. TermInfosTest is, however, not a real JUnit test case, so I wonder how useful it is at all... I'm curious - did your fix change the code to go against a new API? Yes, but not a public API. In other words, is there something that has changed that breaks API compati

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

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_bu

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

On Tuesday 26 April 2005 21:09, Erik Hatcher wrote: > I don't know would it? ÂI have no preference, though it seems ok to > me to simply return null since this is the toString method. ÂFor a > Document, the toString is only useful for debugging anyway. Yes, and during debugging it would be es

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

Erik Hatcher wrote: On Apr 26, 2005, at 2:38 PM, Daniel Naber wrote: On Tuesday 26 April 2005 02:21, [EMAIL PROTECTED] wrote: + public String toString() { +try { + return getDocument().toString(); +} catch (IOException e) { + return null; +} + } Wouldn't it be better here t

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

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_bu

Correct of Query.combine() bugs with new MultiSearcher

As noted in the patch description I just submitted, it should be a complete, correct, robust (relative to possible user Query implementations) and reasonably optimal solution for Query.combine(). It also simplifies the previous methods, deleting all overrides of Query.combine() and Query.merge

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

On 4/26/05, Daniel Naber <[EMAIL PROTECTED]> wrote: > On Tuesday 26 April 2005 21:09, Erik Hatcher wrote: > > > I don't know would it? I have no preference, though it seems ok to > > me to simply return null since this is the toString method. For a > > Document, the toString is only useful for

DO NOT REPLY [Bug 34359] - Cannot use Lucene in an unsigned applet due to Java security restrictions

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_bu

too many classes visible with "ant javadocs"

Hi, the java API documentation now seems to contain classes which have no useful documentation and thus probably shouldn't be part of the API docs, e.g. Among, Testapp, SnowballProgram (maybe more). Also, build.xml has a typo: "MorLikeThis" (Mor instead of More), but I don't know whether this

Re: too many classes visible with "ant javadocs"

On Apr 26, 2005, at 6:10 PM, Daniel Naber wrote: Hi, the java API documentation now seems to contain classes which have no useful documentation and thus probably shouldn't be part of the API docs, e.g. Among, Testapp, SnowballProgram (maybe more). Also, build.xml has a typo: "MorLikeThis" (Mor in

Re: too many classes visible with "ant javadocs"

On Apr 26, 2005, at 6:10 PM, Daniel Naber wrote: the java API documentation now seems to contain classes which have no useful documentation and thus probably shouldn't be part of the API docs, e.g. Among, Testapp, SnowballProgram (maybe more). This is now fixed. I excluded net.sf.* from being jav

Re: [Performance] Streaming main memory indexing of single strings

I've uploaded slightly improved versions of the fast MemoryIndex contribution to http://issues.apache.org/bugzilla/show_bug.cgi?id=34585 along with another contrib - PatternAnalyzer. For a quick overview without downloading code, there's javadoc for it all at http://dsd.lbl.gov/nux/api/o

Re: [Performance] Streaming main memory indexing of single strings

Wolfgang, You have provided a superb set of patches! I'm in awe of the extensive documentation you've done. There is nothing further you need to do, but be patient while we incorporate it into the contrib area somewhere. Your PatternAnalyzer could fit into the contrib/analyzers area nicely

Re: Correct of Query.combine() bugs with new MultiSearcher

I've confirmed Chuck's patch does fix the Highlighter test. I'm set to commit it once it gets the thumbs-up from Doug. Erik On Apr 26, 2005, at 4:58 PM, Chuck Williams wrote: As noted in the patch description I just submitted, it should be a complete, correct, robust (relative to possib

Re: Correct of Query.combine() bugs with new MultiSearcher

Thanks Erik. If you don't here more, I'm sure this fixes a whole class of problems and is better than the previous situation. I'm also confident that it will do the right thing for all the query types built into Lucene. My remaining uncertainty concerns whether user query types might somehow

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

Thanks for the Future pointers. I actually used it, but didn't know it by name. Otis --- Jeremy Rayner <[EMAIL PROTECTED]> wrote: > On 4/26/05, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: > > Also, is "a future for a hit" a typo, or does that actually mean > > something? This makes me think of