GitLab

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

The loop was poorly conceived. Doing the work the other way makes more sense

Strings like "toto" are const char *, therefore the list must be told
to store const char * instead of char*

This should not be hardcoded.

This streamlines the code to initialize and display the statistics.

-auto compute reads_segmented with currents systems selected by user
-active/unactive windows

-doesn't create any new timepoint
-require files with the same number of timepoint

- compute analysis file using database information and stored file.analysis file

The method computes the maximal affectation

Those affectations are useful in several case. Thus it is convenient
to have a method, with the same names, in each affect to retrieve the ambiguous
and the unknown affectations. That makes it possible to get them when
dealing with affect templates

- bug if V gene name is not found in the germline

- filter unvisible node