i did manage to get a flamegraph using dtrace, despite imprecations from macos that i’m running an unsupported configuration (sheesh)

it turns out that rust is not a lazy language, so if you write first_thing().or(second_thing()) both things happen 🤪 or_else() is my friend 🤓

nice, my code can parse leap-seconds.list and verify the checksum and many other sorts of cromulence and print out a new version of leap-seconds.list, and re-parse it, and get the same answer

bah conflicting implementations of trait `std::convert::TryFrom<&str>` for type `std::vec::Vec<leapsecs::LeapSec>`:

hmm and i can’t impl FromStr either because Vec<LeapSec> isn’t defined in my crate even though LeapSec _is_ defined in my crate

yeah i think i’ll just wrap the vec in a tuple struct because i’ll want to define a bunch of other methods on it

i’m currently refactoring my error handling and it’s kind of boring 😴

ooh looks like the code is working again it’ll be a fairly chunky commit tho

std::convert::TryFrom has an associated type called Error and std::str::FromStr has an associated type called Err 🦀oops🦀

hmm, i have both a binary and library target in this crate, and cargo runs all the tests for each target, so it runs the tests twice can’t see if there’s a cfg attribute for targets so i can disable them in the source tho i can turn off the lib tests in cargo.toml