[jira] Commented: (LUCENE-552) NPE during mergeSegments

[ http://issues.apache.org/jira/browse/LUCENE-552?page=comments#action_12376656 ] Ole Kværnø commented on LUCENE-552: --- Occured once more. Further log details (SRC = rev 396455) ... [java] [GC 537735K->471821K(769088K), 0.0765670 secs] [java

Please review the Analyzer for Thai language

I've submited a ThaiAnalyzer for Lucene here http://issues.apache.org/jira/browse/LUCENE-503?page=all I want to contribute the code and have signed the CLA. Can anyone review the code? -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://ww

Re: GData, updateable IndexSearcher

If I'm following this correctly, it omits a related issue which is the need to periodically close and reopen the IndexWriter in order to flush its internal RAMDirectory, and similarly for the IndexReader used for delete. Is there any good solution to avoid these as well? My app has an IndexManage

[jira] Updated: (LUCENE-557) search vs explain - score discrepancies

[ http://issues.apache.org/jira/browse/LUCENE-557?page=all ] Hoss Man updated LUCENE-557: Attachment: LUCENE-557-modify-existing-tests.patch Phase one: stealthily modify (almost) all tests that use an IndexSearcher to use a new subclass which will check eve

[jira] Created: (LUCENE-557) search vs explain - score discrepancies

search vs explain - score discrepancies --- Key: LUCENE-557 URL: http://issues.apache.org/jira/browse/LUCENE-557 Project: Lucene - Java Type: Bug Components: Search Reporter: Hoss Man I'm on a mission to demonstrate (and

Re: (byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80)

--- Yonik Seeley <[EMAIL PROTECTED]> wrote: > On 4/26/06, Charlie <[EMAIL PROTECTED]> wrote: > >writeByte((byte)((i & 0x7f) | 0x80)); > >writeByte((byte)(i | 0x80)); > > Yes, these two lines are equivalent. > It's fairly likely that the JVM already does this > optimization for you though.

Re: GData, updateable IndexSearcher

jason rutherglen wrote: I was thinking you implied that you knew of someone who had customized their own, but it was a closed source solution. And if so then you would know how that project faired. I don't recall the details, but I know folks have discussed this previously, and probably even

Re: GData, updateable IndexSearcher

On 4/26/06, jason rutherglen <[EMAIL PROTECTED]> wrote: > As this would be used with Solr I wonder if there would be a good way to also > update the Solr caches. Other than re-executing queries that generated the results? Probably not. The nice thing about knowing exactly when the view of an inde

Re: GData, updateable IndexSearcher

This originated on the Solr mailing list. > That's the way Lucene changes. I was thinking you implied that you knew of someone who had customized their own, but it was a closed source solution. And if so then you would know how that project faired. I definitely sounds like an interesting pr

[jira] Closed: (LUCENE-497) update copyright (and licence) prior to release of 1.9

[ http://issues.apache.org/jira/browse/LUCENE-497?page=all ] Yonik Seeley closed LUCENE-497: --- Resolution: Invalid Closing. > update copyright (and licence) prior to release of 1.9 > -- > >

[jira] Commented: (LUCENE-497) update copyright (and licence) prior to release of 1.9

[ http://issues.apache.org/jira/browse/LUCENE-497?page=comments#action_12376538 ] Hoss Man commented on LUCENE-497: - This bug should be resolved as "INVALID" > update copyright (and licence) prior to release of 1.9 >

Re: Re[2]: (byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80)

On 4/26/06, Marvin Humphrey <[EMAIL PROTECTED]> wrote: > So the question is, does this assertion hold? > >(byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80) Yes. I tested just this out, and java5 -server reports a 15% performance boost for writeVInt alone, tested over numbers from 1 to 100.

Re: (byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80)

On 4/26/06, Charlie <[EMAIL PROTECTED]> wrote: >writeByte((byte)((i & 0x7f) | 0x80)); >writeByte((byte)(i | 0x80)); Yes, these two lines are equivalent. It's fairly likely that the JVM already does this optimization for you though... at least gcc -O already compiles to identical assembly f

Re: Re[2]: (byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80)

On Apr 26, 2006, at 10:21 AM, Charlie wrote: But I thought Method: public void writeVInt(int i) is not about UTF-8, it is about how to write an int in variable length. Is it included as a part of future unicode character writing? WriteVInt, and also WriteVLong, which contains the same code

Re: Re[2]: (byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80)

On 4/26/06, Charlie <[EMAIL PROTECTED]> wrote: > ok, thanks for your reply. > > But I thought > Method: public void writeVInt(int i) > is not about UTF-8, it is about how to write an int in variable length. Oh, sorry... wrong function. It was a similar optimization to things I had seen in the cha

Re[2]: (byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80)

ok, thanks for your reply. But I thought Method: public void writeVInt(int i) is not about UTF-8, it is about how to write an int in variable length. Is it included as a part of future unicode character writing? -- Best regards, Charlie --- >> I thought >> >> (byte)((i & 0x7f) | 0x80) == (

Re: boosting fields

karl wettin wrote: karl wettin wrote: This could lead me to believe I can use different boost for fields with the same name within one document. You can. The values are multiplied to produce the final boost value for the field. It's not really the same thing as I tried to describe thou

Re: (byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80)

On 4/26/06, Charlie <[EMAIL PROTECTED]> wrote: > I thought > > (byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80) > > As (byte) is able to truncate the last byte for us already, no need of > (& 0x7f). If so, we may change that line to > >writeByte((byte)(i | 0x80)); > > and may speed up a little b

(byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80)

Hello, In: public abstract class IndexOutput public void writeVInt(int i) writeByte((byte)((i & 0x7f) | 0x80)); I thought (byte)((i & 0x7f) | 0x80) == (byte)(i | 0x80) As (byte) is able to truncate the last byte for us already, no need of (& 0x7f). If so, we may change that line to

[jira] Created: (LUCENE-556) MatchAllDocsQuery, MultiSearcher and a custom HitCollector throwing exception

MatchAllDocsQuery, MultiSearcher and a custom HitCollector throwing exception - Key: LUCENE-556 URL: http://issues.apache.org/jira/browse/LUCENE-556 Project: Lucene - Java Type: Bug Compon

Re: Intro and simple feature add

Oops - I just realized you're maintaining a static map of these parameters in the Parmeter class. Should have looked more closely before writing - sorry 'bout that. Glad I at least got the intro correct. -j --- Joe R <[EMAIL PROTECTED]> wrote: > > I have a simple request that applies to or

Intro and simple feature add

I have a simple request that applies to org.apache.lucene.util.Parameter, but before I go suggesting things to add to Lucene, a quick introduction: I'm Joe, I'm working for a company that's using Lucene to build large-ish indexes of documents for clients who'd like to securely store their digital

Re: SRND query

On Apr 26, 2006, at 2:52 AM, Paul Elschot wrote: Iirc in the contrib area there is also an xml query parser that allows xml structured queries, but at the moment I don't know precisely where that is. -