> functionality. In some cases strings are compared with string literals
> using ==. I can give a list if anyone thinks he or she will have use for
> it.
This is a speed optimization. All Strings compared by this function were
"interned" before. This is done for e.g. all "field" names in Lucene.
Where is the patch, that fixes your problems. Your message did not have an
attachment!
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
_
From: Tzvika Barenholz [mailto:[EMAIL PROTECTED]
Sent: Monday, November 19, 2007 8:24 AM
To:
Hi Michael!
The patch is attached to my previous message (and this one too). It doesn't
actually fix an issue, so I don't see where to put it otherwise. Please
advise. *trying not to be difficult* :-)
T
On 11/18/07, Michael McCandless <[EMAIL PROTECTED]> wrote:
>
>
> Thank you! Yes please submi
Thank you! Yes please submit a patch and we can iterate from there.
Mike
"Tzvika Barenholz" <[EMAIL PROTECTED]> wrote:
> Hello good people of Lucene!
>
> I've been using Lucene for a long while, but have only recently had occasion
> to checkout the source code from the trunk and build it mysel
Hello good people of Lucene!
I've been using Lucene for a long while, but have only recently had occasion
to checkout the source code from the trunk and build it myself. When I did
so, I was alerted by my IDE (IDEA) of a large number of irregularities in
the code, some of them serious, most not. I
On Nov 18, 2007 6:07 AM, Michael McCandless <[EMAIL PROTECTED]> wrote:
>
> "Yonik Seeley" <[EMAIL PROTECTED]> wrote:
>
> > 1) If we are deprecating some methods like String termText(), how
> > about at the same time deprecating "String type"? If we want
> > lightweight per-token metadata for commu
Michael McCandless wrote:
>
> Exactly: DocumentsWriter writes the bytes immediately into the
> proxStream. You should only need to change addPosition: I think it
> can access these new [package protected] fields directly from the
> Token, instead of using the separate Payload object.
>
Cool, I'
"Michael Busch" <[EMAIL PROTECTED]> wrote:
> Michael McCandless wrote:
>
> >>
> >> class Token {
> >> byte[] payload;
> >> int payloadLength;
> >> void setPayload(byte[], int length)
> >> byte[] getPayload()
> >> int getPayloadLength()
> >> ...
> >> }
> >
> > +1
> >
> > Mike
Michael McCandless wrote:
>>
>> class Token {
>> byte[] payload;
>> int payloadLength;
>> void setPayload(byte[], int length)
>> byte[] getPayload()
>> int getPayloadLength()
>> ...
>> }
>
> +1
>
> Mike
>
Mike,
just to clarify: I had suggested this at the ApacheCon because
[
https://issues.apache.org/jira/browse/LUCENE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543383
]
Chuck Williams commented on LUCENE-1052:
I believe this needs to be a formula as a reasonable bound on the n
[
https://issues.apache.org/jira/browse/LUCENE-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543382
]
Michael McCandless commented on LUCENE-1057:
Patch looks good to me! Thanks Yonik.
> indexing doesn't
"Yonik Seeley" <[EMAIL PROTECTED]> wrote:
> On Nov 18, 2007 6:07 AM, Michael McCandless <[EMAIL PROTECTED]>
> wrote:
> > How about: if you are re-using your token, then whoever set the
> > payload, positionIncrement, etc, should always clear/reset it on the
> > next token?
>
> I considered this,
On Nov 18, 2007 6:07 AM, Michael McCandless <[EMAIL PROTECTED]> wrote:
> How about: if you are re-using your token, then whoever set the
> payload, positionIncrement, etc, should always clear/reset it on the
> next token?
I considered this, but it doesn't really seem practical since a filter
doesn
+1 for the signature changes and +1 for adding the field name.
-Grant
On Nov 18, 2007, at 6:07 AM, Michael McCandless wrote:
"Yonik Seeley" <[EMAIL PROTECTED]> wrote:
So I think we should change + finalize the payload API before Lucene
2.3 comes out.
Single biggest drawback about current p
[
https://issues.apache.org/jira/browse/LUCENE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543366
]
Michael McCandless commented on LUCENE-1052:
{quote}
I'd like to take it one step further to eliminate t
"Yonik Seeley" <[EMAIL PROTECTED]> wrote:
> So I think we should change + finalize the payload API before Lucene
> 2.3 comes out.
>
> Single biggest drawback about current payloads is that there isn't any
> explicit support for adding different types of payloads to the same
> token.
> I don't rea
"Yonik Seeley" <[EMAIL PROTECTED]> wrote:
> 1) If we are deprecating some methods like String termText(), how
> about at the same time deprecating "String type"? If we want
> lightweight per-token metadata for communication between filters, an
> int or a long used as a bitvector (32 or 64 indepe
17 matches
Mail list logo
