[
http://issues.apache.org/jira/browse/LUCENE-740?page=comments#action_12457619 ]
Doron Cohen commented on LUCENE-740:
Two comments:
1. Testing: There's only limited testing in Lucene's contrib for these stemmers
- we could probably add a s
[
http://issues.apache.org/jira/browse/LUCENE-702?page=comments#action_12457691 ]
Michael McCandless commented on LUCENE-702:
---
Thanks for the review Ning!
> 1 In the two rollbacks in mergeSegments (where inTransaction is
> false), the
[ http://issues.apache.org/jira/browse/LUCENE-702?page=all ]
Michael McCandless updated LUCENE-702:
--
Attachment: LUCENE-702.take2.patch
OK I attached a new patch with changes to only javadocs & unit tests:
* Fixed the disk full unit test to use "
[
http://issues.apache.org/jira/browse/LUCENE-662?page=comments#action_12457713 ]
Grant Ingersoll commented on LUCENE-662:
Hi Nicolas,
Have you run any benchmarks on this? Once I finish up some documentation
stuff, my plan is to start
Can anyone recreate this:
With JDK 1.4:
I run ant javadocs and I get no output whatsoever in build/docs/api
It says 3 errors and 3 warnings. Using verbose=true doesn't show
anything. Adding failonerror=true causes Build Failed, but it
doesn't give a reason. It seems like it gets through f
Grant Ingersoll wrote:
Can anyone recreate this:
With JDK 1.4:
I run ant javadocs and I get no output whatsoever in build/docs/api
I see this as well, with Sun JDK 1.4.2 on Windows, ant 1.6.5. If I move
that one source
(src/java/org/apache/lucene/search/spans/NearSpansOrdered.java)
out of t
[
http://issues.apache.org/jira/browse/LUCENE-662?page=comments#action_12457757 ]
Nicolas Lalevée commented on LUCENE-662:
Not at all.
In fact we don't use a lucene modified with my patch in our system. I only
start working with lucene
OK, if I put in source="1.4" then it works, but is that going to
break the GData stuff?
On Dec 12, 2006, at 9:38 AM, Michael McCandless wrote:
Grant Ingersoll wrote:
Can anyone recreate this:
With JDK 1.4:
I run ant javadocs and I get no output whatsoever in build/docs/api
I see this as w
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457758 ]
Yonik Seeley commented on LUCENE-565:
-
> It would be nice to not have to continually open and close readers on segments
> that aren't involved in a merge. Is t
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457764 ]
Michael McCandless commented on LUCENE-565:
---
> If SegmentInfos had a cached reader, that seems like it would solve both
> problems.
> I haven't thought a
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457789 ]
Yonik Seeley commented on LUCENE-565:
-
> Good idea! I think this could also be used by reopen (LUCENE-743 ) to re-use
> readers.
Yes, although reopen() needs
Grant Ingersoll wrote:
I propose, once I am done w/ some documentation housekeeping, to begin
work on http://issues.apache.org/jira/browse/LUCENE-662 (Nicolas' patch
to incorporate flexible indexing to Lucene) I think this is best
pursued by branching from trunk at the point I begin and pursui
Thanks for the comments Yonik!
To minimize the number of reader open/closes on large persistent segments, I
think the ability to apply deletes only before a merge is important. That
might add a 4th method: doBeforeMerge()
I'm not sure I get this. Buffered deletes are only applied(flushed)
d
Le Mardi 12 Décembre 2006 18:10, Doug Cutting a écrit :
> Grant Ingersoll wrote:
> > I propose, once I am done w/ some documentation housekeeping, to begin
> > work on http://issues.apache.org/jira/browse/LUCENE-662 (Nicolas' patch
> > to incorporate flexible indexing to Lucene) I think this is be
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457833 ]
Yonik Seeley commented on LUCENE-565:
-
On 12/12/06, Ning Li <[EMAIL PROTECTED]> wrote:
> > To minimize the number of reader open/closes on large persistent segm
[
http://issues.apache.org/jira/browse/LUCENE-745?page=comments#action_12457838 ]
Kevin Oliver commented on LUCENE-745:
-
This should also be considered along with LUCENE-711, which sizes some of the
other Vectors more appropriately.
> Make
: OK, if I put in source="1.4" then it works, but is that going to
: break the GData stuff?
try adding this to the javadoc task...
source="${ant.java.version}"
...the gdata stuff is automatically skiped when the java version running
ant isn't 1.5, and with that option the javadocs se
[
http://issues.apache.org/jira/browse/LUCENE-744?page=comments#action_12457855 ]
Hoss Man commented on LUCENE-744:
-
2cents: there's really no need for any of our tests to use the system temp dir
... the junit task in common-build.xml explicitly
Thanks hoss for the answer
The the "bad" java doc will be removed soon as I almost finished the
Gdata Object Model which means the google client classes are not
needed anymore. I will change the structure of the gdata contrib
project tomorrow which will cause some commits. I will skip rhe
int
[
http://issues.apache.org/jira/browse/LUCENE-702?page=comments#action_12457858 ]
Ning Li commented on LUCENE-702:
> This is actually intentional: I don't want to write to the same
> segments_N filename, ever, on the possibility that a reader may
[ http://issues.apache.org/jira/browse/LUCENE-742?page=all ]
Yonik Seeley resolved LUCENE-742.
-
Resolution: Fixed
Thanks Paul,
committed.
> SpanOrQuery.java: simplification and test
> -
>
> Key: L
yep, that works. I will commit the change.
On Dec 12, 2006, at 2:50 PM, Chris Hostetter wrote:
: OK, if I put in source="1.4" then it works, but is that going to
: break the GData stuff?
try adding this to the javadoc task...
source="${ant.java.version}"
...the gdata stuff is au
[
http://issues.apache.org/jira/browse/LUCENE-744?page=comments#action_12457863 ]
Grant Ingersoll commented on LUCENE-744:
Even better solution. Any reason java.io.tmpdir in JUnit task isn't
overridden to point to the same place as tem
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457865 ]
Ning Li commented on LUCENE-565:
> *or* you could choose to do it before a merge of the lowest level on-disk
> segments. If none of the lowest level segments have
: The the "bad" java doc will be removed soon as I almost finished the
: Gdata Object Model which means the google client classes are not
The problems Grant was having actually had nothing to do with gdata ... it
was trggered by some core code that uses assertions -- something perfectly
valid in
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457885 ]
Yonik Seeley commented on LUCENE-565:
-
Hmmm, I see your point... If deletes are deferred, a different reader could go
and open the index and see the additions
[ http://issues.apache.org/jira/browse/LUCENE-702?page=all ]
Michael McCandless updated LUCENE-702:
--
Attachment: LUCENE-702.take3.patch
> In IndexWriter, the rollbackTransaction call in commitTransaction could
> cause write to the same segment_N fil
Just spotted this on Slashdot:
http://opensource.fortifysoftware.com/welcome.html
I wonder what the 3 defects they found and reviewed are... I don't see a way to
see them from their site.
Otis
-
To unsubscribe, e-mail: [EMAI
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://lucene.apache.org/
Hi,
Indeed, I am very impressed by the fact that both the Nutch and Lucene
scored best of all considered project in the survey.
Congratulations to the community!
Lukas
On 12/13/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
Just spotted this on Slashdot:
http://opensource.fortifysoftware.co
30 matches
Mail list logo
