Big bed file with more than 256 contigs is handled properly. #520
Conversation
Otherwise it can influence tests that has nothing to do with the data.
|
Build failed due to http-party/http-server#521 and jfhbrook/node-ecstatic#255 |
|
Thanks for the PR @piotr-gawron! Looks like you all are working on backward compatibility right now with the http-server. Once that gets in I can re-trigger the tests and take another look at this. |
|
Dear @akmorrow13, Now travis is failing, but I'm not sure I understand why - is the |
|
Thanks for the update @piotr-gawron ! I added some comments in the review for how you can fix the flow errors. |
|
@akmorrow13, I fixed flow issues. Let me know if you have more comments. |
src/main/data/BigBed.js
Outdated
| } | ||
|
|
||
| // Generate the reverse map from contig ID --> contig name. | ||
| function reverseContigMap(contigMap: {[key:string]: number}): Array<string> { | ||
| function reverseContigMap(contigMap: { [key: string]: number }): Array<string> { |
There was a problem hiding this comment.
It looks like your editor modifier a lot of the spacing/indentation in this file. Would you be able to revert the lines you did not intend to modify?
There was a problem hiding this comment.
Sorry for that.
I reverted the indentation
|
Thanks @piotr-gawron! |
Current implementation of BigBed file doesn't handle properly files with more than 256 contigs. This is due to the assumption that contigs are a flat structure (
pileup.js/src/main/data/BigBed.js
Line 35 in e99848d
This PR resolve the issue by parsing contig tree structure recursively if necessary.
I hope it will meet your coding standards. I couldn't find a way to enforce jbinary to parse dynamic recursive structures (but it might be doable). Therefore, when the situation arises I manually call jbinary to parse nodes recursively.