handle weird chr in fasta headers - fix issue #32

cbg-ethz / shorah

Repo for the software suite ShoRAH (Short Reads Assembly into Haplotypes)

GNU General Public License v3.0

39 stars 14 forks source link

handle weird chr in fasta headers - fix issue #32 #50

Closed DrYak closed 6 years ago

DrYak commented 6 years ago

Did a quick edit today to handle issue #32 and weird characters in fasta headers.

Questions :

shall I keep this regex-based approach ?
(Or shall I try to make a fasta header name-cleaning routine that removes anything weird)
I've gone using 'rfind' in c++, because regex are missing in the GCC (4.8) used by bio-conda
But I could use boost::regex as a fall-back (see docopt in Haploclique)

DrYak commented 6 years ago

Lastly, we'll also have to pay attention to minor detail between the C++ and the python sides that can come biting us back like the locale causing diverging interpretations of isalnum, \w versus ASCII rule and POSIX [:alpha:]. (Which can also be a problem with printing %f)

I don't know how many people could be running this on their desktops/workstation (hello, French locale !)

ozagordi commented 6 years ago

I tested 0933ede8352fe1dc0f866760a4f3dfa418a65ac7 and it fails when there is a dot in the reference name (I just renamed >reference to >reference.2 in examples/ref_genome.fasta and realigned. The problem seems to be that diri_sampler only creates one debug file and one sampling file without window information: w-reference.dbg instead of w-reference.2-1-201.dbg, w-reference.2-68-268.dbg and so on. Would you please give a look?

DrYak commented 6 years ago

?!?!?

I did exactly that :

seded the reference name to reference.2
smalted a new .bam file according to the README.me
ran shorah amplicon on it (using freshly installed files)
got the expected results.

Are you sure there's no old version of diri_sampler at the wrong part of your search path (cf. your pullrequest #48 not always transferring the files where it should, and pullrequest #51 about searching them) ?

What you see is the behaviour of the old unpatched diri_sampler (using .find('.') instead of .rfind(".reads"), as if you were still having an old version left dangling around.

ozagordi commented 6 years ago

Looks like you are right. I need to check this.

DrYak commented 6 years ago

Tomorrow, I'll rebase and merge if tests pass.

ozagordi commented 6 years ago

You were right. The reason was that in this PR we had the old setup.py that didn't work with meson + pip.

I was trying to address too many issues at the same time and I created some confusion, sorry.

DrYak commented 6 years ago

Rebased against latest master (that includes the latest setup.py). Everything seems to work, as it should.

ozagordi commented 6 years ago

Thanks for the support!