cvs commit: jakarta-lucene-sandbox/contributions/highlighter/src/java/org/apache/lucene/search/highlight QueryTermExtractor.java

ehatcher2004/04/20 18:12:04 Modified:contributions/highlighter/src/java/org/apache/lucene/search/highlight QueryTermExtractor.java Log: javadoc fixups Revision ChangesPath 1.2 +2 -4 jakarta-lucene-sandbox/contributions/highlighter/src/j

cvs commit: jakarta-lucene-sandbox/contributions/highlighter/src/test/org/apache/lucene/search/highlight HighlighterTest.java

ehatcher2004/04/20 18:06:05 Added: contributions/highlighter/src/test/org/apache/lucene/search/highlight HighlighterTest.java Removed: contributions/highlighter/src/java/org/apache/lucene/search/highlight HighlighterTest.java Log:

cvs commit: jakarta-lucene-sandbox/contributions/highlighter/src/test/org/apache/lucene/search/highlight - New directory

ehatcher2004/04/20 18:03:35 jakarta-lucene-sandbox/contributions/highlighter/src/test/org/apache/lucene/search/highlight - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL

cvs commit: jakarta-lucene-sandbox/contributions/highlighter/src/test/org/apache/lucene/search - New directory

ehatcher2004/04/20 18:03:17 jakarta-lucene-sandbox/contributions/highlighter/src/test/org/apache/lucene/search - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-lucene-sandbox/contributions/highlighter/src/test/org/apache/lucene - New directory

ehatcher2004/04/20 18:02:54 jakarta-lucene-sandbox/contributions/highlighter/src/test/org/apache/lucene - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-lucene-sandbox/contributions/highlighter/src/test/org/apache - New directory

ehatcher2004/04/20 18:02:34 jakarta-lucene-sandbox/contributions/highlighter/src/test/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-lucene-sandbox/contributions/highlighter/src/test/org - New directory

ehatcher2004/04/20 18:02:19 jakarta-lucene-sandbox/contributions/highlighter/src/test/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-lucene-sandbox/contributions/highlighter/src/test - New directory

ehatcher2004/04/20 18:01:59 jakarta-lucene-sandbox/contributions/highlighter/src/test - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta Lucene Wiki] Updated: PoweredBy

Date: 2004-04-20T13:23:45 Editor: 217.229.11.172 <> Wiki: Jakarta Lucene Wiki Page: PoweredBy URL: http://wiki.apache.org/jakarta-lucene/PoweredBy no comment Change Log: -- @@ -32,3 +32,4 @@ * [http:/

DO NOT REPLY [Bug 28339] - addIndexes unexpectedly closes index

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

cvs commit: jakarta-lucene/src/test/org/apache/lucene/index TestSegmentMerger.java TestDoc.java DocTest.java

goller 2004/04/20 12:33:35 Modified:src/java/org/apache/lucene/index SegmentMerger.java IndexWriter.java src/test/org/apache/lucene/index TestSegmentMerger.java TestDoc.java DocTest.java Log: Directory in now only closed

Re: cvs commit: jakarta-lucene/src/java/org/apache/lucene/index MultiReader.java FilterIndexReader.java IndexReader.java SegmentReader.java

> Hi again, > > I committed some changes to skipTo and it is now at least in such a state > that I do not know (from code inspection) of any further bugs in it. > > However, it is not tested and I do not have good test cases. It would really > be great if you could test this latest version on you

Re: incorrect OO in lucene source?

Todd VanderVeen wrote: Doug Cutting wrote: Grant Ingersoll wrote: The thread safety issues are on the search side usage of Analyzer, not indexing. Primarily search, but not exclusively. IndexWriter is thread safe. One can add documents to a single IndexWriter instance from multiple thread

Re: incorrect OO in lucene source?

Doug Cutting wrote: Grant Ingersoll wrote: The thread safety issues are on the search side usage of Analyzer, not indexing. Primarily search, but not exclusively. IndexWriter is thread safe. One can add documents to a single IndexWriter instance from multiple threads. Tokenization will be

cvs commit: jakarta-lucene/src/java/org/apache/lucene/store RAMDirectory.java

