Skip to content

Conversation

@tsibley
Copy link

@tsibley tsibley commented Sep 24, 2014

A fixed window size provides a stricter control on average base qualities for datasets with a wide range of read lengths.

Note: this depends on my previous branch (PR #34) and so contains those commits as well. Only the tip commit is the feature-adding one.

Standardizes on --truncate-n.

This preserves the --trunc-n long name previously mentioned in the SE
usage.  It removes the --discard-n long name only ever used internally,
but never documented.
This will help keep them in sync when updating options.
No functional change, only whitespace (compare with git diff -w).
The usage docs now indicate option arguments and are easier to read.  If
the usage was specifically requested with --help, then it is printed to
stdout instead of stderr.  This is useful for the common idiom of asking
for help and piping to a pager like less or more (without redirecting
stderr).
Silences warnings about //-style comments and long strings.

Since kseq.h uses inline functions, a feature of C99, it's not useful
pretending to be C89 compat (GCC's default).
A fixed window size provides a stricter control on average base
qualities for datasets with a wide range of read lengths.
@tsibley
Copy link
Author

tsibley commented Feb 25, 2015

@najoshi I've also updated this PR to be based on top of #40 instead of #34.

@tsibley tsibley changed the title Optionally use a fixed window size instead of 0.1 of the read length [3/4] Optionally use a fixed window size instead of 0.1 of the read length Feb 25, 2015
@tsibley
Copy link
Author

tsibley commented Jun 12, 2015

@xapple That's up to @najoshi, who seems to be pretty out of touch with the Github issues/PRs. You can always use the @MullinsLab sickle fork if you want, which does have this PR merged into it.

@xapple
Copy link

xapple commented Jun 12, 2015

OK That's cool, maybe I'll try it out. But if you have forked and added features etc. you should definitely bump the version number and have sickle 1.34

@tsibley
Copy link
Author

tsibley commented Jun 12, 2015

No, I'm not going to version our fork in the same space as @najoshi's. That would lead to much confusion.

I did change how the version is displayed, however: MullinsLab@4b0dc85

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants