headers
Steven Parkes (JIRA | 1 Jun 2007 01:14
Picon
Favicon

[jira] Commented: (LUCENE-763) LuceneDictionary skips first word in enumeration


    [
https://issues.apache.org/jira/browse/LUCENE-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500521
] 

Steven Parkes commented on LUCENE-763:
--------------------------------------

Can we also update the javadocs to reflect the different semantics between terms() and terms(term)?
Here's some possible verbage. (Also tweaks the "after the given term" which I think isn't correct?) 

{noformat} 
Index: src/java/org/apache/lucene/index/IndexReader.java
===================================================================
--- src/java/org/apache/lucene/index/IndexReader.java   (revision 543284)
+++ src/java/org/apache/lucene/index/IndexReader.java   (working copy)
 <at>  <at>  -539,16 +539,21  <at>  <at> 
     setNorm(doc, field, Similarity.encodeNorm(value));
   }

-  /** Returns an enumeration of all the terms in the index.
-   * The enumeration is ordered by Term.compareTo().  Each term
-   * is greater than all that precede it in the enumeration.
+  /** Returns an enumeration of all the terms in the index.  The
+   * enumeration is ordered by Term.compareTo().  Each term is greater
+   * than all that precede it in the enumeration.  Note that after
+   * calling { <at> link #terms()}, { <at> link TermEnum#next()} must be called
+   * on the resulting enumeration before calling other methods such as
+   * { <at> link TermEnum#term()}.
    *  <at> throws IOException if there is a low-level IO error
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Elschot | 1 Jun 2007 01:21
Picon
Picon
Favicon

Re: enabling java assertions in the tests

On Friday 01 June 2007 00:30, Doron Cohen wrote:
> 
> While testing LUCENE-866 I realized that Java assertions
> are disabled when *I* run 'ant test'.
> Others did have the assertion executed and causing that
> NPE. So I am not sure if this is general problem or only
> a Windows one.

Indeed, see below. I'm running Linux and java 1.6.0.

> Compile wise we are ok, having "-source 1.4".
> At runtime, assertions can be enabled by running "java -ea".
> Using ant, setting "ANT_ARGS=-ea" is supposed to have the
> same effect, but it doesn't, at least not for me.
> 
> Adding:
>      <assertions>
>          <enable/>
>      </assertions>
>
> to the <junit> task would enable assertions during tests
> regardless of ANT_OPTS variable (and hopefully on all OSs).
> 
> Anyone sees a problem with adding this?

My common-build.xml has this added in the junit task:

      <assertions>
        <enable package="org.apache.lucene"/>
      </assertions>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Doron Cohen | 1 Jun 2007 02:08
Picon
Favicon

Re: enabling java assertions in the tests

DM Smith wrote on 31/05/2007 15:59:05:

> I think that having assertions is of no value if they are never
> turned on :)
>
> I suggest going carefully in adding assertions. There are a lot of
> places where assertions are inappropriate (e.g. checking parameters
> on a public method).
>
> I think Sun's document gives good guidelines:
>
> http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

Perhaps the most important guideline regarding assertions
is that they should *never* have side effects, otherwise
correctness is broken when assertions are disabled.

Doron
Permalink | Reply | 0 comments |
headers
Doron Cohen | 1 Jun 2007 02:17
Picon
Favicon

Re: enabling java assertions in the tests

Paul Elschot <paul.elschot <at> xs4all.nl> wrote on 31/05/2007 16:21:09:

> > Adding:
> >      <assertions>
> >          <enable/>
> >      </assertions>
> >
> > to the <junit> task would enable assertions during tests
> > regardless of ANT_OPTS variable (and hopefully on all OSs).

> My common-build.xml has this added in the junit task:
>
>       <assertions>
>         <enable package="org.apache.lucene"/>
>       </assertions>
>

This enables the asserts for all lucene-java packages, but not
for any external jars being used. I think this is cleaner
because the no-args form would enable asserts also in external
jars and might add noise to our tests.

I'll open an issue and patch it like this!
Permalink | Reply | 0 comments |
headers
Doron Cohen (JIRA | 1 Jun 2007 02:22
Picon
Favicon

[jira] Created: (LUCENE-900) Enable Java asserts in the Junit tests

Enable Java asserts in the Junit tests
--------------------------------------

                 Key: LUCENE-900
                 URL: https://issues.apache.org/jira/browse/LUCENE-900
             Project: Lucene - Java
          Issue Type: Test
          Components: Build
            Reporter: Doron Cohen
            Assignee: Doron Cohen
            Priority: Minor

For background see http://www.mail-archive.com/java-dev <at> lucene.apache.org/msg10307.html

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Permalink | Reply | 2 comments |
headers
Andi Vajda | 1 Jun 2007 02:32
Favicon

RE: addIndexes()


On Thu, 31 May 2007, Steven Parkes wrote:

> Hmmm ... something's not meshing for me here.
>
> If I understood what you've said, you have a DbD index to which you are
> addIndexes'ing a memory index? I must have missed something, because
> addIndexes pre- and post-optimizes the target (Dbd) index, not the
> operand (mem) index.

I stand corrected. I'm using an IndexWriter opened on a RAMDirectory to do the 
indexing for a given transaction. Then I call addIndexes([writer]) on the 
IndexWriter backed by the DbDirectory to persist this. This approach ash 
turned out to be considerably faster and less noisy in the database (the 
amount of random access changes) than indexing into the DbDirectory backed 
index directly and then optimizing it.

The docs for addIndexes() say "After this completes, the index is optimized." 
I mistakenly thought that there was discussion here about making this no 
longer be the case.

Andi..
Permalink | Reply | 0 comments |
headers
Michael Busch (JIRA | 1 Jun 2007 03:51
Picon
Favicon

[jira] Commented: (LUCENE-887) Interruptible segment merges


    [
https://issues.apache.org/jira/browse/LUCENE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500550
] 

Michael Busch commented on LUCENE-887:
--------------------------------------

> This looks great to me!

Thanks for reviewing!

> So, if a shutdown request comes in then currently running addDocument
> calls are allowed to complete but if a new addDocument call tries to
> run it will hit an "IndexWriter already closed" IOException.  Once the
> in-flight addDocument calls finish you then flush the ram segments
> without allowing cascading merge.

Exactly.

> This actually means you can potentially have too many "level 0" (just
> flushed) segments in the index but that should not be a big deal since
> the next merge would clean it up.  And it should be rare.

Yes, unless another shutdown request comes while the first merge after
restarting the system is happening (which should be very unlikely), this
will be cleaned up. Also, once the system is up again the IndexWriter 
will delete left over file fragments from an aborted merge.

> In shutdown(), after you call waitForAddDocument(), why not call
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Busch (JIRA | 1 Jun 2007 03:56
Picon
Favicon

[jira] Commented: (LUCENE-698) FilteredQuery ignores boost


    [
https://issues.apache.org/jira/browse/LUCENE-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500552
] 

Michael Busch commented on LUCENE-698:
--------------------------------------

> So perhaps we can remove the NaN by modifying the default implementation of 
> queryNorm to return 1.0 instead of Infinity when passed zero. Would that 
> cause any harm?

Yes I believe this should work, too. This would prevent the NaN score when
DefaultSimilarity is used. It will be the responsibility of people
who implement their own Similarity then to take care of this in a similar way.

I'll open a new issue for fixing the DefaultSimilarity.

> FilteredQuery ignores boost
> ---------------------------
>
>                 Key: LUCENE-698
>                 URL: https://issues.apache.org/jira/browse/LUCENE-698
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Search
>    Affects Versions: 2.0.0
>            Reporter: Yonik Seeley
>            Assignee: Michael Busch
>            Priority: Minor
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Busch (JIRA | 1 Jun 2007 04:03
Picon
Favicon

[jira] Created: (LUCENE-901) DefaultSimilarity.queryNorm() should never return Infinity

DefaultSimilarity.queryNorm() should never return Infinity
----------------------------------------------------------

                 Key: LUCENE-901
                 URL: https://issues.apache.org/jira/browse/LUCENE-901
             Project: Lucene - Java
          Issue Type: Bug
          Components: Search
            Reporter: Michael Busch
            Priority: Trivial

Currently DefaultSimilarity.queryNorm() returns Infinity if sumOfSquaredWeights=0.
This can result in a score of NaN (e. g. in TermScorer) if boost=0.0f.

A simple fix would be to return 1.0f in case zero is passed in.

See LUCENE-698 for discussions about this.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Permalink | Reply | 6 comments |
headers
Michael Busch (JIRA | 1 Jun 2007 06:18
Picon
Favicon

[jira] Commented: (LUCENE-898) contrib/javascript is not packaged into releases


    [
https://issues.apache.org/jira/browse/LUCENE-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500569
] 

Michael Busch commented on LUCENE-898:
--------------------------------------

> My vote is to remove the javascript contrib area entirely. 

+1. It also seems that this package is unmaintained. No files have
been changed since February 2005, when it was moved from the 
sandbox to contrib.

> contrib/javascript is not packaged into releases
> ------------------------------------------------
>
>                 Key: LUCENE-898
>                 URL: https://issues.apache.org/jira/browse/LUCENE-898
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Build
>            Reporter: Hoss Man
>            Priority: Trivial
>
> the contrib/javascript directory is (apparently) a collection of javascript utilities for lucene ..
but it has not build files or any mechanism to package it, so it is excluded form releases.

--

-- 
This message is automatically generated by JIRA.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane