lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: Last failing tests remain to fix!
Date Wed, 08 Apr 2015 22:40:59 GMT
inline

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Lucene.NET committer and PMC member

On Thu, Apr 9, 2015 at 1:09 AM, Wyatt Barnett <wyatt.barnett@gmail.com>
wrote:

> Thanks for the update Itamar -- this sounds exciting.
>
> A few notes / questions from the build side of things here:
>
> First, I'm not as hung up on persistently failing tests as the tests we get
> intermittent failures on. I suspect some of the below will address this.
>

Yup


>
> Second, what do we want to do about the 112 or so ignored tests? I think
> some are marked as long-running via the [LongRunningTest] attribute but
> there are probably some ignored failures in that mix.
>

I guess that should be another task someone needs to take - can you try and
categorize them? some I know are JVM specfic tests that don't apply to
Lucene.NET


>
> Third, regarding the sub-projects, what does the structure look like so I
> can get that integrated into the TeamCity setup? Or should I noodle on it
> and propose one?
>

What do you mean? See here
https://github.com/apache/lucenenet/tree/master/src

Every subproject has a test suite that needs to be run, and should produce
a class library that we could push to nuget when we release. Until then we
should be able to allow people to install via nuget from our build server's
feed.

As far as dependencies and build triggers - that should be obvious and self
explanatory..

Does that make sense?


>
> Thanks for all the help from everyone getting things this far.
>
> On Wed, Apr 8, 2015 at 1:07 PM, Itamar Syn-Hershko <itamar@code972.com>
> wrote:
>
> > Hey all,
> >
> > We are nearly there -- we are this close to a release!
> >
> > We have only about 30 failing tests now in the core, and I'd like to push
> > hard during the next few days so we can get a beta out next week.
> >
> > I'd appreciate your help with this!
> >
> > I've narrowed down several failing tests that require some digging, if
> > folks can assign those to themselves and send us PRs fixing those tests,
> > that would help a lot!
> >
> > 1. Lucene.Net.Search.TestNumericRangeQuery32.TestInfiniteValues()
> > and Lucene.Net.Search.TestNumericRangeQuery64.TestInfiniteValues() --
> > specifically it seems like Double and Float NaNs are treated differently
> > between C# and Java and therefore the failing tests. Or there is a bug in
> > the inner implementation handling those queries.
> >
> > 2. TestLucene40DocValuesFormat has a few failing tests, probably exposing
> > data corruption in one of the codec components. I believe this is
> contained
> > in the 40DocValues tests so the scope isn't huge but I could be wrong.
> >
> > 3. TestLucene42DocValuesFormat has two tests failing with output of lines
> > like "Fail: frozenHash=182658 vs h=5124052". Something is off in
> computing
> > the hashes of the nodes, or maybe the node construction is faulty (which
> is
> > a serious bug). Hashing is done in Lucene.Net.Fst.NodeHash<T>, that'll
> be a
> > good starting point. Also see
> >
> >
> https://github.com/apache/lucenenet/commit/ea7cfe6972972f91090d995c729689fff9a0f54c
> >
> > 4. There seem to be some concurrency issues with file handling, probably
> on
> > the part that is in charge of acquiring and releasing locks. In
> particular
> > see TestDocValuesFormat,
> > .TestShardSearching.TestSimple(),
> > TestBufferedIndexInput.TestSetBufferSize(),
> > TestLockFactory.TestStressLocks(),
> > TestLockFactory.TestStressLocksNativeFSLockFactory()
> >
> > 5. RegexpQuery seems to be broken, I believe the underlying automaton
> > implementation doesn't emit the terms correctly. See the failures in
> > TestRegexpQuery and TestRegexpRandom.
> >
> > 6. Similar but probably unrelated failing test is
> > at TestSpanMultiTermQueryWrapper.TestFuzzy2()
> >
> > 7. An interesting failure to investigate is here:
> > TestIndexableBinaryStringTools.TestEncodedSortability() -- probably a
> > simple porting fail, a subtle Java <--> C# mismatch that we haven't
> > noticed.
> >
> > Additionally, any help with porting the subprojects would be great. Some
> > folks took some subprojects under their wings and never reported back. If
> > you could either complete the work, or donate whatever you have done so
> > far, that would be great.
> >
> > As always, get the code from here: https://github.com/apache/lucenenet
> --
> > work on your fork and send us a PR when ready, with a good description of
> > what you've done.
> >
> > To see the list of currently failing tests in real-time, go here (you can
> > login as guest):
> >
> >
> http://teamcity.codebetter.com/viewType.html?buildTypeId=LuceneNet_Core&branch_LuceneNet=%3Cdefault%3E&tab=buildTypeStatusDiv
> >
> > Thanks, and happy searching,
> >
> > --
> >
> > Itamar Syn-Hershko
> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > Freelance Developer & Consultant
> > Lucene.NET committer and PMC member
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message