Fwd: [jira] Commented: (INFRA-199) Convert Lucene's Bugzilla to JIRA
Here's the status of my request to migrate to JIRA. So we'll be waiting for the upgrade before the migration. Erik Begin forwarded message: From: Jeff Turner (JIRA) [EMAIL PROTECTED] Date: February 20, 2005 9:19:48 PM EST To: [EMAIL PROTECTED] Subject: [jira] Commented: (INFRA-199) Convert Lucene's Bugzilla to JIRA [ http://issues.apache.org/jira/browse/INFRA-199? page=comments#action_59477 ] Jeff Turner commented on INFRA-199: --- The bugzilla importer has a bug which results in zero-byte attachments on imported issues (see INFRA-123). This will be fixed in JIRA 3.1.1, so I'd suggest waiting for that. Convert Lucene's Bugzilla to JIRA - Key: INFRA-199 URL: http://issues.apache.org/jira/browse/INFRA-199 Project: Infrastructure Type: Task Components: JIRA Reporter: Erik Hatcher Priority: Minor The Lucene team would like the issue tracker converted to JIRA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: lucene.apache.org problems again
Looks like the issue has been resolved with the lucene.apache.org DNS. Erik Begin forwarded message: From: Ask Bjørn Hansen [EMAIL PROTECTED] Date: February 20, 2005 9:34:50 PM EST To: Noel J. Bergman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Erik Hatcher [EMAIL PROTECTED] Subject: Re: lucene.apache.org problems again On Feb 20, 2005, at 9:16 AM, Noel J. Bergman wrote: The bitname.com name servers haven't updated. Surnet and Hyperreal have done so. Checking the allowed list, I see: Fixed. The process that does that had become stuck. I unstuck it and added an anti-stuck measure. Thanks! - ask -- http://www.askbjoernhansen.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=31841. 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-02-21 18:49 --- This looks good. Thanks! A few comments: Orignally there was no Weight in Lucene, only Query and Scorer. Weight was added in order to make it so that searching did not modify a Query, so that a Query instance could be reused. Searcher-dependent state of the query is meant to reside in the Weight. IndexReader dependent state resides in the Scorer. Your freezing a query violates this. Can't we create the weight once in Searcher.search? CachedDfSource does not need to be public does it? We need to think about back-compatibliity. Folks have implementations of Query, Weight, Similarity and Scorer. So, when a public API changes we need to deprecate, not remove, old methods, and try hard to make the old version still work. So, for example, we need to figure out how to handle the case where folks have implemented the old Similarity.idf() methods. You no longer call Query.getSimilarity(Searcher). That method permits queries to override the Searcher's Similarity implementation. Is there a reason you do this? We should be computing DFs once for the whole query tree, but it should still be possible to compute, e.g., IDFs independently per node, no? I also wonder if, instead of adding DocFreqSource we could instead still use the Searcher. MultiSearcher could keep an LRU cache of total doc freqs, implemented with LinkedHashMap, for the last few thousand search terms. That would be a far less invasive change, and hence less likely to break folks. Or am I missing something? Sorry if I seem picky, but this is core stuff in Lucene and affects a lot of people. -- 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: How to proceed with Bug 31841 - MultiSearcher problems with Similarity.docFreq() ?
Wolf Siberski wrote: Now I found another solution which requires more changes, but IMHO is much cleaner: - when a query computes its Weight, it caches it in an attribute - a query can be 'frozen'. A frozen query always returns the cached Weight when calling Query.weight(). Orignally there was no Weight in Lucene, only Query and Scorer. Weight was added in order to make it so that searching did not modify a Query, so that a Query instance could be reused. Searcher-dependent state of the query is meant to reside in the Weight. IndexReader dependent state resides in the Scorer. Your freezing a query violates this. Can't we create the weight once in Searcher.search? This approach requires that weights can be serialized. Interestingly, Weight already implements Serializable, but the current implementation doesn't work for all weight classes. The reason is that some weights hold a reference to a searcher which is of course not serializable. We can't make it transient either, because this searcher is the source of the Similarity needed by scorers. On closer look it turned out that the searcher is used only for two things: as source for a Similarity, and as docFreqsmaxDoc source. docFreqmaxDoc are only necessary to initialize the weights, but not needed by scorers. So instead of providing the Searcher, I now provide a Similarity and a DocFreqSource to the weights. Only the Similarity is stored by weights. We need to make sure, however, that this is the correct Similarity. It should still be the result of Query.getSimilarity(Searcher), which doesn't appear to be the case in your patch. As for DocFreqSource versus Searcher, couldn't the Searcher be passed as a source for docFreqs and simoly have Weights not keep a pointer to it? This isn't a big deal, but it would substantially mimimize the API changes. As (IMHO) positive side effect, Similarity got rid of Searcher dependencies, which leads to a better split of responsibilities: - Similarity only provides scoring formulas - Searcher (rsp. DocFreqSource) provides the raw data (tf/df/maxDoc) This change affects quite a few classes (because the createWeight() signature is changed), but the modifications are pretty straightforward. But couldn't the signature change be avoided if the Weight constructors immediately call Query.getSimilarity(Searcher) to get their Similarity, and no longer kept a pointer to the Searcher? From my point of view, the patch submitted now is a sound solution for Bug 31841 (at least I like it :-) ). The next thing which IMHO needs to be done is a review by someone else. I've make a quick review, but it would be nice if others looked at this too. Thanks again for all your work here! Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Into javadocs? [Bug 31841] - [PATCH] MultiSearcher problems with Similarity.docFreq()
Doug, Would you mind if some pieces of your reply end up in the javadocs? Regards, Paul Elschot. On Monday 21 February 2005 18:49, [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31841. 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-02-21 18:49 --- This looks good. Thanks! A few comments: Orignally there was no Weight in Lucene, only Query and Scorer. Weight was added in order to make it so that searching did not modify a Query, so that a Query instance could be reused. Searcher-dependent state of the query is meant to reside in the Weight. IndexReader dependent state resides in the Scorer. Your freezing a query violates this. Can't we create the weight once in Searcher.search? CachedDfSource does not need to be public does it? We need to think about back-compatibliity. Folks have implementations of Query, Weight, Similarity and Scorer. So, when a public API changes we need to deprecate, not remove, old methods, and try hard to make the old version still work. So, for example, we need to figure out how to handle the case where folks have implemented the old Similarity.idf() methods. You no longer call Query.getSimilarity(Searcher). That method permits queries to override the Searcher's Similarity implementation. Is there a reason you do this? We should be computing DFs once for the whole query tree, but it should still be possible to compute, e.g., IDFs independently per node, no? I also wonder if, instead of adding DocFreqSource we could instead still use the Searcher. MultiSearcher could keep an LRU cache of total doc freqs, implemented with LinkedHashMap, for the last few thousand search terms. That would be a far less invasive change, and hence less likely to break folks. Or am I missing something? Sorry if I seem picky, but this is core stuff in Lucene and affects a lot of people. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Into javadocs? [Bug 31841] - [PATCH] MultiSearcher problems with Similarity.docFreq()
Paul Elschot wrote: Would you mind if some pieces of your reply end up in the javadocs? Not at all. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33678] New: - More javadocs for Weight
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33678. 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=33678 Summary: More javadocs for Weight Product: Lucene Version: CVS Nightly - Specify date in submission Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Search AssignedTo: lucene-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] From Doug's reply of 21 Feb 2005 in bug 31841 -- 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]
[ANNOUNCE] Lucene4c 0.03
I'm happy to announce the release of version 0.03 of Lucene4c, a port of Lucene to the C language using the Apache Portable Runtime. This release adds several APIs for running operations over an entire index where previous versions only allowed you to do so with a single segment, improves a number of the error messages for various problems, adds explicit document and field objects, fixes the compound file stream code that was released in the previous version and last but not least adds doxygen style API documentation for the public APIs. With luck this will be the last release before the project moves into the ASF incubator. As usual, the new tarball (as well as previous versions) is available from the project web site: http://electricjellyfish.net/garrett/lucene4c/ HTML versions of the API docs are available at http://electricjellyfish.net/garrett/lucene4c/apidocs/ If you just can't wait for the next version to get whatever halfway finished code I'm working on please feel free to grab it from Subversion at svn://rooneg.dyndns.org/dev/lucene4c/trunk As always, commentary, questions and patches are always welcome. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
