Hi,
Could someone review SOLR-2923 [1]? Although the patch is a little
old, the bug still exists in trunk and the patch applies correctly.
Thank you!
1. https://issues.apache.org/jira/browse/SOLR-2923
--
Adrien
-
To
Thank you for your warm welcome. This is a great honor for me to
become a Lucene and Solr committer.
I am a french software engineer, currently living in Paris although I
was raised near Caen in Normandy. I started to get interested in
search engines in 2008 during an internship at Exalead where
Hi,
Lucene and Solr have a few classes that expose the size of their
instances, but with different method names. There are at least
ramBytesUsed (packed ints), sizeInBytes (FST, RamDirectory) and
memSize (Solr DocSets) that provide an estimation of the memory used
in bytes. The confusing thing is
On Fri, Jun 8, 2012 at 2:12 PM, Michael McCandless
luc...@mikemccandless.com wrote:
+1 to standardize on two names. It is confusing now!
Thanks Mike for your feedback, I created LUCENE-4121 [1] to address this issue.
[1] https://issues.apache.org/jira/browse/LUCENE-4121
--
Adrien
Hi Denis,
On Sun, Jun 17, 2012 at 5:57 AM, Denis Wilson Souza Rosa
deniswsr...@gmail.com wrote:
Do you have any sort of docs, papers or even books about the
algorithms that were implemented?
There are really lots of different algorithms being used in Lucene.
Moreover, more and more components
Welcome Greg!
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
On Fri, Jun 29, 2012 at 2:55 PM, Robert Muir rcm...@gmail.com wrote:
Can we move this CHANGES entry under the beta section?
Fixed. Thanks, Robert.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For
Hi Uwe,
On Sun, Oct 28, 2012 at 5:25 PM, Uwe Schindler u...@thetaphi.de wrote:
I don't want to use GIT; HG was horrible, too!
Why don't you like them?
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For
On Thu, Nov 1, 2012 at 7:27 PM, Michael McCandless
luc...@mikemccandless.com wrote:
I think Adrien fixed this in rev 1404456.
I hope so. :-) I just committed another fix in order to make sure to
use a FS dir for this test.
--
Adrien
Hi!
I'll try to complete what Simon and Robert said:
On Thu, Nov 8, 2012 at 8:56 AM, eksdev eks...@googlemail.com wrote:
Just a theoretical question, would it make sense to add some sort of
StoredDocument[] bulkGet(int[] docId) to fetch multiple stored documents in
one go?
The reasoning
Hi,
I just committed LUCENE-4509 [1] which changes the default
StoredFieldsFormat on trunk (backport to come on branch 4.x in a few
minutes). You should reindex.
[1] https://issues.apache.org/jira/browse/LUCENE-4509
--
Adrien
Hi Jack,
On Tue, Nov 13, 2012 at 4:06 PM, Jack Krupansky j...@basetechnology.comwrote:
Hmmm... does this mean that 4.1 would REQUIRE reindexing?
No it doesn't. This is a notice for people who would already use the
(unreleased) Lucene41Codec for some test indexes to tell them that they
I committed a fix.
--
Adrien
Hi Shai,
On Thu, Nov 15, 2012 at 11:39 AM, Shai Erera ser...@gmail.com wrote:
what if we made it a non-test class, which takes any Codec to wrap (i.e.
not default to Lucene41Codec)?
What would be the benefits of having this class vs. extending FilterCodec?
While at that, should
Hi,
On Thu, Nov 15, 2012 at 11:52 AM, Shai Erera ser...@gmail.com wrote:
Several objects introduce a Filter/Wrapper, which essentially act as
delegators. E.g. FilterDirectory, FilterCodec, FilterAtomicReader, and
while not strictly a delegator - SlowCompositeReaderWrapper.
I would like to
Hi,
I just modified the Lucene 4.1 stored fields format again[1]. You should
reindex.
[1] https://issues.apache.org/jira/browse/LUCENE-4558
--
Adrien
Hi David,
Looking at the last comments on LUCENE-4547[1], I think it has not been
decided yet whether there will be a type for multi-valued doc values or
applications will need to build it on top of binary doc values. If all your
documents have a fixed number of values, maybe an option could be
Hi Shawn,
Tests that are known to be slow can be disabled by passing
-Dtests.slow=false to ant test. Given that the zookeeper/cloud tests
are annotated with @Slow, ant test would ignore them.
--
Adrien
On Mon, Nov 19, 2012 at 11:11 PM, Mark Miller markrmil...@gmail.com wrote:
If nobody objects, I'm ready to try extending the commit bot jira
tagger to the whole dev group.
Nice to have the JIRA issues automatically updated, thanks!
--
Adrien
On Fri, Nov 30, 2012 at 3:48 PM, David Smiley (@MITRE.org)
dsmi...@mitre.org wrote:
RandomizedTesting for the win! Thanks a ton Dawid.
+1
--
Adrien
On Tue, Dec 11, 2012 at 4:44 PM, Uwe Schindler u...@thetaphi.de wrote:
So we may need some svn-ignored extra folder, appearing in the source
folders of the IDE, but the contents are generated by ant eclipse.
+1
--
Adrien
Congratulations Sami!
--
Adrien
Hi Shai,
On Thu, Dec 13, 2012 at 12:21 PM, Shai Erera ser...@gmail.com wrote:
As I said, if someone volunteers to do some work on the Solr side, I will
gladly participate in that effort.
I just don't even know where to start w/ Solr :).
The entry point for Solr facets is
Hi Shai,
Thanks for your answers!
On Thu, Dec 13, 2012 at 5:05 PM, Shai Erera ser...@gmail.com wrote:
the lucene module requires users to decide at indexing time what and how
to facet
whereas Solr does everything at searching time
True, that's one difference between the two implementations
Hi Uwe,
On 31/08/2012 17:53, Uwe Schindler wrote:
We can now also make BulkOperationPackedSingleBlock final like the other
classes!
Good point, it cannot hurt! I just committed.
--
Adrien Grand
-
To unsubscribe, e-mail
Sorry, looks like something went wrong in my last commit. I'll try to
fix it.
--
Adrien Grand
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Hi Jack,
On Tue, Sep 18, 2012 at 10:43 PM, Jack Krupansky
j...@basetechnology.com wrote:
/**
* @return tha maximum number of chars in source field to copy to destination
field.
*/
public int getMaxChars() {
tha s.b. the.
I just committed a fix, thanks for reporting this typo.
--
Adrien
On Mon, Sep 24, 2012 at 3:43 PM, Robert Muir rcm...@gmail.com wrote:
Whats the problem? everything works fine here (ant documentation-lint)
with 1.6.0_26:
The problem is that some class-use HTML files are not valid (they
contain lines such as TDCode to maintain and access
indices.\n!nbsp;/TD
Smoke test passed successfully on my computer (Ubuntu 12.04.1 , locale=fr_FR).
Good that lucene-core JAR now is 2.0 MB (vs. 2.3 in 4.0-BETA).
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional
Mike,
On 03/10/2012 17:35, mikemcc...@apache.org wrote:
+if (!success) {
+ IOUtils.close(bloomIn, delegateFieldsProducer);
+} else {
+ IOUtils.close(bloomIn);
+}
When success is false, maybe you should use closeWhileHandlingException instead?
--
Smoke tests passed on my computer.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
On Tue, Oct 9, 2012 at 6:34 PM, Robert Muir rcm...@gmail.com wrote:
Test2BStoredFields? :)
Funny that we found an integer overflow at the same time! But this
kind of test seems hard to implement to me (the trick in Test2BDocs
won't help...).
--
Adrien
On Tue, Oct 9, 2012 at 6:45 PM, Robert Muir rcm...@gmail.com wrote:
Test2BDocs cheats and only tests IndexReader.
Does compressing stored fields optimize merging with any bulk-byte
copying? Maybe that could speed up such a test so it only takes
minutes (like Test2BPostings)
Yes and no :
Welcome, Alan!
On 10/08/2012 17:54, Michael McCandless wrote: Replying to dev@
because Jira keeps being unavailable:
Seems like we should default BlockPostingsFormat to COMPACT.
Something that worries me too is that I tried to reproduce this
benchmark (but with a lower jvmCount as I was running out of time)
My bad, I'll fix it.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Too late, Robert already fixed it! Thanks Robert!
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Hi Shai,
I think the issue is that Facet45Codec shouldn't be declared in
META-INF/services. This codec is exactly the same one as
Lucene45Codec, it only sets different defaults at writing time but
reading segments written with Lucene45 or Facet45 is exactly the same
for Lucene. We could set up
Hi,
On Fri, Aug 30, 2013 at 3:00 PM, Shai Erera ser...@gmail.com wrote:
The Codec itself may not be needed to be specified in META-INF/services, but
the DVFormat it uses is.
Correct, because otherwise Lucene couldn't read segments written with
this DV format.
So it's not like you can define
Hi Thomas,
On Fri, Aug 30, 2013 at 2:57 PM, Thomas Matthijs li...@selckin.be wrote:
Needs to be in services or you can't read indexes written with it afaik
This is correct in general, but in this particular case, Facet45Codec
is a sub-class of Lucene45Codec which just overrides the default doc
Actually this is a side-effect of LUCENE-5188. There is a bug in
LZ4.compressHC (which I committed to test various trade-offs between
compression speed and ratio but is not used in any official codec) on
very compressible inputs which seems to be more easily triggered now
that the inputs can be
Good ideas. Uwe also suggested to open an issue so that this bug fix
is in the changelog. I will do it soon...
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail:
The luke request handler and your JaccardSimilarityQuery use the same
API to retrieve documents (according to the stack trace) so I'm
surprised that you see errors in one case only. Are you sure you are
looking at the same documents? If background merges happened between
your M/R job and your
Hi,
I was looking at the changelogs for Lucene and Solr and I think they
look pretty good. What would you think about realeasing Lucene/Solr
4.5, are there issues you would like to get in before the release?
--
Adrien
-
To
Unless someone else volunteers to do the release, I'll be busy until
~wednesday next week so there are still a few days to get fixes in
anyway. However I agree with Robert that our branch_4x should always
be stable and releasable.
@Jack, @Erick could you share more details about the issues that
Out of curiosity, is it just for having another testing environment or
does Bamboo have useful features for us that Jenkins doesn't have?
On Wed, Sep 11, 2013 at 8:26 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
Do they also offer Bamboo services? This would be a nice addition to
Hi all,
Since everyone seems to agree this is time for a release, I created a
lucene_solr_4_5 branch in our SVN repository. From now on, please
backport to this branch all changes that should go into a Lucene/Solr
4.5 release.
I'm going to work on updating the versions in the code base, JIRA and
This is my bad, I will fix it.
On Thu, Sep 12, 2013 at 3:01 PM, Policeman Jenkins Server
jenk...@thetaphi.de wrote:
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/793/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseSerialGC
All tests passed
Build Log:
[...truncated 22633
This should be fixed now.
On Thu, Sep 12, 2013 at 3:04 PM, Adrien Grand jpou...@gmail.com wrote:
This is my bad, I will fix it.
On Thu, Sep 12, 2013 at 3:01 PM, Policeman Jenkins Server
jenk...@thetaphi.de wrote:
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/793/
Java: 64bit
Hi,
Versions have been updated in trunk and branch_4x. I started writing
release notes drafts[1][2] but I'm pretty sure they are terrible, feel
free to reword existing entries or add new ones for important changes.
[1] https://wiki.apache.org/lucene-java/ReleaseNote45
[2]
Thanks for pointing this out, Otis!
I think the columnar nature of Parquet makes it more similar to doc
values than to stored fields, and indeed, if you look at the parquet
file-format specification [1], it is very similar to what we have for
doc values [2]. In both cases, we have
- dictionary
Up to Lucene 4.4, CachingWrapperFilter cached filters with FixedBitSet
only by default, which sounds wasteful when the filter only matches a
few documents so I wanted to start experimenting with new
alternatives. I first worked on WAH8DocIdSet, then Paul Elschot
contributed EliasFanoDocIdSet and
Hi all,
Please test and vote to release the following Lucene and Solr 4.5.0 artifacts:
http://people.apache.org/~jpountz/staging_area/lucene-solr-4.5.0-RC0-rev1524484/
This vote is open until monday.
Smoke tester passed and Elasticsearch tests ran successfully with
these artifacts, so here is
Hi,
On Thu, Sep 19, 2013 at 3:10 PM, Yonik Seeley yo...@lucidworks.com wrote:
It looks like the last commit on SOLR-4221 didn't make it on the 45
branch. This is a change to a new API and hence needs to make it into
4.5
Thanks for noticing this issue, I will backport the commit.
Hoss, do
On Thu, Sep 19, 2013 at 3:40 PM, Noble Paul നോബിള് नोब्ळ्
noble.p...@gmail.com wrote:
I see a commit message on branch_4x for the changes I made . Isn't it the
same branch?
I created the lucene_solr_4_5 branch last week, which I'm using to
create release candidates. The purpose was to allow
Hi,
Lucene needs to load a field value entirely into memory in order to
store it, which defeats the purpose of providing a field value with a
Reader (ie. in a streaming fashion). This is why storing fields is not
supported by this constructor.
If you want your field to be stored, you need to
LUCENE-5223 and the missing commit from SOLR-4221 have been
backported. A new RC is currently being uploaded...
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail:
Here is a new release candidate. Difference with the previous
candidate is that this RC1 now has LUCENE-5223 as well as the missing
commit from SOLR-4221:
http://people.apache.org/~jpountz/staging_area/lucene-solr-4.5.0-RC1-rev1524755/
This vote is open until Tuesday.
Smoke tester was happy on
Hi Chris,
On Fri, Sep 20, 2013 at 2:33 AM, Chris Hostetter
hossman_luc...@fucit.org wrote:
I *think* this means that we just need to backport r1522884 to the 4_5
branch, but i don't think we need a re-spin.
Thanks for reporting this error. I agree this doesn't need a respin,
especially given
On Fri, Sep 20, 2013 at 9:20 AM, Adrien Grand jpou...@gmail.com wrote:
I'll backport the commit to lucene_solr_4_5.
Oh, I see you have already done that, thanks!
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr
Yonik,
On Tue, Sep 24, 2013 at 1:52 AM, Yonik Seeley yo...@lucidworks.com wrote:
The fix has been committed to the 45 branch.
Given how much pain was caused the last time the binary format changed
(the change from modified-UTF8 to normal UTF-8), I think this warrants
a 4.5 re-spin.
Thanks
Here is a new release candidate that fixes some JavaBin codec backward
compatibility issues (SOLR-5261, SOLR-4221).
Please vote to release the following artifacts:
http://people.apache.org/~jpountz/staging_area/lucene-solr-4.5.0-RC2-rev1526012/
Smoke tester was happy on my end so here is my
On Thu, Sep 26, 2013 at 12:21 PM, Uwe Schindler uschind...@apache.org wrote:
Welcome back heavy committing! :-)
Welcome back Wolfgang!
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional
Thanks to Markus Jelsma's thoughtful testing, other backward
compatibility issues of the JavaBin codec have been found and fixed
(SOLR-4221). Please vote to release the following artifacts:
http://people.apache.org/~jpountz/staging_area/lucene-solr-4.5.0-RC3-rev1526423/
The vote is open until
Agreed, LUCENE-5218 seems to be worth a respin. I will also backport
LUCENE-5245 as per Simon's suggestion.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail:
Here is a new release candidate for which LUCENE-5218, LUCENE-5245 and
LUCENE-5233 have been backported. Please vote to release the following
artifacts:
http://people.apache.org/~jpountz/staging_area/lucene-solr-4.5.0-RC4-rev1526586/
This vote is open until Tuesday.
Smoke tester was happy on
Hi Steve,
On Fri, Sep 27, 2013 at 9:30 PM, Steve Rowe sar...@gmail.com wrote:
I attached a fix to the issue Shawn created for the missing implicit
Solr-core-properties-on-RELOAD issue: SOLR-5279
IMHO, this regression should be fixed in 4.5.
Adrien, I tried to raise you on IRC but didn't
Please vote to release the following artifacts:
http://people.apache.org/~jpountz/staging_area/lucene-solr-4.5.0-RC5-rev1527178/
Here is my +1.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For
Thank you all for testing the release artifacts, the vote passed. I
will start the release process soon.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail:
Welcome, Joel!
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
For your information, I'm having trouble uploading the Solr artifacts
to dist.apache.org[1] so there might be some delay before I announce
the release. I'll keep you informed.
[1] https://issues.apache.org/jira/browse/INFRA-6827
--
Adrien
. If that is the case, please
try another mirror. This also goes for Maven access.
--
Adrien Grand
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
On Tue, Oct 8, 2013 at 8:30 PM, Michael McCandless
luc...@mikemccandless.com wrote:
This tells the Memory DVFormat that you're willing to waste RAM to get
faster decode speed. However, it had no effect! Apparently, Memory
DVFormat only uses that parameter when the number of unique values is
I'm pleased to announce that Ryan Ernst has accepted to join our ranks
as a committer.
Ryan has been working on a number of Lucene and Solr issues and
recently contributed the new expressions module[1] which allows for
compiling javascript expressions into SortField instances with
excellent
The test confuses me, it calls bits.ensureCapacity(bit) followed by
bits.fastSet(bit), but if bit becomes the new capacity then it is by
definition out of range?
--
Adrien
-
To unsubscribe, e-mail:
Welcome Shalin!
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
I'll dig.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
On Thu, Apr 4, 2013 at 10:54 PM, Steve Rowe sar...@gmail.com wrote:
This reproduces 100% for me on trunk under OS X - I made an issue:
https://issues.apache.org/jira/browse/LUCENE-4908
Thanks Steve, that may be because of my last commit that I've not
backported on 4.x yet...
--
Adrien
It was actually due to my last commit. I committed a fix and closed the issue.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
I committed a fix.
On Thu, Apr 11, 2013 at 1:06 AM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1494/
No tests ran.
Build Log:
[...truncated 342 lines...]
[javac] Compiling 373 source files to
On Tue, Apr 23, 2013 at 1:50 PM, Simon Willnauer
simon.willna...@gmail.com wrote:
Here is a new RC candidate...
http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
+1
--
Adrien
-
To unsubscribe,
On Tue, Apr 30, 2013 at 9:29 AM, Simon Willnauer
simon.willna...@gmail.com wrote:
ok guys here is my +1 for TAKE 4 !!
+1 Smoke tester ran successfully.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For
Hi Steve,
On Tue, Apr 30, 2013 at 3:57 PM, Steve Rowe sar...@gmail.com wrote:
Smoke tester is unhappy when testing Lucene - this reproduces for me 100%,
both from the unpacked source release tarball and on the release branch,
under both Java 6 and 7:
-
[junit4:junit4] Suite:
On Fri, May 3, 2013 at 6:14 AM, Robert Muir rcm...@gmail.com wrote:
I think solr should no longer be a war file but a search app. I don't care
how it accomplishes this: jetty, netty, its all up to us.
Let me know your ideas: I think its a necessary step to move solr forwards.
+1 I think this
My bad, I'll fix!
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
This test failed because CommonGramsFilter immediately followed
MockGraphTokenFilter and doesn't handle graph inputs correctly:
https://issues.apache.org/jira/browse/LUCENE-4983.
On Tue, May 7, 2013 at 1:27 PM, Policeman Jenkins Server
jenk...@thetaphi.de wrote:
Build:
Hi Erick,
The stored fields reader reuses the buffer used for decompression across
calls in the same thread, so I'm thinking that this kind of behaviour could
happen if some documents are very large. Is it the case?
Adrien
Le 8 mai 2013 17:22, Erick Erickson erickerick...@gmail.com a écrit :
Erick,
On Thu, May 9, 2013 at 10:28 PM, Erick Erickson erickerick...@gmail.com wrote:
Yeah, this is getting warmer. Some of the
CompressingStoredFieldsReader objects are 240M. The documents aren't
nearly that large I don't think (but I'll verify).
Wow, 240M is a lot! Would you be able to know
On Mon, May 13, 2013 at 5:43 PM, rm...@apache.org wrote:
Author: rmuir
Date: Mon May 13 15:43:51 2013
New Revision: 1481936
URL: http://svn.apache.org/r1481936
Log:
avoid NRTCachingDirectory in this test
Thank you Robert!
--
Adrien
I'll dig.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
This was an actual bug: Sorter.rotate could be called even when one of
the two adjacent slices to rotate is empty, which is bad since it
potentially performs lots of copies/swaps while there is nothing to
do.
I committed a fix.
--
Adrien
I can reproduce this one. It seems to me that the problem is that
MockDirectoryWrapper.getRecomputedSizeInBytes uses RAMFile.length
although RAMFile.length is only set on flush or seek and is 0 until
then? Should setFileLength be called after every write?
On Thu, May 16, 2013 at 8:35 AM, Apache
On Thu, May 16, 2013 at 11:30 AM, Shai Erera ser...@gmail.com wrote:
As long as bytes are buffered, I think it's OK to not hit disk-full... they
never made it to the directory yet.
Good point. So the test needs to call commit right after
IndexWriter.add(Document) to make sure flush gets called,
On Thu, May 16, 2013 at 1:58 PM, Robert Muir rcm...@gmail.com wrote:
I dont get it. MDW wraps its IndexOutput so it knows... sounds like
the counting is off.
The problem is that RAMDirectory delays the counting.
MockDirectoryWrapper.getRecomputedActualSizeInBytes sums all the
lengths of the
On Thu, May 16, 2013 at 7:55 PM, Robert Muir rcm...@gmail.com wrote:
FYI we currently have:
[exec] Crawl/parse...
[exec]
[exec]
file:///build/docs/analyzers-common/org/apache/lucene/analysis/util/FilteringTokenFilter.html
[exec] WARNING: anchor version appears
Since the resolution of this failure doesn't look trivial (as there
are several options), I opened
https://issues.apache.org/jira/browse/LUCENE-5004.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For
Seems to be https://issues.apache.org/jira/browse/LUCENE-5004.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
In this test, EdgeNGramTokenFilter immediately follows ShingleFilter
and it fails because EdgeNGramTokenFilter doesn't handle graph inputs
correctly. I working on a fix.
--
Adrien
-
To unsubscribe, e-mail:
I committed a fix.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
I just reverted the change that made the test fail.
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
1 - 100 of 6267 matches
Mail list logo
