Doron Cohen wrote:
http://issues.apache.org/jira/browse/LUCENE-738 updated fileformats.xml.
This shows correctly in
http://svn.apache.org/viewvc/lucene/java/trunk/src/site/src/documentation/content/xdocs/fileformats.xml?view=markup
but not reflected (2nd day now) in the "Main" site version
http:
Looks good now, thanks Michael.
Michael McCandless wrote:
> Doron Cohen wrote:
> > http://issues.apache.org/jira/browse/LUCENE-738 updated
fileformats.xml.
> > This shows correctly in
> > http://svn.apache.
>
org/viewvc/lucene/java/trunk/src/site/src/documentation/content/xdocs/fileformats.
> xml
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12458158 ]
Ning Li commented on LUCENE-565:
> Can the same thing happen with your patch (with a smaller window), or are
> deletes applied between writing the new segment and
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12458170 ]
Yonik Seeley commented on LUCENE-565:
-
> both inserts and deletes - are committed in the same transaction.
OK, cool. I agree that's the ideal default behavior
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12458174 ]
Yonik Seeley commented on LUCENE-565:
-
Minor question... in the places that you use Vector, is there a reason you
aren't using ArrayList?
And in methods that p
[
http://issues.apache.org/jira/browse/LUCENE-740?page=comments#action_12458201 ]
Steven Parkes commented on LUCENE-740:
--
I'm kind of wondering about the snowball licensing, so I'm intrigued by Yonik's
comment. Cleanup is necessary?
Did th
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12458205 ]
Ning Li commented on LUCENE-565:
> Minor question... in the places that you use Vector, is there a reason you
> aren't using ArrayList?
> And in methods that pass
[
http://issues.apache.org/jira/browse/LUCENE-740?page=comments#action_12458209 ]
Doug Cutting commented on LUCENE-740:
-
This is a good question. We redistribute stuff generated from Snowball
sources, not the original files. Does this cons
I just saw the following new Lucene application announced:
http://omnifind.ibm.yahoo.net/productinfo.php
While I work for Yahoo!, I know nothing about Yahoo!'s involvement in
this except for what I've just read in the press. Were any of the IBM
folks on this list involved? If so, congratulatio
The primary folks on the Lucene side are Michael Busch and Andreas
Neumann. Certainly other folks at IBM have contributed significant
pieces (though notable NOT me) but Michael and Andreas did most of the
heavy lifting.
I'll leave them to take credit for their work.
--
Incorrect error message in AnalyzingQueryParser.getPrefixQuery
--
Key: LUCENE-746
URL: http://issues.apache.org/jira/browse/LUCENE-746
Project: Lucene - Java
Issue Type: Improvement
[ http://issues.apache.org/jira/browse/LUCENE-746?page=all ]
Ronnie Kolehmainen updated LUCENE-746:
--
Attachment: AnalyzingQueryParser.getPrefixQuery.patch
Patch for current trunk.
> Incorrect error message in AnalyzingQueryParser.getPrefixQuery
> -
Hello all,
two weeks ago I met the DB4O CEO at the DB4O roadshow in Berlin. We
talked about gdata, lucene and the license nightmare. Two days later I
got an email that db4o will release a third license to allow projects
like lucene to closely-distribute the db4o binaries and source. I did
receive
What are the licensing terms?
-Brian
On Dec 13, 2006, at 11:31 AM, Simon Willnauer wrote:
Hello all,
two weeks ago I met the DB4O CEO at the DB4O roadshow in Berlin. We
talked about gdata, lucene and the license nightmare. Two days later I
got an email that db4o will release a third license t
There your go:
http://www.db4o.com/about/company/legalpolicies/docl.aspx
thanks simon
On 12/13/06, Brian McCallister <[EMAIL PROTECTED]> wrote:
What are the licensing terms?
-Brian
On Dec 13, 2006, at 11:31 AM, Simon Willnauer wrote:
> Hello all,
>
> two weeks ago I met the DB4O CEO at the D
[
http://issues.apache.org/jira/browse/LUCENE-436?page=comments#action_12458264 ]
Otis Gospodnetic commented on LUCENE-436:
-
4 months later, I think I see the same problem here.
I'm using JDK 1.6 (I saw the same problem under 1.5.0_0(8,9,
Probably best to go to legal-discuss. I think the "non-transferable"
restriction in section 2 will be an issue.
http://people.apache.org/~cliffs/3party.html
Dan.
Simon Willnauer wrote:
There your go:
http://www.db4o.com/about/company/legalpolicies/docl.aspx
thanks simon
On 12/13/06, Brian M
Hi,
I'm looking at Robert Engels' patches in
http://issues.apache.org/jira/browse/LUCENE-436 and looking at TermInfosReader.
I think I understand why there is ThreadLocal there in the first place - to act
as a per-thread cache for the expensive to compute SegmentTermEnum yes?
But why is the
[
http://issues.apache.org/jira/browse/LUCENE-436?page=comments#action_12458292 ]
robert engels commented on LUCENE-436:
--
I would doubt the ThreadLocal "issue" that was in 1.4, changed in 1.5, would be
reintroduced in 1.6.
I do not use Luc
Aaaah, I think I get it.
TermIndexReader can be shared by multiple threads.
Each thread will need access to SegmentTermEnum inside the TIR, but since each
of them will search, scan, and seek to a different location, each threads needs
its own copy/clone of the original SegmentTermEnum.
ThreadLoc
[ http://issues.apache.org/jira/browse/LUCENE-681?page=all ]
Otis Gospodnetic resolved LUCENE-681.
-
Resolution: Won't Fix
I think Jed's right. Plus, calling new Field(), which would now be possible,
would give us without the actual information abou
That is correct.
On Dec 13, 2006, at 4:48 PM, Otis Gospodnetic wrote:
Aaaah, I think I get it.
TermIndexReader can be shared by multiple threads.
Each thread will need access to SegmentTermEnum inside the TIR, but
since each of them will search, scan, and seek to a different
location, each
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
clover.setup:
clover.info:
[echo]
[ec
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
Hi folks,
Over at Lucene.Net, I have run into a NUnit test which is failing with
Lucene.Net (C#) but is passing with Lucene (Java). The two tests that fail
are: TestInternationalMultiSearcherSort and TestInternationalSort
After several hours of investigation, I narrowed the problem to what I
bel
Thanks for the congratulations, Doug!
The credits for the Lucene side of the work really go to Michael, and
to the entire Lucene group - this community sometimes came up with
patches faster than we could ask for them.
To answer your question: How is Lucene used in this product?
- Needless to men
Simon: it looks like you removed the contrib/gdata-server/src/java/
directory and added several new directories -- but the
invoke-javadoc macro in the main build.xml file still expects it to be
there.
I assume just switching to contrib/gdata-server/src/core/java/ would solve
the immediate problem
Surprising but it looks to me like a bug in Java's collation rules for
en-US. According to
http://developer.mimer.com/collations/charts/UCA_latin.htm, \u00D8
(which is Latin Capital Letter O With Stroke) should be before U,
implying -1 is the correct result. Java is returning 1 for all
strengths
29 matches
Mail list logo
