lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elad Margalit <eladm...@gmail.com>
Subject Re: Remaining Work/Priorities
Date Mon, 03 Oct 2016 18:15:14 GMT
Hi,

first of all let me thank Shad for a really great job. we're lucky to have
you and your contribution.

I hope @conniey will manage the port to xUnit, I truly believe this will
solve the context issues.

I would like to do a major replace with the whole solution to avoid
unnecessary castings (sbyte)
for instance:

from:
if ((sbyte)b >= 0)
to
if (b <= 127)

same all tests are pass, but this is a big change with many files,

when do you think we should do it? after the pr's done or now?

Thanks,


On Sun, Oct 2, 2016 at 10:01 PM, Shad Storhaug <shad@shadstorhaug.com>
wrote:

> Hello,
>
> I just wanted to open this discussion to talk about the work remaining to
> be done on Lucene.Net version 4.8.0. We are nearly there, but that doesn't
> mean we don't still need help!
>
>
> FAILING TESTS
> -------------------
>
> We now have over 5000 passing tests and as soon as pull request #188 (
> https://github.com/apache/lucenenet/pull/188) is merged, by my count we
> have only 20 (actual) failing tests. Here is the breakdown by project:
>
> Lucene.Net (Core) - 15 failing / 1989 total
> Lucene.Net.Analysis.Common - 0 failing / 1445 total
> Lucene.Net.Classification - 0 failing / 9 total
> Lucene.Net.Expressions - 0 failing / 94 total
> Lucene.Net.Facet - (including #188 will be) 0 failing / 152 total
> Lucene.Net.Join - 0 failing / 27 total
> Lucene.Net.Memory - 0 failing / 10 total
> Lucene.Net.Misc - 2 failing / 42 total
> Lucene.Net.Queries - 2 failing / 96 total
> Lucene.Net.QueryParser - 1 failing / 203 total
> Lucene.Net.Suggest - 0 failing / 142 total
>
> The reason why I said ACTUAL tests above is because I recently discovered
> that many of the "failures" that are being reported are false negatives (in
> fact, the VS2015 NUnit test runner shows there are 135 failing tests total
> and 902 tests total that don't belong to any project). Most NUnit 2.6 test
> runners do not correctly run tests in shared abstract classes with the
> correct context (test setup) to make them pass. These out-of-context runs
> add several additional minutes to the test run.
>
> As an experiment, I upgraded to NUnit 3.4.1 and it helped the situation
> somewhat - that is, it ran the tests in the correct context and I was able
> to determine that we have more tests than the numbers above and they are
> all succeeding. However, it also ran the tests in an invalid context (that
> is, the context of the abstract class without any setup) and some of them
> still showed as failures.
>
> I know @conniey is currently working on porting the tests over to xUnit.
> Hopefully, swapping test frameworks alone (or using some of the new fancy
> test attributes) is enough to fix this issue. If not, we need to find
> another solution - preferably one that can be applied to all of the tests
> in abstract classes without too much effort or changing them so they are
> too different from their Java counterpart.
>
> Remaining Pieces to Port
> ---------------------------------
>
> I took an inventory of the remaining pieces left to port a few days ago
> and here is what that looks like (alphabetical order):
>
> 1. Analysis.ICU (Depends on ICU4j)
> 2. Analysis.Kuromoji
> 3. Analysis.Morfologik (Depends on Morfologik)
> 4. Analysis.Phonetic (Depends on Apache Commons)
> 5. Analysis.SmartCN
> 6. Analysis.Stempel (currently in progress)
> 7. Analysis.UIMA (Depends on Tagger, uimaj-core, WhiteSpaceTokenizer)
> 8. Benchmark (many dependencies)
> 9. Demo
> 10. Highlighter (Depends on Collator (which is still being ported) and
> BreakIterator (which we don't have a solution that works in .NET core yet))
> 11. Replicator (many dependencies)
> 12. Sandbox (Depends on Apache Jakarta)
> 13. Spatial (Already ported in #174 (https://github.com/apache/
> lucenenet/pull/174), needs a recent version of spatial4n)
> 14. QueryParser.Flexible
>
> Itamar, it would be helpful if you would be so kind as to organize this
> list in terms of priority. It also couldn't hurt to update the contributing
> documents (https://github.com/apache/lucenenet/blob/master/CONTRIBUTING.md,
> and https://cwiki.apache.org/confluence/display/LUCENENET/Current+Status
> with the latest information so anyone who wants to help out knows the
> current status.
>
> Of course, it is the known status of dependencies that we need
> clarification on. Which of these dependencies is known to be ported? Which
> of them are ported but are not up to date? Which of them are known not to
> be ported, and which of them are unknown?
>
>
> Public API Inconsistencies
> ---------------------------------
>
> One thing that I have had my eye on for a while now is the
> .NETification/consistency of the core API (that is, in the Lucene.Net
> project). There are several issues that I would like to address including:
>
>
> 1.       Method names that are still camelCase
>
> 2.       Properties that should be methods (because they do a lot of
> processing or because they are non-deterministic)
>
> 3.       Methods that should be properties
>
> 4.       .Size() vs .Size vs .Count - should generally all be .Count in
> .NET
>
> 5.       Interfaces should begin with "I"
>
> 6.       Classes should not begin with "I" followed by another capital
> letter (for some reason some of them were named that way)
>
> 7.       .CharAt() should probably be this[]
>
> 8.       Generic types nested within generic types (which cause Visual
> Studio to crash when Intellisense tries to read them)
>
> ... and so on. The only thing is these are all sweeping changes that will
> affect everyone helping out on Lucene.Net and anyone who is currently using
> the beta. So, I just wanted to gather some input on when the most
> appropriate time to begin working on these sweeping changes would be?
>
>
> Thanks,
> Shad Storhaug (NightOwl888)
>
>
>
>
>
>
>

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