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

you must be found something a bit odd, u don't get that problem

i think i'm linking the binary target with the library in a strange way - i'm declaring the modules in both lib·rs and main·rs because i had some trouble using the lib in

Yes, that's basically #include'ing the tests over again. You *should* be using the lib crate as any other client application would. In what way were you having trouble before?

can't remember now :-) it was some kind of name collision i'll revisit it when i have the functionality closer to working, still a lot of cleanup needed in many places

ok thanks :-) i think the main clue i missed was that i needed to use the lib as if it were another crate