goller 2004/04/20 11:27:55 Modified:src/java/org/apache/lucene/store RAMDirectory.java Log: temporary directory in constructor was never closed Revision ChangesPath 1.14 +9 -3 jakarta-lucene/src/java/org/apache/lucene/store/RAMDirectory.java Index: RAMDir

cvs commit: jakarta-lucene/src/java/org/apache/lucene/index IndexReader.java

goller 2004/04/20 11:21:06 Modified:src/java/org/apache/lucene/index IndexReader.java Log: temporary directory in isLocked(String) was never closed Revision ChangesPath 1.31 +5 -2 jakarta-lucene/src/java/org/apache/lucene/index/IndexReader.java Index: Inde

Re: incorrect OO in lucene source?

Robert Engels wrote: Please don't take my questions as criticism... I asked them "because" Lucene is held up as an example of good OO design, and I was trying to reconcile my knowledge of OO design with the Lucene developers. Please don't take my response as overly-sensitive. Rather I was trying

Re: cvs commit: jakarta-lucene/src/java/org/apache/lucene/document Document.java

Otis Gospodnetic wrote: I can see people asking if they can use these methods to update Documents that have already been indexed, so I think it would be good if you could add notes to both remove methods and emphasize that they are useful only for Documents that have not yet been indexed. Otis done

Re: incorrect OO in lucene source?

Doug Cutting wrote: Robert Engels wrote: Lucene is often cited as an excellent example of OO design. That is kind, but the primary goal of Lucene is to provide functionality, not to use "correct" OO design. The two are not always in accord. Hear, hear! Shouldn't 'Filter' just be an interfa

cvs commit: jakarta-lucene/src/java/org/apache/lucene/document Document.java

goller 2004/04/20 10:55:16 Modified:src/java/org/apache/lucene/document Document.java Log: improved javadoc Revision ChangesPath 1.18 +23 -6 jakarta-lucene/src/java/org/apache/lucene/document/Document.java Index: Document.java

Re: cvs commit: jakarta-lucene/src/java/org/apache/lucene/document Document.java

I can see people asking if they can use these methods to update Documents that have already been indexed, so I think it would be good if you could add notes to both remove methods and emphasize that they are useful only for Documents that have not yet been indexed. Otis --- [EMAIL PROTECTED] wro

DO NOT REPLY [Bug 28462] - [PATCH] new method: Document.remove()

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

cvs commit: jakarta-lucene/src/java/org/apache/lucene/document Document.java

goller 2004/04/20 10:26:16 Modified:src/test/org/apache/lucene/document TestDocument.java src/java/org/apache/lucene/document Document.java Log: removeField and removeFields added to Document enhancement was proposed in bug 28462 Revision ChangesPath 1.4

RE: incorrect OO in lucene source?

Please don't take my questions as criticism... I asked them "because" Lucene is held up as an example of good OO design, and I was trying to reconcile my knowledge of OO design with the Lucene developers. It just "feels like" IndexReader and IndexWriter should be interfaces... My Lucene IndexReade

Re: incorrect OO in lucene source?

Robert Engels wrote: Lucene is often cited as an excellent example of OO design. That is kind, but the primary goal of Lucene is to provide functionality, not to use "correct" OO design. The two are not always in accord. It seems the abstract base classes were created so there was a place to pu

DO NOT REPLY [Bug 27423] - [PATCH] Demo HTML parser does not properly handle meta tag attributes.

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

cvs commit: jakarta-lucene/src/demo/org/apache/lucene/demo/html HTMLParser.java HTMLParser.jj

goller 2004/04/20 09:27:24 Modified:src/demo/org/apache/lucene/demo/html HTMLParser.java HTMLParser.jj Log: fix for bug 27423 slightly modified version of Daniel?s patch Revision ChangesPath 1.5 +22 -13 jakarta-lucene/src/demo/org/apac

Re: two api ideas

