[ http://issues.apache.org/jira/browse/LUCENE-569?page=all ]
paul.elschot updated LUCENE-569:
Attachment: SpanNearQuery20060622.patch
The patch to SpanNearQuery at the other issue still uses NearSpans.
Using the patch attached here, NearSpans is not used
DM Smith wrote:
Generally open source projects have a policy to change as little of
the file
as possible, only changing what is necessary.
Hmmm. Necessary by what criterion? Necessary to make, say, Lucene
exploit the new interator constructs to avoid run-time type-checking?
Necessary to
It doesn't subclass Field b/c I didn't want to deal with the
constructors (Field does not have an empty constructor) and everything
and I didn't think LazyField should be exposed publicly at the API
level. It is not something you want people instantiating ever b/c then
they will try to add the
On Jun 22, 2006, at 4:31 AM, John Haxby wrote:
DM Smith wrote:
Generally open source projects have a policy to change as little
of the file
as possible, only changing what is necessary.
Hmmm. Necessary by what criterion? Necessary to make, say,
Lucene exploit the new interator construc
DM Smith wrote:
I simply meant that the change that is being made should be done in
such a way that one applying the patch can readily see what is being
changed. The most common case of unnecessary change is that of
whitespace. Changing indentation, changing the placement of curly
braces, reor
TestConstantScoreRangeQuery does not compile with ecj
-
Key: LUCENE-611
URL: http://issues.apache.org/jira/browse/LUCENE-611
Project: Lucene - Java
Type: Bug
Components: Search
Versions: 2.0.0
Environm
[ http://issues.apache.org/jira/browse/LUCENE-611?page=all ]
DM Smith updated LUCENE-611:
Attachment: TestConstantScoreRangeQueryPatch.txt
> TestConstantScoreRangeQuery does not compile with ecj
> -
>
>
[
http://issues.apache.org/jira/browse/LUCENE-611?page=comments#action_12417311 ]
Yonik Seeley commented on LUCENE-611:
-
Are there any other ecj related compile issues?
I'd rather fix all lucene-core related ones in a single JIRA isse/patch.
> TestConst
[
http://issues.apache.org/jira/browse/LUCENE-415?page=comments#action_12417314 ]
Volodymyr Bychkoviak commented on LUCENE-415:
-
Yonik,
is this right code?
if (file.length() == 0) {
// This can happen if there was a previous crash / un
[
http://issues.apache.org/jira/browse/LUCENE-415?page=comments#action_12417315 ]
Volodymyr Bychkoviak commented on LUCENE-415:
-
moreover
FSDirectory.createDirectory() which calls FSIndexOutput constructor already has
a check for file existance
[
http://issues.apache.org/jira/browse/LUCENE-415?page=comments#action_12417317 ]
Yonik Seeley commented on LUCENE-415:
-
Thanks for catching that Volodymyr.
I did a further search of the code, and FSIndexOutput is only instantiated in
one place: create
On 6/22/06, John Haxby <[EMAIL PROTECTED]> wrote:
DM Smith wrote:
> I simply meant that the change that is being made should be done in
> such a way that one applying the patch can readily see what is being
> changed. The most common case of unnecessary change is that of
> whitespace. Changing i
[
http://issues.apache.org/jira/browse/LUCENE-611?page=comments#action_12417319 ]
DM Smith commented on LUCENE-611:
-
I have checked all of trunk/src/{java,demo,test} but not gcj. I have not
checked any of contrib yet.
Give me a bit and I'll check these out
Lucene Searcher failing if the keyword is "a*" or "b*"
---
Key: LUCENE-612
URL: http://issues.apache.org/jira/browse/LUCENE-612
Project: Lucene - Java
Type: Bug
Components: Search
Reporter: Dhananjay Kumar
[
http://issues.apache.org/jira/browse/LUCENE-611?page=comments#action_12417333 ]
DM Smith commented on LUCENE-611:
-
Other than gcj, everything compiles with ecj without error (given the attached
patch).
The gcj fails on an import which has nothing to do wi
[ http://issues.apache.org/jira/browse/LUCENE-612?page=all ]
Otis Gospodnetic resolved LUCENE-612:
-
Resolution: Invalid
See the FAQ (e.g.
http://wiki.apache.org/jakarta-lucene/LuceneFAQ#head-06fafb5d19e786a50fb3dfb8821a6af9f37aa831
) and java-
[ http://issues.apache.org/jira/browse/LUCENE-611?page=all ]
Yonik Seeley resolved LUCENE-611:
-
Fix Version: 2.0.1
Resolution: Fixed
Assign To: Yonik Seeley
Thanks, I just commited this.
> TestConstantScoreRangeQuery does not compile wit
DM Smith wrote:
In an earlier note, I suggested that there needs to be guidance as to how
Java 5 constructs are to be incorporated into code, contrib and core.
(Sooner or later, core will change to Java 5) Or does anything go?
Once we decide to accept Java 5 code, we should of course encourage
On 6/22/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
DM Smith wrote:
> In an earlier note, I suggested that there needs to be guidance as to
how
> Java 5 constructs are to be incorporated into code, contrib and core.
> (Sooner or later, core will change to Java 5) Or does anything go?
Once we de
On 6/22/06, DM Smith <[EMAIL PROTECTED]> wrote:
On 6/22/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
>
> DM Smith wrote:
> > In an earlier note, I suggested that there needs to be guidance as to
> how
> > Java 5 constructs are to be incorporated into code, contrib and core.
> > (Sooner or later, c
I agree. This is probably the first compelling argument that I would
agree with the use of 1.5. IIRC, Concurrent utils were available for
the 1.4 available at
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
before it was accepted into official 1.5 util package. I
There are some big performance differences between the J2SE 5.0 concurrent
package, and previous "outside" the JRE packages - the 1.5 JVM has some
internal primitives that make the concurrent classes far more efficient.
-Original Message-
From: Ray Tsang [mailto:[EMAIL PROTECTED]
Sent: Th
[ http://issues.apache.org/jira/browse/LUCENE-608?page=all ]
Daniel Naber resolved LUCENE-608:
-
Resolution: Fixed
The patch has been committed.
> deprecate Document.fields(), add getFields()
>
>
>
DM Smith wrote:
One of the things I liked about 2.0 was that 1.9 was a bridge to it from
1.4.3 via deprecations. It made migration fairly straightforward. I would
like to see this going forward to 2.1. If so there needs to be some thought
to how and whether the existing API will be deprecated in
: If 2.1 will break API compatibility then it should be called 3.0. Major
: release numbers are all about API compatibility. If code works with
: Lucene X.Y, then it should also compile against Lucene X.Y+1, but it may
: not work with Lucene X+1.Z.
: JVM version is orthogonal to this, no?
One
On Jun 22, 2006, at 5:46 PM, Doug Cutting wrote:
DM Smith wrote:
One of the things I liked about 2.0 was that 1.9 was a bridge to
it from
1.4.3 via deprecations. It made migration fairly straightforward.
I would
like to see this going forward to 2.1. If so there needs to be
some thought
t
On 6/22/06, DM Smith <[EMAIL PROTECTED]> wrote:
I think the place where it will really come into play will be new code.
Absolutely...
I wrote some new code recently that uses Java 1.5 (ArrayQueue and
BufferedTokenFilter) that is meant to make it easier to write
TokenFilters that need state (loo
27 matches
Mail list logo
