GitLab

Revcomp directly on an integer.
Tests added

Was done in IKMerStore but we should provide it as a tool. Now IKmerStore uses the function dna_to_int.
Tests added.

Use bitwise operations which avoids branching with if/switch.
Tests added

Curiously, omitting this case make fail only some unit tests, but no should_get tests.
What does this 'else' case mean ? Is it really used in Vidjil ?

The previous IKmerStore.getResult() (still used in MapKmerStore) had several string malloc/free through spaced(), accounting for a good part of the total time of the heuristic.
This implementation should be faster.

Thanks Mikaël for the solution of the C++ template nightmare :)

Variables removed from affect_infos_s. Can't be tested anymore

Conflicts:
	server/fuse.py

This should be done with a more generic way:
There should be a unique place to store the definition of (pseudo-)germlines.

When removing common substrings, the results was sometimes hard to understand, especially with numbers
(15-bla48 97-bla84 -> 1548 9784, now 15-48 97-84)

An address was displayed in windows.fa, because of
os << windowToStream…

With short V sequences (particularly in pseudo germlines), the sequence we were retrieving
at the end of the V could be longer than what the V length actually was.

Only results.before_left and results.after_right are signifiant to assert the segmentation

No worries this comes from the fact that this tests uses a very large
window. Therefore a slight modification of the segmentation may shift the
segmentation to the right and may prevent from getting a window.

There were several cases with an affectation like that one:
+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V ?+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V ?+V+V+V+V+V+V+V+V ? ? ?+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V ?+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V ?+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+V _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+V _ _ _ _ _ _ _ _ _+J+J ?+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J ?+J+J+J+J

Where the last +V was not taken into account with the previous heuristic, but
was with the current one.

These are borderline cases. The cases were just at the border
of the acceptance (for delta_max) with the previous implementation.
Now they're rejected (because of the correction explained in e57c515)

It happens when we have V and J labels but when we're not able to segment because one
of the criteria on the number of V compared to J is not fulfilled

While CountKmerAffectAnalyser is more flexible, the heuristic implemented
in KmerAffectAnalyser is more efficient, that's why we use it in the KmerSegmenter

The new heuristic gives position 9 from the end of the V which
makes more sense (it is the last position in the V that is not shared
with the J). Conversely, for position 19, it corresponds to the first
position in the J that is not shared by the V.

When the k-mer ends at the position we're considering, it
should be taken into account by default.

This constructor is only dedicated to testing. It does not make sense to use it otherwise.

Thanks Mathieu

Now we require that we have <before> (resp. <after>) affectations
before (resp. after) the maximal positions, to avoid false positives.

To define a maximum, make sure that we have some before'' affectations
before the position and, conversely, that we have some after'' affectations,
after the position

-maybe add timestamp ??