Both changes sound reasonable to me. Tim Jones wrote: What do you guys think of these two ideas - would they be good additions to the API (or maybe the sandbox)? 1. New type of SortField, allowing custom comparison function: public SortField (String field, // which field to sort

Re: incorrect OO in lucene source?

Grant Ingersoll wrote: The thread safety issues are on the search side usage of Analyzer, not indexing. Primarily search, but not exclusively. IndexWriter is thread safe. One can add documents to a single IndexWriter instance from multiple threads. Tokenization will be done in parallel. Doug

Re: incorrect OO in lucene source?

+1 most emphatically! - Original Message - From: "Erik Hatcher" <[EMAIL PROTECTED]> To: "Lucene Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, April 20, 2004 10:35 AM Subject: Re: incorrect OO in lucene source? > My vote is to get 1.4 fully released (there are some *dramatic* new

Re: incorrect OO in lucene source?

The thread safety issues are on the search side usage of Analyzer, not indexing. >>> [EMAIL PROTECTED] 04/20/04 10:52AM >>> Grant Ingersoll wrote: >I agree with Robert, as I have had similar wishes about more interface capabilities, >but also agree with Eric in that Lucene works great in a lot o

Re: incorrect OO in lucene source?

Erik Hatcher wrote: My vote is to get 1.4 fully released (there are some *dramatic* new features) and then we can really kick in the discussions for API/interface overhauls and how we want to deal with backwards compatibility issues as well. Does anyone feel strongly enough about API changes

Re: incorrect OO in lucene source?

Grant Ingersoll wrote: I agree with Robert, as I have had similar wishes about more interface capabilities, but also agree with Eric in that Lucene works great in a lot of ways.I have found the current design causes you to have to hard code things that shouldn't need to be hard coded, especial

Re: incorrect OO in lucene source?

It's sort of redundant since the CHANGES.txt file in Lucene's CVS notes what is new. But the highlights are sorting, spans, and term vectors. Erik On Apr 20, 2004, at 10:41 AM, Goulish, Michael wrote: Erik -- I hope this isn't redundant -- What are the most important new features coming out

RE: incorrect OO in lucene source?

Erik -- I hope this isn't redundant -- What are the most important new features coming out in 1.4, in your opinion? Your favorites. I introduced Lucene to my company -- we're having a good time with it, and I'd like to give a sort of top-5 good-parts-overview of what's coming. --

Re: incorrect OO in lucene source?

My vote is to get 1.4 fully released (there are some *dramatic* new features) and then we can really kick in the discussions for API/interface overhauls and how we want to deal with backwards compatibility issues as well. Does anyone feel strongly enough about API changes to be made for 1.4?

two api ideas

What do you guys think of these two ideas - would they be good additions to the API (or maybe the sandbox)? 1. New type of SortField, allowing custom comparison function: public SortField (String field, // which field to sort SortComparatorFactory comparator, // how

Re: incorrect OO in lucene source?

I agree with Robert, as I have had similar wishes about more interface capabilities, but also agree with Eric in that Lucene works great in a lot of ways.I have found the current design causes you to have to hard code things that shouldn't need to be hard coded, especially in the TokenStream

Re: incorrect OO in lucene source?

Erik Hatcher wrote: Robert, I agree with your sentiment about interfaces. I haven't looked into the specifics of what you mention about IndexReader though. Out of curiosity - is there something about Lucene's design that is preventing you from extending Lucene? Pragmatically speaking, we sh

Re: cvs commit: jakarta-lucene/src/java/org/apache/lucene/index MultiReader.java FilterIndexReader.java IndexReader.java SegmentReader.java

Incze Lajos wrote: Hi Incze, looks like the bug in PhraseScorer that I fixed last week (discovered by Daniel). Could you verify whether the strange behavior still shows up with the current CVS-version of Lucene. You may use your old index. Reindexing is not necessary. Thanks, Christoph I'm us

cvs commit: jakarta-lucene/src/java/org/apache/lucene/index SegmentTermEnum.java SegmentTermDocs.java SegmentMerger.java TermInfosWriter.java

goller 2004/04/20 06:47:58 Modified:src/java/org/apache/lucene/index SegmentTermEnum.java SegmentTermDocs.java SegmentMerger.java TermInfosWriter.java Log: hopefully corrected or at least improved version of skipTo Revision Chang

cvs commit: jakarta-lucene/src/test/org/apache/lucene/search TestPhraseQuery.java

goller 2004/04/20 06:39:08 Modified:src/test/org/apache/lucene/search TestPhraseQuery.java Log: test added that demonstrates an already fixed bug in PhraseScorer of 1.4rc2 Revision ChangesPath 1.5 +26 -0 jakarta-lucene/src/test/org/apache/lucene/search/TestP

RE: Fuzzy query with Jaro-Winkler distance

I think it is as simple as 'modifying' FuzzyQuery.java, check a 'environment variable', and then either instantiate a FuzzTermEnum(), or a SpecialFuzzyTermEnum(). All of the logic of 'FuzzyTerm' is contained in FuzzyTermEnum.java. If it is nothing more than a different difference calculation, the

RE: incorrect OO in lucene source?

Not exactly. Nothing is "preventing" me, it just seemed a bit "wrong". I am involved in a quite large development project which uses Lucene in a small capacity. I would have liked to leave behind code that was easier to maintain/understand - I think the proper use of interfaces would have helped.

Re: cvs commit: jakarta-lucene/src/java/org/apache/lucene/index MultiReader.java FilterIndexReader.java IndexReader.java SegmentReader.java

> Hi Incze, > > looks like the bug in PhraseScorer that I fixed last week (discovered by > Daniel). Could you verify whether the strange behavior still shows up with > the > current CVS-version of Lucene. You may use your old index. Reindexing is not > necessary. > > Thanks, > Christoph I'm us

RE: How To Find Fix for a Bug?

Actually, I was incorrect. The version of the code I was running against was 1.4rc1. Updating the BooleanScorer did the trick. Robert Engels -Original Message- From: Christoph Goller [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 3:40 AM To: Lucene Developers List Subject: Re: Ho

Re: Fuzzy query with Jaro-Winkler distance

On Apr 20, 2004, at 5:11 AM, eks dev wrote: Hi All, I would like to use Fuzzy Query with another type(s) of string distance. You will have to write your own Query (probably subclass MultiTermQuery) to do this. The FuzzyQuery calculations are buried deep and not customizable (at least not cur

cvs commit: jakarta-lucene/xdocs contributions.xml

otis2004/04/20 02:41:50 Modified:docs contributions.html xdocscontributions.xml Log: - Added Lindex Revision ChangesPath 1.39 +50 -0 jakarta-lucene/docs/contributions.html Index: contributions.html ===

Fuzzy query with Jaro-Winkler distance

Sorry for previous email, wrong click. This is complete: Hi All, I would like to use Fuzzy Query with another type(s) of string distance. For now, I plan to implement Jaro-Winkler distance. Can somebody give me a hint what would be the best place/way to slot it in in Lucene? Ideally, cu

Re: incorrect OO in lucene source?

Robert, I agree with your sentiment about interfaces. I haven't looked into the specifics of what you mention about IndexReader though. Out of curiosity - is there something about Lucene's design that is preventing you from extending Lucene? Pragmatically speaking, we shouldn't change anythi

Fuzzy query with Jaro-Winkler distance

Hi All, I would like to use Fuzzy Query with another type(s) of string distance. Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger

Re: How To Find Fix for a Bug?

Robert Engels wrote: I am working on lucene 1.3 final, and it appears to have the same bug as 1.4rc1 http://issues.apache.org/bugzilla/show_bug.cgi?id=2 How can I find out which files were changed to fix this bug? (so I can apply the changes back to 1.3). Thanks Robert Engels BooleanScorer cha

Re: cvs commit: jakarta-lucene/src/java/org/apache/lucene/index MultiReader.java FilterIndexReader.java IndexReader.java SegmentReader.java

Incze Lajos wrote: I'm putting my findings here, as seems to me related. In a mid size corpora I've found the following mistery: 1) +SZIDO:"jan 1"-- 92 hits 2) +SZIDO:"jan 1" +TYPE:ER-CIKK -- 433 hits 3) +SZIDO:"jan 1" +TYPE:ER-CIKK NONSENSE

DO NOT REPLY [Bug 28405] - error in finding indexed document

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 28285] - [PATCH] Ordered spanquery with slop can fail

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 28405] - error in finding indexed document

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

cvs commit: jakarta-lucene/xdocs/lucene-sandbox index.xml

otis2004/04/20 00:17:23 Modified:docs contributions.html docs/lucene-sandbox index.html xdocscontributions.xml xdocs/lucene-sandbox index.xml Log: - Moved Highlighter to Sandbox page Revision ChangesPath 1.38 +