Re: Questions about DeleteFile method

Judging from the method name, this is back in Lucene.Net, so maybe this is a bug in the .Net port. The .cfs file indicates that you are using the compound index format, which means that *.fN files should not be deleted explicitly like that. I wonder if you see the same behaviour with Lucene (Java)

Questions about DeleteFile method

So after digging around FSDirectory's DeleteFile method, I noticed something curious. After an incremental index, the system tried to delete a lot of *.f* files (like _5.f1, _5.f2), which didn't exist on the file system. These files are named after the segment that is being deleted (for example, t

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

Thanks! Wolfgang. I've committed this change after it successfully worked for me. Thanks! Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: build process changes

On May 2, 2005, at 2:52 PM, Doug Cutting wrote: Thanks for doing all this! It looks great! *whew* - thanks. As always, let me know if there is anything further I can do. I'll tidy things up as I go with it. What are your thoughts on what files we should actually distribute? There is merit

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

On May 2, 2005, at 5:21 PM, Wolfgang Hoschek wrote: Finally found and fixed the bug! The fix is simply to replace MemoryIndex.MemoryIndexReader skipTo() with the following: public boolean skipTo(int target) { if (DEBUG) System.err.println(".skipTo: " + targe

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

The version I sent returns in O(1), if performance was your concern. Or did you mean something else? Since 0 is the only document number in the index, a return target == 0; might be nice for skipTo(). It doesn't really help performance, though, and the next() works just as well. Regards, Paul Elsc

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

On Monday 02 May 2005 23:38, Wolfgang Hoschek wrote: > > Yes, the svn trunk uses skipTo more often than 1.4.3. > > > > However, your implementation of skipTo() needs some improvement. > > See the javadoc of skipTo of class Scorer: > > > > http://lucene.apache.org/java/docs/api/org/apache/lucene/sea

Lucene 1.9 java.nio in MMapDirectory

Hi Folks, I am looking at Lucene 1.9 RC1 and noticed that MMapDirectory is using java.nio. Isn't java.nio based on Java 1.4? If so, isn't Lucene 1.9 suppose to be backward compatible with Java 1.3? Regards, -- George Aroush

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

Yes, the svn trunk uses skipTo more often than 1.4.3. However, your implementation of skipTo() needs some improvement. See the javadoc of skipTo of class Scorer: http://lucene.apache.org/java/docs/api/org/apache/lucene/search/ Scorer.html#skipTo(int) What's wrong with the version I sent? Remeber t

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

Wolfgang, On Monday 02 May 2005 23:21, Wolfgang Hoschek wrote: > Finally found and fixed the bug! > The fix is simply to replace MemoryIndex.MemoryIndexReader skipTo() > with the following: > > public boolean skipTo(int target) { >

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

Finally found and fixed the bug! The fix is simply to replace MemoryIndex.MemoryIndexReader skipTo() with the following: public boolean skipTo(int target) { if (DEBUG) System.err.println(".skipTo: " + target);

DO NOT REPLY [Bug 10340] - [PATCH] Phonetic Search capability

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 10340] - [PATCH] Phonetic Search capability

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 10340] - [PATCH] Phonetic Search capability

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 23655] - [PATCH] Provide a java.util.List wrapper around the Hits object

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: geographical searches

2005/5/2, Guillermo Payet <[EMAIL PROTECTED]>: > > If you're only searching for any term using *, I'm not sure why you're > > using Lucene? > > Most searches are not as simple, and for those the GeoFilter does > the trick. I'm just trying to optimize for the few searches for > all items within an

Re: build process changes

Thanks for doing all this! It looks great! Erik Hatcher wrote: However it seems much simpler for us to only distribute lucene-XX.tar.gz/zip and lucene-XX-src.tar.gz/.zip rather than distributing each contrib component separately. I agree. The current build process builds the same 4 distributio

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

This is what I have as scoring calculation, and it seems to do exactly what lucene-1.4.3 does because the tests pass. public byte[] norms(String fieldName) { if (DEBUG) System.err.println("MemoryIndexReader.norms: " + fieldName); Info info = getInfo(fieldName); int numTokens = info

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

I'm looking at it right now. The tests pass fine when you put lucene-1.4.3.jar instead of the current lucene onto the classpath which is what I've been doing so far. Something seems to have changed in the scoring calculation. No idea what that might be. I'll see if I can find out. Wolfgang

Re: geographical searches

> If you're only searching for any term using *, I'm not sure why you're > using Lucene? Most searches are not as simple, and for those the GeoFilter does the trick. I'm just trying to optimize for the few searches for all items within an area. On Mon, May 02, 2005 at 08:24:07AM -0500, [EMAIL P

Re: geographical searches

I don't really need any geographical scoring. I just need to be able to show all items within a region. Since a lot of the complexity of "Query" has to do with scoring, would it be better to just use the GeoFilter, and to search for *? Are there any performance issues with this? You might try

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

On May 1, 2005, at 10:20 PM, Wolfgang Hoschek wrote: I've uploaded code that now runs against the current SVN, plus junit test cases, plus some minor internal updates to the functionality itself. For details see http://issues.apache.org/bugzilla/show_bug.cgi?id=34585 Be prepared for the test

Re: too many classes visible with "ant javadocs"

On May 1, 2005, at 9:32 PM, Brian Goetz wrote: junit.jar really ought to be removed from our repository. Due to classloader issues, doesn't work with junit.jar anywhere but in the classpath that launches Ant. The Ant best practice is to put junit.jar in ANT_HOME/lib anyway. I have adjusted the