search

dib-lab / kProcessor

kProcessor: kmers processing framework.
https://kprocessor.readthedocs.io
BSD 3-Clause "New" or "Revised" License
11 stars 1 forks source link

Major Updates #27

Closed mr-eyes closed 5 years ago

mr-eyes commented 5 years ago

Highlights changes:

  1. Added an overloaded kDataFrameMQF constructor to take hashing mode.
  2. Added QHasher class for hashing the Qs.
  3. Integrated kmerDecoder to parse sequences files and strings.
  4. Modified a lot of functions that depend on Seqan to use kmerDecoder instead.
  5. Major Enhancements in the Python interface.
  6. Added kDataFramePHMAP for allowing very small kmer sizes.
  7. Modified the kDataFrameMAP to store sorted kmers.
  8. Added Python docs.
  9. Added Python test cases.
  10. Splitted the kDataFrame.cpp into separate files.
shokrof commented 5 years ago

Please make the pull request to the development branch not the master

shokrof commented 5 years ago

@mr-eyes

mr-eyes commented 5 years ago

Please make the pull request to the development branch not the master

You can safely merge now. Sorry, I have created the PR to the master as the kmerDecoder branch was not behind the development branch.

shokrof commented 5 years ago

I dont want to merge it to the master. the master branch is for releases only.

drtamermansour commented 5 years ago

We do not have any releases yet. The more we commit to development, the more it gets diverge from the master. I think we should try to merge all working code into the master to get one working release before we start new developmental branches

shokrof commented 5 years ago

I dont see a problem for the development branch to be away of the master. We should merge the development to the master once for every release and I will do it after finishing release 1. Furthermore, It makes no sense to merge to the master the kmer decoder while I am still developing on the development branch. what if the changes that Mohamed did makes conflict with my development.

drtamermansour commented 5 years ago

There is a confusion here. I mean that we should not keep a separate development branch until we have a release. For now, we have to merge kmerDecoder into development. But we should merge development itself into master ASAP.

shokrof commented 5 years ago

I agree with you.

shokrof commented 5 years ago

@mr-eyes you can merge development branch to kmer decoder and then do the pull request

shokrof commented 5 years ago

@mr-eyes good job

shokrof commented 5 years ago

Did you make tests for kmerDecoder ?

mr-eyes commented 5 years ago

@shokrof Thank you. The kmerDecoder tests will be implemented soon in its own repoistory. In the kProcessor, All the tests have passed after kmerDecoder integration to the functions that depended on Seqan.

drtamermansour commented 5 years ago

Congratulations!

ctb commented 5 years ago

Just to weigh in on the merge stuff, the goal should be to keep the PR merge-able, not necessarily to actually merge - you can do this by pulling in the master branch routinely.