btw, the Lenya Wiki is experiencing the same problems. I think it would
make sense that people have to ask for a Wiki account on the development
list, otherwise one just keeps chasing these spammers endlessly ...
just my 2 cents
Michael
Simon Willnauer wrote:
cheers Grant!!
regards simon
Raman Kaur wrote:
Hi,
I have few questions about lucene builds and tests.
1. On which jdk versions and operating systems lucene is tested on.
2. I found out information about Lucene nightly builds and tests at
http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/
From the above url, i
Raman,
Lucene is built and tested under Linux here:
http://parabuild.viewtier.com:8080/parabuild/index.htm?displaygroupid=5
Regards,
Slava Imeshev
- Original Message -
From: "Raman Kaur" <[EMAIL PROTECTED]>
To:
Sent: Monday, March 26, 2007 7:54 PM
Subject: jdks and operating systems
Hi,
I have few questions about lucene builds and tests.
1. On which jdk versions and operating systems lucene is tested on.
2. I found out information about Lucene nightly builds and tests at
http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/
From the above url, it looks like build
[
https://issues.apache.org/jira/browse/LUCENE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Busch updated LUCENE-431:
-
Description:
>From java-dev, Doug's reply of 12 Sep 2005
on Delaying buffer allocation in Buff
[
https://issues.apache.org/jira/browse/LUCENE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Busch updated LUCENE-431:
-
Attachment: lucene-431.patch
We should fix both, RAMInputStream and RAMOutputStream to subclass I
[
https://issues.apache.org/jira/browse/LUCENE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Busch reassigned LUCENE-431:
Assignee: Michael Busch (was: Lucene Developers)
> RAMInputStream without further bufferin
[
https://issues.apache.org/jira/browse/LUCENE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Busch reassigned LUCENE-431:
Assignee: Michael Busch (was: Lucene Developers)
> RAMInputStream without further bufferin
[
https://issues.apache.org/jira/browse/LUCENE-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484258
]
Marvin Humphrey commented on LUCENE-851:
On Mar 26, 2007, at 3:45 PM, Karl Wettin (JIRA) wrote:
> I did not
[
https://issues.apache.org/jira/browse/LUCENE-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484253
]
Karl Wettin commented on LUCENE-851:
I did not mean it should be used for primary sorting, but rather as you
des
[
https://issues.apache.org/jira/browse/LUCENE-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484248
]
Marvin Humphrey commented on LUCENE-851:
That suggests an implementation derived from how sorting is currentl
Ask on java-user, java-dev is for people developing Lucene, java-user
is for questions of this nature.
Also, look at the javadocs for StandardAnalyzer, as it uses the
StopTokenFilter. You need to pass in your stopwords or use the
default stop set.
-Grant
On Mar 26, 2007, at 5:30 PM, Tim
[
https://issues.apache.org/jira/browse/LUCENE-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484234
]
Karl Wettin commented on LUCENE-851:
If this is what I think, then it is really cool and can be very interesting
I would like to be able to get terms from my data that are a combination of
two existing analyzers.
I would like this for both posting and searching of various fields.
An example of the data might be as follows:
Hello XY&Z Corporation - [EMAIL PROTECTED]
I would like the following terms to com
Pruning
---
Key: LUCENE-851
URL: https://issues.apache.org/jira/browse/LUCENE-851
Project: Lucene - Java
Issue Type: New Feature
Components: Index, Search
Reporter: Marvin Humphrey
Priority: Minor
Gree
[
https://issues.apache.org/jira/browse/LUCENE-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated LUCENE-850:
--
Attachment: prodscorer.patch.diff
Generify the subquery handling logic of DisMax to make it easy to bui
[
https://issues.apache.org/jira/browse/LUCENE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484195
]
Mike Klaas commented on LUCENE-446:
---
I've often wanted to multiply the scores of two queries. I looked at
Functio
Easily create queries that transform subquery scores arbitrarily
Key: LUCENE-850
URL: https://issues.apache.org/jira/browse/LUCENE-850
Project: Lucene - Java
Issue Type: New Fe
cheers Grant!!
regards simon
On 3/26/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
FYI.
I have taken care of the Gdata issues
Begin forwarded message:
> From: Joe Schaefer <[EMAIL PROTECTED]>
> Date: March 26, 2007 2:45:36 PM EDT
> To: [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTE
FYI.
I have taken care of the Gdata issues
Begin forwarded message:
From: Joe Schaefer <[EMAIL PROTECTED]>
Date: March 26, 2007 2:45:36 PM EDT
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL P
"Ning Li" <[EMAIL PROTECTED]> wrote:
> On 3/26/07, Michael McCandless (JIRA) <[EMAIL PROTECTED]> wrote:
> > Ahhh, this is a very good point. OK I won't deprecate "flushing by
> > doc count" and instead will allow either "flush by RAM usage" (default
> > to this?) or "flush by doc count".
>
> Just
> Very long documents are useful for testing for anomalies, but they're
> not so useful as retrieved documents, nor typical of applications.
That's what I thought, too. I'm kinda curious to see how gutenburg
compares to wikipedia for things like merge policy, in particular,
by-docs vs. by-bytes.
On 3/26/07, Michael McCandless (JIRA) <[EMAIL PROTECTED]> wrote:
Ahhh, this is a very good point. OK I won't deprecate "flushing by
doc count" and instead will allow either "flush by RAM usage" (default
to this?) or "flush by doc count".
Just want to clarify: It's either "flush and merge by by
Steven Parkes wrote:
And what about Project Gutenburg?
Wikipedia is going to have relatively short text, Gutenburg very long.
Very long documents are useful for testing for anomalies, but they're
not so useful as retrieved documents, nor typical of applications. Very
long hits are awkward f
[
https://issues.apache.org/jira/browse/LUCENE-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484175
]
Michael McCandless commented on LUCENE-845:
---
>> With LUCENE-843 I'm thinking we should deprecate maxBuffere
Yonik Seeley wrote:
The java coding standards do say
"Spaces after keywords but no spaces either before or after
parentheses in method calls"
"if (a)" and "foo(a)"
Lucene's formatting guidelines are stated at:
http://wiki.apache.org/lucene-java/HowToContribute
In short, they say: Sun's conve
[
https://issues.apache.org/jira/browse/LUCENE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen resolved LUCENE-849.
Resolution: Fixed
Lucene Fields: [Patch Available] (was: [Patch Available, New])
Committed.
[
https://issues.apache.org/jira/browse/LUCENE-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484150
]
Yonik Seeley commented on LUCENE-845:
-
> With LUCENE-843 I'm thinking we should deprecate maxBufferedDocs entirel
[
https://issues.apache.org/jira/browse/LUCENE-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484139
]
Benjamin Henriet commented on LUCENE-835:
-
Hi Mark,
Thank you for your work. You said: "Query-parse-time inje
29 matches
Mail list logo
