[
https://issues.apache.org/jira/browse/LUCENE-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670103#action_12670103
]
Doug Cutting commented on LUCENE-1534:
--
Now, on the cusp of 3.0, might be a good time
[
https://issues.apache.org/jira/browse/LUCENE-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669750#action_12669750
]
Doug Cutting commented on LUCENE-1534:
--
I've always found idf squared an unhelpful
[
https://issues.apache.org/jira/browse/LUCENE-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669754#action_12669754
]
Doug Cutting commented on LUCENE-1534:
--
sumOfSquaredWeights properly normalizes query
Uwe Schindler wrote:
Why not refer?
I would not veto the refer, but I also would not vote for it and would
not add it myself. As a developer, when I want to see unreleased
javadocs, I build them. Posting unreleased documentation has risks.
Folks might find them, develop software against
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667326#action_12667326
]
Doug Cutting commented on LUCENE-1483:
--
In principle, the MultiSearcher is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663055#action_12663055
]
Doug Cutting commented on LUCENE-1345:
--
Uwe Maybe I should create an new JIRA issue
[
https://issues.apache.org/jira/browse/LUCENE-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663090#action_12663090
]
Doug Cutting commented on LUCENE-1518:
--
Why 1.0 and not 0.0?
0.0 does seem more
robert engels wrote:
You are a moron. And I don't mean that in a offensive way - I am using
the secondary definition.
*2**:* a very stupid person
That's still offensive and totally unacceptable here. Please refrain
from making ad-hominem remarks and stick to discussing the issues.
robert engels wrote:
Can something be offensive if its a statement of fact ? If you believe
it is (under definition #3), then his remarks to me were just as
offensive - as they caused me much displeasure and resentment. So please
dress him down as well.
His comments were on-topic. The
[
https://issues.apache.org/jira/browse/LUCENE-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662247#action_12662247
]
Doug Cutting commented on LUCENE-1476:
--
bq. To really tighten this loop, you have
Andrzej Bialecki wrote:
No matter whether you are right or wrong, please keep a civil tone on
this public forum.
+1 Ad-hominem remarks are anti-community.
Doug
-
To unsubscribe, e-mail:
Robert Engels wrote:
Do what you like. You obviously will. This is the problem with the Lucene
managers - the problems are only the ones they see - same with the solutions.
If the solution (or questions) put them outside their comfort zone, they are
ignored or dismissed in a tone that is
Michael McCandless wrote:
So then I think we should start with approach #2 (build real-time on
top of the Lucene core) and iterate from there. Newly added docs go
into a tiny segments, which IndexReader.reopen pulls in. Replaced or
deleted docs record the delete against the right SegmentReader
Jason Rutherglen wrote:
2) Implement realtime search by incrementally creating and merging
readers in memory. The system would use MemoryIndex or
InstantiatedIndex to quickly (more quickly than RAMDirectory) create
indexes from added documents.
As a baseline, how fast is it to simply use
Michael McCandless wrote:
Are you saying we can deprecate these classes in 2.9, and all methods
whose signature involves one of these classes, without offering the
new classes?
No. Folks should be able to recompile w/o deprecation warnings against
2.9, then upgrade to 3.0. Features should
Jason Rutherglen wrote:
Broadly speaking, what areas are we looking to create new APIs for in
2.9? How dramatic are we looking to go?
That's not really the question. We shouldn't rush to get big API
changes in. Rather we should continue to cautiously evolve the API.
Periodically, when
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12657466#action_12657466
]
Doug Cutting commented on LUCENE-1483:
--
bq. I would actually be fine with keeping
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12657476#action_12657476
]
Doug Cutting commented on LUCENE-1483:
--
Woah! Don't make me switch all that again
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656071#action_12656071
]
Doug Cutting commented on LUCENE-1473:
--
Therefore the patch is to be taken
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656073#action_12656073
]
Doug Cutting commented on LUCENE-1483:
--
public abstract void setBase(int base
Jason Rutherglen wrote:
Decoupling IndexReader would for 3.0 would be great. This includes
making public SegmentReader, MultiSegmentReader.
A constructor like new SegmentReader(TermsDictionary termDictionary,
TermPostings termPostings, ColumnStrideFields csd, DocIdBitSet deletedDocs);
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655761#action_12655761
]
Doug Cutting commented on LUCENE-1483:
--
Could we add a new class like
{code}
public
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655806#action_12655806
]
Doug Cutting commented on LUCENE-1473:
--
Thanks, Wolf, this looks like a promising
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655812#action_12655812
]
Doug Cutting commented on LUCENE-1483:
--
If users are using a HitCollector as a ref
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655894#action_12655894
]
Doug Cutting commented on LUCENE-1473:
--
shift the problem around but do not really
[
https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654875#action_12654875
]
Doug Cutting commented on LUCENE-1482:
--
safeDebugMsg is protected in a public class
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654940#action_12654940
]
Doug Cutting commented on LUCENE-1483:
--
make a HitCollector that gathers the results
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654970#action_12654970
]
Doug Cutting commented on LUCENE-1483:
--
But for IndexSearcher(Multi*Reader).search
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654513#action_12654513
]
Doug Cutting commented on LUCENE-1473:
--
Would it take any more lines of code
[
https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654545#action_12654545
]
Doug Cutting commented on LUCENE-1482:
--
Should I attach the slf4j jars separately
John Wang wrote:
Thus we are enforcing users
that care about Serialization to use the release jar.
We already encourage folks to use a release jar if possible. So this is
not a big change. Also, if folks choose to build their own jar, then
they are expected to use that same jar everywhere,
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653869#action_12653869
]
Doug Cutting commented on LUCENE-1473:
--
How to write a unit test for multiple
The infoStream stuff goes back to 1997, before there was log4j or any
other Java logging framework.
There's never been a big push to add logging to Lucene. It would add a
dependency, and Lucene's jar has always been standalone, which is nice.
Dependencies can conflict. If Lucene requires
Shai Erera wrote:
Perhaps instead of introducing Java logging then (if you're too against
it), we could introdue a static InfoStream class, with a static
message() and isVerbose() methods.
It's tempting to add our own logging API, as you suggest, but I fear
that would re-invent what so many
John Wang wrote:
If we were to depend on a jar for logging, then why not log4j or
commons-logging?
Lucene is used by many applications. Many of those applications already
perform some kind of logging. We'd like whatever Lucene adds to fit in
with their existing logging framework, not
John Wang wrote:
This has been gone back and forth on this thread already. Again,
I agree it is not the perfect solution. I am comparing that to the
current behavior, I don't think it is worse. (Only in my opinion).
So, if it's good enough for you, a user of java serialization, then
Jason Rutherglen wrote:
I think it's best to implement Externalizable as long as someone is
willing to maintain it. I commit to maintaining the Externalizable
code.
We need to agree to maintain things as a community, not as individuals.
We can't rely on any particular individual being
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653972#action_12653972
]
Doug Cutting commented on LUCENE-1473:
--
I guarantee 2.9 and above classes
John Wang wrote:
I agree with the process itself, what would make it better is
some transparency on how patches/issues are evaluated to be committed.
To be clear: there is no forum for communication about patches except
this list, and, by extension, Jira. The process of patch evaluation is
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653413#action_12653413
]
Doug Cutting commented on LUCENE-1473:
--
Serialization between VM1 and VM2 of class
Jason Rutherglen wrote:
A relatively simple patch such as 1473 Serialization
represents this well.
LUCENE-1473 is an incomplete patch that proposes to commit the project
to new back-compatibility requirements. Compatibility requirements
should not be added lightly, but only deliberately,
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653553#action_12653553
]
Doug Cutting commented on LUCENE-1473:
--
This discussion has digressed to general
John Wang wrote:
If you guys need help, maybe you guys should expand your committer list?
Committers are added when they've contributed a series of high-quality
patches that have been committed, and demonstrated their ability to be
easy to work with. Displaying anger is not a good way to
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652882#action_12652882
]
Doug Cutting commented on LUCENE-1473:
--
But, what's now being asked for (expected
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652888#action_12652888
]
Doug Cutting commented on LUCENE-1473:
--
bq. If it is not meant to be serialized, why
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652932#action_12652932
]
Doug Cutting commented on LUCENE-1473:
--
Doesn't Hadoop handle versioning inside
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652939#action_12652939
]
Doug Cutting commented on LUCENE-1473:
--
The documentation should probably be fixed
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652965#action_12652965
]
Doug Cutting commented on LUCENE-1473:
--
I'm not sure why you and Doug and focusing
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652591#action_12652591
]
Doug Cutting commented on LUCENE-1473:
--
The attached patch optimizes java
[
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652194#action_12652194
]
Doug Cutting commented on LUCENE-1472:
--
ThreadLocal?
DateTools.stringToDate() can
[
https://issues.apache.org/jira/browse/LUCENE-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12650344#action_12650344
]
Doug Cutting commented on LUCENE-1451:
--
A bit of history, if any care.
Originally
Michael McCandless wrote:
I do worry that wholesale formatting changes will obsolete pending
patches
Note that 'patch -l' will ignore whitespace, permitting indentation
changes w/o breaking patches.
Doug
-
To unsubscribe,
Steven A Rowe wrote:
This would not entirely fix the issue; each version's javadocs should link to the same version of the site docs, rather than to the latest version (which is what I assume you mean here).
Right. The javadocs should use a relative link to point to versioned
docs. But, if
[
https://issues.apache.org/jira/browse/LUCENE-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12645565#action_12645565
]
Doug Cutting commented on LUCENE-1422:
--
But: what if you revert all changes to all
Broken links in released docs might be fixed by adding redirects to the
website, by editing:
http://svn.apache.org/repos/asf/lucene/.htaccess
The trunk javadocs should not be published on the website. We should
only publish released documentation.
Doug
Steven A Rowe wrote:
When the
Michael Busch wrote:
Currently Lucene's backwards compatibility policy states: That's to
say, any code developed against X.0 should continue to run without
alteration against all X.N releases. In LUCENE-1422 the question came
up if this statement should apply to public and protected APIs only
[
https://issues.apache.org/jira/browse/LUCENE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641132#action_12641132
]
Doug Cutting commented on LUCENE-1426:
--
+1 This sounds like a great way to approach
[
https://issues.apache.org/jira/browse/LUCENE-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639495#action_12639495
]
Doug Cutting commented on LUCENE-1422:
--
prototypeToken() and nextToken() seem
Michael Busch wrote:
public abstract boolean nextToken() throws IOException;
What's the point of a separate Token and TokenStream if there's only a
single Token per TokenStream? If that's really the direction we'll go,
then all of the Token methods should be on TokenStream, and Token
Yonik Seeley wrote:
AIUI, Apache only officially releases source code, so any binaries are
artifacts or derivatives of a release, not really the release itself.
Unless those artifacts include the source code. It's best to vote on a
signed tgz file than a subversion tag, since the latter can
To be clear, one can use the official Lucene logo for this purpose,
right? Apache doesn't want its trademarks used to describe other
products, but other folks using the Lucene logo to refer to Apache
Lucene is fine. So a link to http://lucene.apache.org/ whose anchor is
Powered by Lucene
Chris Hostetter wrote:
Bingo. Even if we know 100% when/how the Lucene logo can be used, and we
write lots of words about it on the website to make it clear to people
when/how they can use it, people still may avoid it out of legal paranoia.
Long ago, we used to do that.
[
https://issues.apache.org/jira/browse/LUCENE-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12618001#action_12618001
]
Doug Cutting commented on LUCENE-1340:
--
I firmly believe there is a way to do
This also reminds me of the pulsing technique described in:
http://citeseer.ist.psu.edu/cutting90optimizations.html
Doug
eks dev wrote:
It seams someone else had the same idea to inline very short postings into
term dictionary (even for in-memory index) ans save one pointer (and seek, in
[
https://issues.apache.org/jira/browse/LUCENE-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601336#action_12601336
]
Doug Cutting commented on LUCENE-1294:
--
I too always felt this a feature, albeit
Chris Hostetter wrote:
I've added you to the committer group in Jira .. you should be able to
assign issues to yourself, and resolve issues now.
You mean 'role', right? We don't use Jira groups much anymore.
Doug
-
To
[
https://issues.apache.org/jira/browse/LUCENE-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598105#action_12598105
]
Doug Cutting commented on LUCENE-1290:
--
FWIW, the Hits API was originally designed
The conventional use of ngrams when searching is not to treat them as a
set but a sequence. Thus, for foola you could index the sequence
[_f, fo, oo, ol, la, a_], and then search for the phrase
[oo, ol] to find all occurences of ool. This is useful in
languages that use logograms without
[
https://issues.apache.org/jira/browse/LUCENE-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583797#action_12583797
]
Doug Cutting commented on LUCENE-1255:
--
Since the increment is relative to the prior
[
https://issues.apache.org/jira/browse/LUCENE-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583808#action_12583808
]
Doug Cutting commented on LUCENE-1255:
--
Hoss: you're right, the change I proposed
[
https://issues.apache.org/jira/browse/LUCENE-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582442#action_12582442
]
Doug Cutting commented on LUCENE-1231:
--
So there are a number of features
robert engels wrote:
Some would argue that all that Field needs is
FieldData getField(String name); and void setField(String name,FieldData
data);
and FieldData has
toBytes(); fromBytes()
Isn't hindsight wonderful!
Writing custom versions of IndexReader and IndexWriter was very
Chris Hostetter wrote:
in my opinion other blog he links to hits the nail on the head a
little better (i remember reading this last year) ...
http://kirillosenkov.blogspot.com/2007/08/choosing-interface-vs-abstract-class.html
The rule of thumb there is good too:
An interface should define
Steven A Rowe wrote:
In the comments on the blog post, the author (Kirill Osenkov) agrees with a dissenter
(Alexander Jung, a.k.a. AJ.NET), who re-states the rule of thumb as:
An interface should define at most one contract.
But what if you want to expand the contract? For example, Field
robert engels wrote:
The problem with abstract classes, is that any methods you provide
know something of the implementation, unless the methods are
implemented solely by calling other abstract methods (which is rarely
the case if the abstract class contains ANY private members).
Yes,
[
https://issues.apache.org/jira/browse/LUCENE-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated LUCENE-1217:
-
Description:
Field class can hold three types of values,
See: AbstractField.java protected
[
https://issues.apache.org/jira/browse/LUCENE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12571553#action_12571553
]
Doug Cutting commented on LUCENE-954:
-
Disabling score normalization in Hits seems like
Michael McCandless wrote:
In fact I've found you need to pursue both the 2x type gains and also
the many smaller ones, to reach good performance.
+1 Put another way, you must address both the asymptotic behavior and
the constant factors. A good order-of-algorithms implementation is
Ning,
I am also interested in starting a new project in this area. The
approach I have in mind is slightly different, but hopefully we can come
to some agreement and collaborate.
My current thinking is that the Solr search API is the appropriate
model. Solr's facets are an important
[
https://issues.apache.org/jira/browse/LUCENE-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565815#action_12565815
]
Doug Cutting commented on LUCENE-1044:
--
deprecate autoCommit=true entirely
+1
[
https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565820#action_12565820
]
Doug Cutting commented on LUCENE-1157:
--
I worry that the nightly build documentation
[
https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565843#action_12565843
]
Doug Cutting commented on LUCENE-1157:
--
Sure, it makes sense to make changes.txt
[
https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565917#action_12565917
]
Doug Cutting commented on LUCENE-1157:
--
Maybe we can make the links to the nightly
Michael Busch wrote:
Doug Cutting wrote:
/www/lucene.apache.org/java/docs/api/.htaccess
/www/lucene.apache.org/java/docs/nightly/api/.htaccess
I just changed these to files to redirect to the new location:
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/javadoc
Chris Hostetter wrote:
the only .htaccess
files i can find anywhere under
https://svn.apache.org/repos/asf/lucene/java/site or
https://svn.apache.org/repos/asf/lucene/java/trunk only contain
AddDefaultCharset off
There are more:
find /www/lucene.apache.org/ -name .htaccess
[
https://issues.apache.org/jira/browse/LUCENE-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561778#action_12561778
]
Doug Cutting commented on LUCENE-1121:
--
For Hadoop, we've seen significant
Grant Ingersoll wrote:
Does anyone have experience w/ how other open source projects deal with
this?
Use abstract base classes instead of interfaces: they're much easier to
evolve back-compatibly. In Hadoop, for example, we really wish that
Mapper and Reducer were not interfaces and are
[
https://issues.apache.org/jira/browse/LUCENE-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561539#action_12561539
]
Doug Cutting commented on LUCENE-1121:
--
What JVM were these tests run with?
Use
Grant Ingersoll wrote:
1. We add a new section to CHANGES for each release, at the top where we
can declare what deprecations will be removed in the _next_ release
(major or minor) and also any interface API changes
2. When deprecating, the @deprecate tag should declare what version it
will
[
https://issues.apache.org/jira/browse/LUCENE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559730#action_12559730
]
Doug Cutting commented on LUCENE-1084:
--
This kind of limit is common on web search
Grant Ingersoll wrote:
I don't know, I think it is nice to have explicit links to previous ones
as well, but it is one extra click. I suspect that is the main thing
people want from previous versions so it is nice to not have to dig deep
into the Site Versions and have it right there from the
Matt Reynolds wrote:
Directory is currently an abstract class that claims in its javadoc that
Directory is a flat list of files, then goes on to describe non-flat
list of files based implementations (JDBC, RAM, etc). Is it worthwhile
to split out Directory into a top level interface, and
[
https://issues.apache.org/jira/browse/LUCENE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555642#action_12555642
]
Doug Cutting commented on LUCENE-1103:
--
Should the position increment be zero
[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551566
]
Doug Cutting commented on LUCENE-1083:
--
The changes to build.xml should be provided as a patch file
[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551625
]
Doug Cutting commented on LUCENE-1083:
--
Thanks for updating this!
bq. The svn task is not in ant core yet
[
https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550130
]
Doug Cutting commented on LUCENE-753:
-
Brad, [...]
That's Brian. And right, the difference in your tests
[
https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550135
]
Doug Cutting commented on LUCENE-753:
-
My prior remarks were posted before I saw Brian's latest benchmarks
[
https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550179
]
Doug Cutting commented on LUCENE-753:
-
So it looks like pread is ~50% slower on Windows, and ~5-25% faster
[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549500
]
Doug Cutting commented on LUCENE-1083:
--
The prior release is a new concept that needs to be added to the build
Grant Ingersoll wrote:
Right, the javadocs are for the nightly build. See the Site Versions
section of http://lucene.apache.org/java/docs/index.html for releases.
Unreleased stuff should only be linked to in a developer section of
the website. Right now the primary javadoc links on the
1 - 100 of 473 matches
Mail list logo
