DO NOT REPLY [Bug 34563] - Efficient Sorting of DateField/DateTools Encoded Timestamp Long Values

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 34563] - Efficient Sorting of DateField/DateTools Encoded Timestamp Long Values

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 34563] New: - Efficient Sorting of DateField/DateTools Encoded Timestamp Long Values

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: DO NOT REPLY [Bug 31841] - [PATCH] MultiSearcher problems with Similarity.docFreq()

Yes, this is better: +1 Otis --- Doug Cutting <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=31841 > > > > > > [EMAIL PROTECTED] changed: > > > >What|Removed |Added > > > -

Re: Jakarta image on lucene.apache.org

Hm, I'd like to replace it with a generic Apache logo... but it looks like jakarta-logo.gif comes from the 'site' SVN repository, which is used for xdocs -> docs build: % ant -Dasf.site.home=../../../site/ docs This 'site' SVN repo is for Jakarta projects. Is there one for TLPs? Otis --- Bern

Fwd: [jira] Closed: (INFRA-272) 3 new Lucene mailing lists

Sorry for the delay in sending this out. There are now new lists for Lucene commit messages, one for the Ruby port work that is beginning, and also a general one set up to span all of the Lucene community for use for general discussion across all subprojects. Here are quick links for subscrib

Re: wiki configuration and commit messages

On Apr 21, 2005, at 4:59 PM, Daniel Naber wrote: On Thursday 21 April 2005 22:34, Erik Hatcher wrote: Commits come to [EMAIL PROTECTED] - subscribe to that using [EMAIL PROTECTED] So is the information on this page, that says *all* commits go to commits@, not correct anymore?: http://lucene.apache

Re: wiki configuration and commit messages

On Thursday 21 April 2005 22:34, Erik Hatcher wrote: > Commits come to [EMAIL PROTECTED] - subscribe to that > using [EMAIL PROTECTED] So is the information on this page, that says *all* commits go to commits@, not correct anymore?: http://lucene.apache.org/java/docs/mailinglists.html Regards

Re: wiki configuration and commit messages

On Apr 21, 2005, at 4:12 PM, Daniel Naber wrote: I didn't get a commit message about Otis' and my SVN commits yesterday. Is that a problem only on my side? Commits come to [EMAIL PROTECTED] - subscribe to that using [EMAIL PROTECTED] Also, the Wiki start page is a German page if your browser if

wiki configuration and commit messages

Hi, I didn't get a commit message about Otis' and my SVN commits yesterday. Is that a problem only on my side? Also, the Wiki start page is a German page if your browser if configured for German, i.e. you get a page with meta information about the Wiki, not about Lucene. Who has access to the

Re: search on stored, unindexed fields?

On Thursday 21 April 2005 20:47, Robert Engels wrote: > Has there ever been any work done to allow the searching on stored, but > unindexed fields? Only indexed fields can be searched, but any field can be both indexed and stored. > It does not seems to be trivial, since a user could use and/or c

search on stored, unindexed fields?

Has there ever been any work done to allow the searching on stored, but unindexed fields? It does not seems to be trivial, since a user could use and/or constructs that mixed indexed and non-indexed fields. On a related note, does lucene optimize the search based on term frequency? So that if I

search on stored, unindexed fields?

Has there ever been any work done to allow the searching on stored, but unindexed fields? It does not seems to be trivial, since a user could use and/or constructs that mixed indexed and non-indexed fields. On a related note, does lucene optimize the search based on term frequency? So that if I

Re: UnscoredRangeQuery

On Thursday 21 April 2005 17:41, Yonik Seeley wrote: > OK, so as I said, my previous version of UnscoredRangeQuery that could > work with any number of terms in the range had a problem - it could > return duplicates if a doc had more than one term in the range. > > Here is how I fixed it: > I hack

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

Wolf Siberski wrote: In each case applications should call a corresponding Searcher method. Here I don't agree completely and have another suggestion to resolve that issue. The affected methods are low-level API methods anyway, and even before their javadoc referred application developers to othe

Re: Lucene Benchmark - Wintel faster than Unix (?)

At home, running a dual boot WinXPsp2 and Fedora Core 3, I found that FC3 was faster. At least initially. The difference was staggering. Indexing a Bible, creating one doc per verse and storing the verse reference but not storing the verse, took a couple of minutes under FC3 and 2.5+ hours under

Re: Lucene Benchmark - Wintel faster than Unix (?)

_Not_ to start wars over pentium/vs/opteron/vs/sparc or unix/vs/linux/vs/windows. I thought this was a very valid observation. That confuses many a good man. Also, there are most likely many people making hardware decisions for Lucene going into production ( I know I made one ) The better the deci

Re: UnscoredRangeQuery

OK, so as I said, my previous version of UnscoredRangeQuery that could work with any number of terms in the range had a problem - it could return duplicates if a doc had more than one term in the range. Here is how I fixed it: I hacked together an UnscoredQuery that takes a Filter (it's like Filte

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

Doug Cutting wrote: When we deprecate things we should ensure: 1. That, if they're removed, everything else should keep working. 2. That they should indicate what should be used instead. In Searchable.java we now have methods whose javadoc refers to deprecated methods, which will be a problem if t

Re: Jakarta image on lucene.apache.org

Otis, why not replacing the apache-jakarta image on the lucene website with the image from http://apache.org ? That would be the easiest way to get rid of the Jakarta reference. Bernhard Otis Gospodnetic wrote: Hello, I just realized that we still have one big left-over Jakarta reference - it's