Closed petrelharp closed 2 years ago
...either a bug or SLiM does always put the most recent mutation first.)
I'm not sure whether that is guaranteed. It might be different for new mutations added by SLiM itself versus those added by addNewMutation() / addNewDrawnMutation(), and I'm not sure how removeMutations() might affect things. This could of course be checked, but I don't have time to get into it right at the moment. Might be easiest to determine empirically, rather than by looking at the code. :-> But then of course there is also the question of whether SLiM guarantees any particular behavior, or whether whatever it does right now could change in the future without a "breach of contract". I would lean towards the latter, especially since neither of us actually knows what the "contract" might be, and it might be inconsistent, and so forth. I don't think there's any "contract" in this area.
Codecov hasn't run for some reason (I've just added the action to github), but I've run it locally, and it looks good.
Merging #299 (f3cd117) into main (9bc27db) will increase coverage by
0.15%
. The diff coverage is95.77%
.
@@ Coverage Diff @@
## main #299 +/- ##
==========================================
+ Coverage 95.44% 95.59% +0.15%
==========================================
Files 8 8
Lines 724 613 -111
Branches 145 127 -18
==========================================
- Hits 691 586 -105
+ Misses 22 18 -4
+ Partials 11 9 -2
Impacted Files | Coverage Δ | |
---|---|---|
pyslim/provenance.py | 83.78% <ø> (-4.73%) |
:arrow_down: |
pyslim/slim_metadata.py | 96.17% <93.80%> (-3.83%) |
:arrow_down: |
pyslim/methods.py | 97.39% <96.41%> (-2.61%) |
:arrow_down: |
pyslim/slim_tree_sequence.py | 98.11% <97.29%> (+3.77%) |
:arrow_up: |
pyslim/_version.py | 100.00% <100.00%> (ø) |
|
pyslim/spatial.py | 87.23% <100.00%> (-12.77%) |
:arrow_down: |
pyslim/util.py | 100.00% <100.00%> (ø) |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
Over in https://github.com/popsim-consortium/stdpopsim/issues/1334 we found out that
convert_alleles
is taking way too long. I had a try at changing it to usemetadata_vector
(in this PR); however, there's no appreciable change in speed. (However, note that at least I noticed that the complicated stuff I was doing had no effect - either a bug or SLiM does always put the most recent mutation first.)