[
https://issues.apache.org/jira/browse/LUCENE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-626:
---
Attachment: spellchecker.diff
NgramPhraseSuggester is now decoupled from the adaptive layer, but I wo
[
https://issues.apache.org/jira/browse/LUCENE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-626:
---
Attachment: (was: spellchecker.diff)
> Extended spell checker with phrase support and adaptive us
[
https://issues.apache.org/jira/browse/LUCENE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-626:
---
Description:
Some minor changes to how the single token ngram spell checker in
contrib/spellcheck,
[
https://issues.apache.org/jira/browse/LUCENE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-626:
---
Comment: was deleted
> Adaptive, user query session analyzing spell checker.
> --
[
https://issues.apache.org/jira/browse/LUCENE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-626:
---
Comment: was deleted
> Adaptive, user query session analyzing spell checker.
> --
[
https://issues.apache.org/jira/browse/LUCENE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-626:
---
Comment: was deleted
> Adaptive, user query session analyzing spell checker.
> --
[
https://issues.apache.org/jira/browse/LUCENE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-626:
---
Comment: was deleted
> Adaptive, user query session analyzing spell checker.
> --
[
https://issues.apache.org/jira/browse/LUCENE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-626:
---
Comment: was deleted
> Adaptive, user query session analyzing spell checker.
> --
[
https://issues.apache.org/jira/browse/LUCENE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-626:
---
Comment: was deleted
> Adaptive, user query session analyzing spell checker.
> --
FYI, I filed a Solr bug for this issue:
https://issues.apache.org/jira/browse/SOLR-138
-Yonik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I think that is much more involved... I don't think there is an easy
way to move a query between threads/pools once it has started unless
you restart the entire query.
You might be able to dynamically lower the thread priority however
when you detect a long query, so that smaller (faster) q
robert engels <[EMAIL PROTECTED]> wrote on 02/02/2007 14:08:46:
> You might be able to quantify the search request ahead of time (# of
> terms, # of high frequency terms, etc.) and assign the request to the
> appropriate pool (quick, normal, lengthy).
>
> Then you can assign an appropriate # of th
You might be able to quantify the search request ahead of time (# of
terms, # of high frequency terms, etc.) and assign the request to the
appropriate pool (quick, normal, lengthy).
Then you can assign an appropriate # of threads to each pool.
Most people understand that complex queries migh
On 2/2/07, robert engels <[EMAIL PROTECTED]> wrote:
For a process that is mostly CPU bound (which is the case with Lucene
if the index is in the OS cache), having so many "active" threads
will actually hurt performance due to the context switching and
synchronization.
Sure... it certainly wasn'
FYI,
For a process that is mostly CPU bound (which is the case with Lucene
if the index is in the OS cache), having so many "active" threads
will actually hurt performance due to the context switching and
synchronization. Better to use a request queue / thread pool. (I
think I read somewh
Yonik Seeley wrote:
I think synchronization can become expensive under heavy contention,
regardless of how lightweight the code inside.
I'm skeptical of this. It's possible, but I've never seen it.
Doug
-
To unsubscribe, e-m
On 2/2/07, Doug Cutting <[EMAIL PROTECTED]> wrote:
Yonik Seeley wrote:
> I ran across a situation where a great number of threads were blocked on
> ensureIndexIsRead(), even after it had already been loaded.
That sounds bizarre. A sync block that tests a field for non-null
shouldn't tie things
Yonik Seeley wrote:
I ran across a situation where a great number of threads were blocked on
ensureIndexIsRead(), even after it had already been loaded.
That sounds bizarre. A sync block that tests a field for non-null
shouldn't tie things up much, I wouldn't think. Are you sure that one
of
On 2/2/07, Doug Cutting <[EMAIL PROTECTED]> wrote:
Yonik Seeley wrote:
> What was the use-case behind loading the term index lazily?
> I'm having a hard time figuring out what one would do with an
> IndexReader that doesn't involve a term lookup somehow.
Index merging only iterates through terms
[
https://issues.apache.org/jira/browse/LUCENE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469837
]
Michael McCandless commented on LUCENE-793:
---
Good idea! I will take that approach.
> Javadocs should expl
Check index version?
Otis
- Original Message
From: Yonik Seeley <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Friday, February 2, 2007 1:36:35 PM
Subject: TermInfosReader lazy term index reading
What was the use-case behind loading the term index lazily?
I'm having a hard tim
You only need to load it for segments that are read, instead of
paying the init price on all segments that may never be used.
On Feb 2, 2007, at 12:36 PM, Yonik Seeley wrote:
What was the use-case behind loading the term index lazily?
I'm having a hard time figuring out what one would do with
Yonik Seeley wrote:
What was the use-case behind loading the term index lazily?
I'm having a hard time figuring out what one would do with an
IndexReader that doesn't involve a term lookup somehow.
Index merging only iterates through terms.
Doug
---
What was the use-case behind loading the term index lazily?
I'm having a hard time figuring out what one would do with an
IndexReader that doesn't involve a term lookup somehow.
-Yonik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
[
https://issues.apache.org/jira/browse/LUCENE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469819
]
Doug Cutting commented on LUCENE-793:
-
Should we add more precise exceptions for these cases, and add them to the
I'm late, but here is another willkommen from China.
Otis
- Original Message
From: Doug Cutting <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Cc: [EMAIL PROTECTED]
Sent: Thursday, February 1, 2007 12:17:59 PM
Subject: Welcome Michael Busch
The Lucene PMC has voted to add Michael Bu
Also, let me know tomorrow if it doesn't update, as I have sometimes
noticed it doesn't always work and I haven't had time to investigate
it just yet. It is strange, b/c I then run the same command that is
run by the cron and everything works just fine.
On Feb 2, 2007, at 9:08 AM, Michael
On 2/2/07, Michael Busch <[EMAIL PROTECTED]> wrote:
Grant, it seems you own the directory, but the group doesn't have write
access...
Or am I doing anything wrong?
I don't think so. Everyone should make sure their umask is 002
-Yonik
-
Hi Michael,
Btw, welcome aboard! Glad to have such good help!
From http://wiki.apache.org/jakarta-lucene/CommittersResources on
the Wiki, see http://wiki.apache.org/jakarta-lucene/
HowToUpdateTheWebsite
Essentially, all you _should_ have to do is commit your changes to
both the src tree
Hi,
I just added myself to the "Who we are" page, regenerated it and
committed the changes. Now I tried to update the website by doing:
ssh people.apache.org
cd /www/lucene.apache.org/java/docs
svn up
It fails with the following message:
svn: Can't open file 'images/.svn/lock': Permission
Doug Cutting wrote:
The Lucene PMC has voted to add Michael Busch as a Lucene committer.
Welcome, Michael!
Doug
Thanks everyone for the nice words!
Of course I want to keep the tradition alive, so here follows my
introduction :-)
I am from Germany (more exactly from the Sauerland :-) ). I
Hi Hui,
We love contributions! Take a look at http://wiki.apache.org/jakarta-
lucene/HowToContribute
Are these changes on top of Lucene or part of the core? If they are
on top, they could go as a contrib which is much easier to get
accepted. The best way to submit changes is through a pa
Javadocs should explain possible causes for IOExceptions
Key: LUCENE-793
URL: https://issues.apache.org/jira/browse/LUCENE-793
Project: Lucene - Java
Issue Type: Bug
Componen
Dear Hui,
i'm a Ph. d. student from University Complutense of Madrid (Spain)
where i'm teaching assistant also, in the departament of Artificial
Intelligence. I'm working with Lucene from two years ago, and i'm very
interesting on re-implement certain classes (TermQuery, TermScorer,
DefaultSimil
- Mensaje original -
De: Hui Fang <[EMAIL PROTECTED]>
Fecha: Viernes, Febrero 2, 2007 5:45 am
Asunto: implementatin of the state-of-art retrieval models for lucene?
A: java-dev@lucene.apache.org
> Dear all,
>
> My primary research interest is Information retrieval, with a
> focus on
>
PrecedenceQueryParser misinterprets queries starting with NOT
-
Key: LUCENE-792
URL: https://issues.apache.org/jira/browse/LUCENE-792
Project: Lucene - Java
Issue Type: Bug
>>are there any legitimate usecases for calling rewrite other then when a
>>Searcher is about to execute the query?
When using the highlighter it is recommended to use a rewritten query e.g. to
get all the variations for a fuzzy query.
However I don't think there should be a problem with the aut
Hi,
Here is the link to the actual paper:
http://crpit.com/confpapers/CRPITV27Anh.pdf
Regards,
Thang.
On 2/2/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 2/1/07, Thang Luong Minh <[EMAIL PROTECTED]> wrote:
> I'm thinking of replace the byte-aligned scheme with the "fixed binary"
> coding
38 matches
Mail list logo
