[
https://issues.apache.org/jira/browse/LUCENE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754486#action_12754486
]
Hoss Man commented on LUCENE-1897:
--
bq. If the README said, you will find this jar at /lu
[
https://issues.apache.org/jira/browse/LUCENE-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754470#action_12754470
]
Mark Miller edited comment on LUCENE-1908 at 9/11/09 10:37 PM:
-
[
https://issues.apache.org/jira/browse/LUCENE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754480#action_12754480
]
Mark Miller edited comment on LUCENE-1897 at 9/11/09 10:05 PM:
-
[
https://issues.apache.org/jira/browse/LUCENE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754480#action_12754480
]
Mark Miller edited comment on LUCENE-1897 at 9/11/09 10:04 PM:
-
[
https://issues.apache.org/jira/browse/LUCENE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754480#action_12754480
]
Mark Miller commented on LUCENE-1897:
-
I guess.
bq. if we had a refrence to a jar fil
: Subject: NumericRange Field and LuceneUtils?
: References: <9ac0c6aa090932s69804fa5vbf5590ea6181e...@mail.gmail.com>
: In-Reply-To: <9ac0c6aa090932s69804fa5vbf5590ea6181e...@mail.gmail.com>
http://people.apache.org/~hossman/#threadhijack
Thread Hijacking on Mailing Lists
When starting
Michael McCandless wrote:
> Thanks Mark! -- comments below:
>
> On Fri, Sep 11, 2009 at 3:34 PM, Mark Miller wrote:
>
>
>> I'd have to dig in to be of much help. Hard to remember this stuff.
>>
>> 0:a 1:a 1:b 2:c 2:d 3:e 3:a 4:f 4:g 5:h 5:i 6:j 6:a 7:b 7:k 8:k
>>
>> span 0 to 8
>> span 1 to 8
[
https://issues.apache.org/jira/browse/LUCENE-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754470#action_12754470
]
Mark Miller commented on LUCENE-1908:
-
Looks great!
bq. Document Euclidean norm |V(d)
[
https://issues.apache.org/jira/browse/LUCENE-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754471#action_12754471
]
Shai Erera commented on LUCENE-1908:
This looks great ! Really helpful. Few comments:
[
https://issues.apache.org/jira/browse/LUCENE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754379#action_12754379
]
Hoss Man commented on LUCENE-1897:
--
Honestly: i don't think this is a bug. javadocs are
[
https://issues.apache.org/jira/browse/LUCENE-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754373#action_12754373
]
Doron Cohen commented on LUCENE-1908:
-
Suggested Similarity javadoc can be reiewed her
Just FYI I recall a fair amount of discussion on SpanNear:
http://www.lucidimagination.com/search/s:email/l:dev?q=SpanNearQuery
http://www.lucidimagination.com/search/?q=NearSpansOrdered#/s:email/l:dev
See also http://issues.apache.org/jira/browse/LUCENE-1001
I remember being very confused by Ne
On Fri, Sep 11, 2009 at 4:45 PM, Uwe Schindler wrote:
> By the way: This is documented:
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/javadoc/core/org/apac
> he/lucene/document/NumericField.html
>
> NOTE: This class is only used during indexing. When retrieving the stored
> field value
By the way: This is documented:
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/javadoc/core/org/apac
he/lucene/document/NumericField.html
NOTE: This class is only used during indexing. When retrieving the stored
field value from a Document instance after search, you will get a
conventional
Hallo Daniel,
I am not really sure what you are talking about (what is LuceneUtils?).
To your question about NumericField: NumericField is only used for indexing.
If you also store the field to retrieve it from the index e.g. with search
results, NumericField creates a stored Field containing the
Thanks Mark! -- comments below:
On Fri, Sep 11, 2009 at 3:34 PM, Mark Miller wrote:
> I'd have to dig in to be of much help. Hard to remember this stuff.
>
> 0:a 1:a 1:b 2:c 2:d 3:e 3:a 4:f 4:g 5:h 5:i 6:j 6:a 7:b 7:k 8:k
>
> span 0 to 8
> span 1 to 8
> span 3 to 8
> span 6 to 8
>
> I think
[
https://issues.apache.org/jira/browse/LUCENE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754302#action_12754302
]
Doron Cohen commented on LUCENE-1896:
-
hi Mark, I moved the work on the Similarity jav
[
https://issues.apache.org/jira/browse/LUCENE-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen updated LUCENE-1908:
Attachment: LUCENE-1908.patch
Attached patch adds explanations on how current scoring function is
Similarity javadocs for scoring function to relate more tightly to scoring
models in effect
---
Key: LUCENE-1908
URL: https://issues.apache.org/jira/browse/LUCENE-1908
I'd have to dig in to be of much help. Hard to remember this stuff.
0:a 1:a 1:b 2:c 2:d 3:e 3:a 4:f 4:g 5:h 5:i 6:j 6:a 7:b 7:k 8:k
span 0 to 8
span 1 to 8
span 3 to 8
span 6 to 8
I think those are the right 4. You start on the left and work right. Spans
always start after
the last one star
Sounds right... but this LuceneUtils class isn't part of Lucene is it?
-Yonik
http://www.lucidimagination.com
On Fri, Sep 11, 2009 at 3:01 PM, Daniel Shane wrote:
> Is it normal that LuceneUtils.getString(Document document, String fieldName)
> uses document.getField() in the background?
>
> If
Is it normal that LuceneUtils.getString(Document document, String
fieldName) uses document.getField() in the background?
If, for example, you indexed something using the new NumericRange field,
then you will get a class cast exception in there.
Would it not be better to call getFieldable() in
Under LUCENE-1458, I'm hitting a curious test failure in
TestPositionsIncrement.testPayloadsPos0. The failure happens because
the codec I'm testing (pulsing codec) allows you to retrieve the same
payload more than once if the term was pulsed (inlined into terms
dict), whereas w/ trunk you can only
Hi,
You should post this question on lucene java-user list,
that would be the correct place, for this question.
theDude_2 wrote:
http://lucene.apache.org/java/2_4_0/api/org/apache/lucene/queryParser/MultiFieldQueryParser.html#parse(java.lang.String[],
java.lang.String[], org.apache.lucene.analy
[
https://issues.apache.org/jira/browse/LUCENE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754250#action_12754250
]
Michael McCandless commented on LUCENE-1458:
{quote}
bq. Changed terms to be s
: Could a git branch make things easier for mega-features like this?
why not just start a subversion branch?
:
: > Further steps towards flexible indexing
: > ---
: >
: > Key: LUCENE-1458
: > URL: https://issues.apache.org/jira
[
https://issues.apache.org/jira/browse/LUCENE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754200#action_12754200
]
Yonik Seeley commented on LUCENE-1458:
--
bq. Changed terms to be stored in RAM as byte
I think this one should be fixed now? Have you tested?
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik
> Seeley
> Sent: Friday, Septemb
On Fri, Sep 11, 2009 at 8:22 AM, Uwe Schindler wrote:
> I hope, this time we find possible traps/errors
> *before* releasing RC4
Yeah, there was an older Solr issue open for this too:
https://issues.apache.org/jira/browse/SOLR-1404
Just didn't come across it and recognize it as a Lucene bug fast
I for myself feel comfortable.
It would be good to drop the JARs into Solr before releasing. I did it and
it seemed to work, but I only ran the tests, no real server.
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Mes
IMHO, if I'm forced to write a by-pass filter to re-use a filter instead
of copy/pasting it, I think we are getting way off the Decorator
Pattern. Its not simple anymore. I bet you have 9 chances out of 10 that
a dev. will copy/paste that code before writing a by-pass filter.
Extending the fun
Lucene has always had way too much use of final for my taste. I have often
had to resort of chicanery to get around this.
In many cases, there wasn't even an alternative abstract class. Writing
test cases involving IndexWriters was a case that sticks in my memory.
On Fri, Sep 11, 2009 at 7:13 A
Just let me know when you feel comfortable and I'll start the tests and
transfer.
- Mark
Uwe Schindler wrote:
> I am finished win LUCENE-1906!
>
> I also opened an issue for Solr: Maybe there are changes needed for
> correctOffset after 2.9RC4. I hope, this time we find possible traps/errors
> *b
I think thats true - but its also interesting to note: LowerCaseFilter
has been final since it was put into svn in 01.
--
- Mark
http://www.lucidimagination.com
Ted Dunning wrote:
>
> Copy/paste. Clearly Uwe and others were worried that users wouldn't
> be able to extend these classes compat
Copy/paste. Clearly Uwe and others were worried that users wouldn't be able
to extend these classes compatibly.
My own opinion is that this causes worse problems with back compatibility
because people wind up copying code instead of calling it. You may be able
to extend an abstract class to mini
[
https://issues.apache.org/jira/browse/LUCENE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1458:
---
Attachment: LUCENE-1458.tar.bz2
LUCENE-1458-back-compat.patch
New pa
> The only thing I can do is add a filter before the LowerCaseFilter that
> would pass all the non-word tokens to the next filter, but it seems really
> complicated for a case where a simple extend would do the job.
This is the way to go!
Uwe
With the current API of TokenStream (incrementToken) I really do not see
how I could do the following scenario with the Decorator Pattern :
I have a case where I would like to execute the LowerCaseFilter only if
the token is of type "word". I do not want to execute the
LowerCaseFilter if the t
I am finished win LUCENE-1906!
I also opened an issue for Solr: Maybe there are changes needed for
correctOffset after 2.9RC4. I hope, this time we find possible traps/errors
*before* releasing RC4.
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@t
[
https://issues.apache.org/jira/browse/LUCENE-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754105#action_12754105
]
Uwe Schindler commented on LUCENE-1906:
---
I created an issue (SOLR-1423). Maybe there
[
https://issues.apache.org/jira/browse/LUCENE-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754101#action_12754101
]
Uwe Schindler commented on LUCENE-1906:
---
It seems that Solr compiles with the new JA
[
https://issues.apache.org/jira/browse/LUCENE-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754100#action_12754100
]
Koji Sekiguchi commented on LUCENE-1906:
bq. There may be some changes needed in S
>> It seems like something higher up must accept two rects and OR them together
>> during the searching?
That's the way I've done it before. It's like the old "Asteroids" arcade game
where as the ship drifts off-screen stage right it is simultaneously emerging
back from stage-left.
- Or
I do not know, how this could affect Solr, but it could be the case.
Currently most Tokenizers do not use CharStreams at all. After committing
LUCENE-1906, I think there is also some additional work in Solr's custom
Tokenizers needed (changed the correctOffset method).
-
Uwe Schindler
H.-H.-Me
[
https://issues.apache.org/jira/browse/LUCENE-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754062#action_12754062
]
Michael McCandless commented on LUCENE-1781:
Bill, could you please post a sin
45 matches
Mail list logo
