GitLab

Thanks to landscape.io

Thanks to @mikael-s.
Closes #2253.

Why can't we keep complicated stuff when there exists really easy solutions?

The purpose is to test consistency of the segmentation with 1, 6 and 11 reads.
Instead of generating the data on the fly we can store the most abundant datasets
and use the magic -x option (see 7b314b61) to restrict the dataset to fewer
sequences.

This will solve some compatibility issues as this test could have some troubles
working on some architectures.

See #1580.

See #1580.

As the D is short (with one error), we provide the three
possibilities. Follows d89f52d8

See #2249

Follows 81ac715d.

Follows 81ac715d.

Following f78c6fc3, name these constants in a positive way,
as we report these unsegmentation cases.

With the previous changes, one may have e-value computations on short sequences,
leading to a possibly negative number of k-mers in getProbabilityAtLeastOrAbove().

Fixes #2107.

We set a meaningful e-value.
Moreover, after closer inspection, we find that one sequence may be a genuine 'only V'.

See #2107.

Now that we check e-values to get UNSEG_ONLY_V/J status,
an e-value of 1.0 is not meaningful here.

See #2107.

There were previously two places where the segmentation could fail with UNSEG_ONLY_V/J.
The first one, when there is no 'good' segmentation point, was improved by 5298c86f, requiring at least 5 k-mers.
It turned out that it was not sufficient, as reported by @flothoni in #2107.

Contrarily to what what thought in 5298c86f, the segmentation point returned by kaa->getMaximum()
is actually meaningful to compute some e-values, even when kaa->getMaximum().max_found is false.

We thus now remove completely some ancient code where the thresholds were based on the number of k-mers,
and rely solely on checkLeftRightEvaluesThreshold() to discriminate between these unsegmentation causes.

Streamlines the code, and will fix #2107.

Opens #2107.

Vidjil is now as efficient as a 'sort | uniq -c'.
Fixes #1642.

See #1642.

See #1642.

See #1642.

One-letter variable names are not very convenient to work with.

We could have a leak of some bytes

Prevent valgrind to be launched on this test (ie. valgrind on valgrind)

Completes 06ada6e9.

We use this more friendly wording instead of 'representative' for quite some time.
See for example e0d8420c, 02b4bc6d, a7aaee81, d445eca5.

Cosmetic change.

Fixes #2239.

Confirms #2239.

Useful when viewed through web interfaces (e.g. on Gitlab/Github).

Otherwise comments could be ignored.

Some architectures fail on that test because of errors in
libstdc++ on some architectures. We ignore those errors.

Follows 5d910513 and related to #1824

Following cbcff399 ?