Release of 0.4.0

[sstadick]

Hello! Is there a timeline for cutting the 0.4.0 release? Specifically I'm finding the read_record_set_exact functionality to be extremely useful.

[markschl]

Thanks for the interest in this feature, unfortunately I'm quite busy right now with other work. I did a lot more refactoring since the first 0.4 alpha release, trying to move towards a more general library that would make it possible and easy to implement additional sequence formats. However, that also makes it more complicated conceptually, which is why I got stuck somehow. I don't think I'll be able to have a stable version within less than three months (which may be even too optimistic). I'll try with another alpha release first...

For 0.4, I wanted to offer read_record_set_exact to allow reading paired end reads. I guess if that feature is important to you just now, it might be an option to add it to v0.3.x. It should not be too difficult to do, it needs a few modifications in fastq.rs and also fasta.rs. I would be happy to accept a PR or could try to implement it by myself.

[nh13]

@markschl any updates on a release with read_record_set_exact included? We find it incredibly useful but want to rely on a published release versus a specific hash. Would a contributed PR still be on the table?

[markschl]

@nh13 I'm sorry, I'm still nowhere near a second alpha release due to lots of other work, so a final 0.4.0 release will definitely take some time. Also, there will probably be several API changes, so I wouldn't rely on 0.4 alpha.

I would certainly be happy about a PR to the v0.3 branch with a read_record_set_exact implementation. If I'm not mistaken (haven't looked into the code for some time now) it's only necessary to turn this loop into a for loop counting up to the desired number of records.

[markschl]

@nh13 I had a look at the code again, and especially for the FASTA module it's a bit more complicated because the RecordSets are being reused. Also, it has to be kept in mind that the buffer may not always contain the requested number of records. In order to guarantee an exact number of records, the code if !try_opt!(self.find()) {...} needs to be replaced with if !try_opt!(self.find()) && !try_opt!(self.next_complete()) {...}. The desired number of records may still not be achieved if the end of input is reached (in which case the given condition will be false). Therefore, it could be a good idea to return number of records from read_record_set_exact (unfortunately, read_record_set returns nothing). It may be an important information for users to know.