[
http://issues.apache.org/jira/browse/LUCENE-528?page=comments#action_12443978 ]
Ning Li commented on LUCENE-528:
I'll submit a patch next week.
> Optimization for IndexWriter.addIndexes()
> -
>
>
[
http://issues.apache.org/jira/browse/LUCENE-673?page=comments#action_12443975 ]
Marvin Humphrey commented on LUCENE-673:
It seems that NFS doesn't support delete-upon-last-close semantics. That means
that an IndexWriter can delete fil
[
http://issues.apache.org/jira/browse/LUCENE-657?page=comments#action_12443952 ]
Steven Parkes commented on LUCENE-657:
--
Good point on the members.
There are public getter methods and the member are set from ctor, so the only
reason for m
[
http://issues.apache.org/jira/browse/LUCENE-657?page=comments#action_12443946 ]
Yonik Seeley commented on LUCENE-657:
-
Making the class non-final is fine.
As far as changing members to protected, I'm not opposed to opening something
up a
[ http://issues.apache.org/jira/browse/LUCENE-657?page=all ]
Steven Parkes updated LUCENE-657:
-
Lucene Fields: [Patch Available] (was: [New, Patch Available])
> FuzzyQuery should not be final
> --
>
> Key: LUC
[
http://issues.apache.org/jira/browse/LUCENE-528?page=comments#action_12443940 ]
Yonik Seeley commented on LUCENE-528:
-
> Algorithm looks good?
Yep, looks good.
A possible optimization *far* down the road for segments that need copying
c
Ah, I was looking for an exact match. I'm not sure why that overlap is there.
Otis
- Original Message
From: Steven Rowe <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Friday, October 20, 2006 2:09:21 PM
Subject: Re: [jira] Updated: (LUCENE-692) Hangul Jamo (Korean) support in
[
http://issues.apache.org/jira/browse/LUCENE-489?page=comments#action_12443937 ]
Steven Parkes commented on LUCENE-489:
--
Ah. I get it.
Yeah, it is ready to be committed (at least I think it is). In terms of the
"patch available" flag (whi
I did run the java/trunk/buiild.xml file with ant package as I guess
gump did as well. We had similar problems a couple of weeks ago as the
java doc could not be generated with java version < 1.5 but there was
a quick ant fix for that.
I will take some time to figure out a better solution or clean
Otis Gospodnetic wrote:
> I see it only in 1 place (Korean):
U+1100-U+11FF is included in the U+0100-U+1FFF range in LETTER:
| < #LETTER: // unicode letters
[
"\u0041"-"\u005a",
"\u0061"-"\u007a",
"\u00c0"-"\u00d6",
"\u00d8"-"\u00f6",
"\u00f8"-"\u00f
Can you post what doesn't work? Are you getting exceptions or errors
when running or are you not able to compile, etc?
Have you looked at http://lucene.apache.org/java/docs/scoring.html ?
(Feedback on the documentation would be useful, too, esp. in the form
of a patch: https://issues.apac
I see it only in 1 place (Korean):
$ grep 11ff src/java/org/apache/lucene/analysis/standard/StandardTokenizer.jj
"\u1100"-"\u11ff" // Hangul Jamo
Maybe I'm not seeing something...
Otis
- Original Message
From: Steven Rowe <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
S
[ http://issues.apache.org/jira/browse/LUCENE-692?page=all ]
Grant Ingersoll resolved LUCENE-692.
Lucene Fields: (was: [New, Patch Available])
Resolution: Duplicate
Duplicate of https://issues.apache.org/jira/browse/LUCENE-478
> Hangul Jamo
[
http://issues.apache.org/jira/browse/LUCENE-528?page=comments#action_12443911 ]
Ning Li commented on LUCENE-528:
> I think you need to ensure that no segments from the source index "S" remain
> after the call, right?
Correct. And thanks!
So
Hi,
On Fri, 2006-10-20 at 13:22 -0400, Steven Rowe wrote:
> This has already been addressed by a patch committed by Otis to fix the
> following issue (in August 2006, after the 2.0.0 release):
>
>https://issues.apache.org/jira/browse/LUCENE-478
Oops! I only searched the open issues looking
Joe Shaw (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/LUCENE-692?page=all ]
[snip]
> One of our users reported their inability to search some Korean
> strings. This is because the Hangul Jamo Unicode block is not
> included in the StandardTokenizer.jj file.
> I'm attaching a patch w
[
http://issues.apache.org/jira/browse/LUCENE-489?page=comments#action_12443893 ]
Otis Gospodnetic commented on LUCENE-489:
-
Ooops, sorry, I thought it was ready to be committed. Can you commit? Take it
back, all yours! :)
> Allow QP
[ http://issues.apache.org/jira/browse/LUCENE-692?page=all ]
Joe Shaw updated LUCENE-692:
Attachment: lucene-hangul-jamo.patch
Patch to StandardTokenizer.jj which fixes this.
> Hangul Jamo (Korean) support in StandardTokenizer.jj
> -
Hangul Jamo (Korean) support in StandardTokenizer.jj
Key: LUCENE-692
URL: http://issues.apache.org/jira/browse/LUCENE-692
Project: Lucene - Java
Issue Type: Improvement
Component
[
http://issues.apache.org/jira/browse/LUCENE-489?page=comments#action_12443888 ]
Steven Parkes commented on LUCENE-489:
--
Uhh ... can I ask why the assignee change? I shouldn't work on this anymore?
> Allow QP subclasses to support Wildcard
[
http://issues.apache.org/jira/browse/LUCENE-689?page=comments#action_12443885 ]
Otis Gospodnetic commented on LUCENE-689:
-
I'd personally really want to see how come that field is null to begin with.
If possible, could you try to debu
[
http://issues.apache.org/jira/browse/LUCENE-667?page=comments#action_12443886 ]
Otis Gospodnetic commented on LUCENE-667:
-
Yes, but people may still play with them (e.g. to test things out quickly) and
may not be familiar with the buil
[ http://issues.apache.org/jira/browse/LUCENE-489?page=all ]
Otis Gospodnetic reassigned LUCENE-489:
---
Assignee: Otis Gospodnetic (was: Steven Parkes)
> Allow QP subclasses to support Wildcard Queries with leading "*"
>
[
http://issues.apache.org/jira/browse/LUCENE-667?page=comments#action_12443883 ]
Yonik Seeley commented on LUCENE-667:
-
The first line of these generated files say that they are generated files
though.
> javacc skeleton files not regenerat
[
http://issues.apache.org/jira/browse/LUCENE-667?page=comments#action_12443881 ]
Otis Gospodnetic commented on LUCENE-667:
-
I'm okay with this, although this might one day piss somebody off - imagine
making manual changes, running the j
[
http://issues.apache.org/jira/browse/LUCENE-667?page=comments#action_12443864 ]
Yonik Seeley commented on LUCENE-667:
-
The removed deprecations were part of the lucene-wide sweep to remove all
deprecated methods going from Lucene 1.9 to 2.
[
http://issues.apache.org/jira/browse/LUCENE-489?page=comments#action_12443858 ]
Steven Parkes commented on LUCENE-489:
--
I guess because I am uncomfortable manually modifying automatically generated
code. If there's a compelling reason for
I will look after this as soon as I get to my sources!
best regards simon
On 10/20/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contac
+1
Could we add a more generic signature to the unsubscribe signature on
the User mailing list, as well? Something like:
-
Please let us know what is important to you and vote on Lucene
issues at [URL]
To unsubscribe, e-mai
[
http://issues.apache.org/jira/browse/LUCENE-528?page=comments#action_12443841 ]
Yonik Seeley commented on LUCENE-528:
-
I think you need to ensure that no segments from the source index "S" remain
after the call, right?
> Optimization for
[
http://issues.apache.org/jira/browse/LUCENE-689?page=comments#action_12443776 ]
Michael Goddard commented on LUCENE-689:
Otis, you have an excellent point. At the time I encountered this error, I was
in a hurry to get something shippe
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project lucene-java has an issue affecting its community integration.
This issue affects
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project lucene-java has an issue affecting its community integration.
This issue affects
[
http://issues.apache.org/jira/browse/LUCENE-662?page=comments#action_12443766 ]
Nicolas Lalevée commented on LUCENE-662:
I just realized reading the recent discussing on lucene-dev (LazyField use of
IndexInput not thread safe) that the
Hi Bob,
If you happen to have this as a patch, or if you can make one, could you please
attach it to http://issues.apache.org/jira/browse/LUCENE-691 ?
Thanks,
Otis
- Original Message
From: Bob Carpenter <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Tuesday, June 13, 2006 3:1
Bob Carpenter's FuzzyQuery refactoring
--
Key: LUCENE-691
URL: http://issues.apache.org/jira/browse/LUCENE-691
Project: Lucene - Java
Issue Type: Improvement
Components: Search
Report
[ http://issues.apache.org/jira/browse/LUCENE-691?page=all ]
Otis Gospodnetic updated LUCENE-691:
Summary: Bob Carpenter's FuzzyTermEnum refactoring (was: Bob Carpenter's
FuzzyQuery refactoring)
> Bob Carpenter's FuzzyTermEnum refactoring
> ---
Hello,
I'm trying to implement my own scoring algorithm with Lucene but I don't get
any results.
Lucene documentation explains how to implement new scoring, modifying Query,
Weight and Scorer classes. I have tried this but doesn't work
This is the BM25 Scorer formule:
log((N-f+0.5)/(f+0
Everyone's busy, so I think what's needed is a reminder that 1) voting is
possible and 2) voting helps prioritize commits.
Is it possible to change the format/template of outgoing email when a new issue
is created?
If so, would it be possible to add a sentence about voting for issues to it?
Per
After fixing to preserve current merge policy, improvement became smaller
and inconsistent, not worth to justify such change. So I am removing this
proposal.
Thanks for all the comments on this.
- Doron
-
To unsubscribe, e-mail:
[
http://issues.apache.org/jira/browse/LUCENE-689?page=comments#action_12443726 ]
Otis Gospodnetic commented on LUCENE-689:
-
Hm, weird. l peeked at SpanOrQuery.java and it looks like the private field
instance var should be set in the c
[
http://issues.apache.org/jira/browse/LUCENE-489?page=comments#action_12443724 ]
Otis Gospodnetic commented on LUCENE-489:
-
Steven: this patch looks good to me. Why not (manually) remove those 2
deprecated methods, getColumn and getLin
[
http://issues.apache.org/jira/browse/LUCENE-528?page=comments#action_12443723 ]
Ning Li commented on LUCENE-528:
We want a robust algorithm for the version of addIndexes() which
does not call optimize().
The robustness can be expressed as the
43 matches
Mail list logo
