GitLab

See #2732.

See #2989.

Now with TAP_TEST[(]\([^()&]*[(][^()&]*[)]\)
See #2989.

sed -i "s/TAP_TEST[(]\([^()&]*\) == \([^()&]*\), /TAP_TEST_EQUAL\(\1, \2, /"
with some manual checks.

See #2989.

Begins #2989.

Closes #2919.

I wonder whether TAP_ADDITIONAL_INFOS is actually used.

Windows can be either shortened or shifted.

See #2987.

Follows !141.

Not necessarily useful, but it's good to know.
See #2986.

Close #2983.

Dynamic window length and position

Closes #2913

See merge request !141

We add a `-r 1` parameter to output all the windows in the JSON. This helps us
to ensure that all “tuned” windows are properly warned in the JSON output.

See #2913, #2916.

(edited by @magiraud following 6e18874d)

We make sure that the output specifies that some sequences are segmented with
a “tuned” window.

See #2913

Warn when we have one.

This requires to add a new segmentation status. The problem is that
Segment::getSegmentationStatus() returns just an integer which doesn't make
possible to have several statuses at once (which could be convenient). A
solution would be to use masks for the statuses (ie. if s is the status we
would store 1 << s).  Since this would require quite some code modification to
achieve that, I added some extra tests (that's bad) to deal with the case
where the segmentation is achieved with a shorter or shifted window. In such a
case we warn the user in the JSON (warning on the CLI should be done too).

See #2913, #2916.

It is good to know so that we can warn the user.

See #2913

It was hard to make some tests (eg. unsegmentation-causes.should-get) have a
too short window. Modifying a constant just so that the test passes is bad
practice, but this is not the case here (at least I believe so).  Having
difficulties to have a too short w also meant that in practice we would almost
never see a “too short w” again. This could be nice. But we know that the
position of the window is not accurate (it is not designed to be). Therefore
20nt, if they are perfectly centered may be ok. But we know that it may not be
well centered (and we even allow some shifts). Therefore 30nt seems to be a
safer limit.

See #2913

The software should return the proper segmentation even without telling it that we are on TRG.
That is all the more important as we now segment short sequences.

(edited by @magiraud following 6e18874d)

All sequences are now properly segmented. We even have twice the same CDR3.
We update the average lengths accordingly.

We also now tests for the forward and reverse segmentation.

The sequence has been shortened and the tests updated accordingly.

If the window size if less than the maximum provided we do not
allow any possible value. This allows to round down the value to
the closest multiple of shift.

In case of strange values, just return a (0,0)

If an user chooses to have a very small window, we should not forbid it.

See #2913

Most of the time the window will fit in the read. We want to avoid extra computations.

Moreover this is the only case where the shift will be 0.

This computation is done in constant time.
This will be used to adapt dynamically the window if we don't have enough space to put it
(see #2913).

The should-vdj test fails for reasons unrelated with this issue.
Thus we have to get rid of this should-vdj test (see #2767 for that matter)
and only test what we want here: that the clone is properly segmented

See #2910

See vdj#512.