-
Notifications
You must be signed in to change notification settings - Fork 212
Comparing changes
Open a pull request
base repository: rust-bio/rust-bio
base: v2.3.0
head repository: rust-bio/rust-bio
compare: v3.0.0
- 5 commits
- 50 files changed
- 9 contributors
Commits on Jul 11, 2025
-
refactor: removed lazy_static! dependency and cleaned up scores (#639)
* cleaner version of scores * refactor: remove lazy_static + clean up scores * clean * use std lazylock * Update MSRV to 1.80 * Update README.md with updated MSRV --------- Co-authored-by: Felix Wiegand <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a56a02a - Browse repository at this point
Copy the full SHA a56a02aView commit details
Commits on Sep 19, 2025
-
refactor: Clippy warnings caused by legacy numeric constants (#644)
* fixed clippy warnings caused by legacy numeric constants * correct formatting
Configuration menu - View commit details
-
Copy full SHA for 0a36bcf - Browse repository at this point
Copy the full SHA 0a36bcfView commit details -
feat!: improved API and internals for pattern_matching::myers and add…
… LazyMatches::dist_at() (#640) This PR includes some changes to the `bio::pattern_matching::myers` code. The initial motivation was to improve the [pattern matching feature](https://markschl.github.io/seqtool-docs/find/#approximate-matching) in [this](https://github.com/markschl/seqtool) sequence handling tool, but I ended up also including some code from refactoring efforts that I actually started some years ago already. Summary: * Added a `LazyMatches::dist_at()` method complementing the already existing `hit_at`, `path_at`, etc. (e318e4c) * Refactoring of code that computes the alignment path (traceback) with the aim to make it more understandable (f8d1f89, 53d177b, be1e35c). The methods of the `TracebackHandler` trait were changed (code re-grouped), but the behaviour should not have changed (alignment paths found to be correct with fuzzing). In addition, there are many additional doc comments, and some more references to the Myers paper. A small deviation from the paper in `long.rs` (no padding with wildcards) is more clearly documented. I looked at this again, but I can't find any issues with my approach. The fact that the simple and block-based implementation yield the same results (with fuzzing, comparing single u64 or u128 with multi-u8 block version) further suggests there are no issues with this code. * The fuzzing code was extended to also test ambiguities and wildcards and include a comparison to Edlib (commented out to avoid introducing another dependency) (f8d1f89, 97104c2) * Fixed two small bugs: 1. Fix panic in `LazyMatches::...at()` methods if called with an end position for a match with distance > k (e318e4c) 2. fixed panics with very large `max_dist` (`...::long::Myers::distance()` did always panic) (5445989) * Updated the documentation, also improving the module descriptions, which were partly outdated (not adapted to the block-based implementation) (1d39dec). A small change to the `ukkonen` docs was also made (1a7432d) * Some performance evaluations (thereby simplifying the benchmark code, 47f8fe6), added some `#[inline]` (b383561), although I had to remove one again due to some performance regression I don't fully understand (694f573). Bottom line: `Myers::find_all()` appears faster now, everything else is equally fast. * Fixed some small warnings in other `pattern_matching` modules (298b1f9). I checked that it compiles under Rust 1.65.0, although I had to downgrade to multimap 0.10.0 for this. * Updated the copyright notice in mod.rs with my name (1d39dec) (hopefully fine like this, otherwise I can adjust) * Slightly changed the behaviour of `MyersMatcher::ambig()`, allowing it to be called multiple times on the same symbol (3be7543) Possible remaining issues. * The inlining of `fn next...()` is now a little inconsistent, unfortunately (due to 694f573) * I'm not entirely sure if the term *linear-time* in `pattern_matching/mod.rs` still applies for the block-based algorithm, which is O(nk). If k is kept constant, then time scales linearly with text length (which would also qualify the Ukkonen algorithm as being linear-time). Thanks for considering this PR! --------- Co-authored-by: markschl <[email protected]> Co-authored-by: Johannes Köster <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 122a44d - Browse repository at this point
Copy the full SHA 122a44dView commit details -
feat: Added BEDPE file support (#631)
Added [BEDPE](https://bedtools.readthedocs.io/en/latest/content/general-usage.html#bedpe-format) files reader and writer. The code was copied from `src/io/bed.rs` and slightly modified, as such the tests are nearly the same and `cargo test` passed. --------- Co-authored-by: Johannes Köster <[email protected]> Co-authored-by: Johannes Koester <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 61adf2a - Browse repository at this point
Copy the full SHA 61adf2aView commit details -
chore(master): release 3.0.0 (#646)
🤖 I have created a release *beep* *boop* --- ## [3.0.0](v2.3.0...v3.0.0) (2025-09-19) ### ⚠ BREAKING CHANGES * improved API and internals for pattern_matching::myers and add LazyMatches::dist_at() ([#640](#640)) ### Features * Added BEDPE file support ([#631](#631)) ([61adf2a](61adf2a)) * improved API and internals for pattern_matching::myers and add LazyMatches::dist_at() ([#640](#640)) ([122a44d](122a44d)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Configuration menu - View commit details
-
Copy full SHA for 14c0425 - Browse repository at this point
Copy the full SHA 14c0425View commit details
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v2.3.0...v3.0.0