Max Blachman

Per-probe features seems excesive. Here's the API I'm imagining. `autocfg::set_feature(&mut self, &str feature)` which adds ```rust #![feature(example_feature)] ``` at the start of all probes as you described. But setting features...

Changing `SPI_DRIVER_SELECT` to 1 does indeed allow the SdInfo example to run, working as expected, on my Arduino Nano Every. Thanks. Regarding the SPI default driver, that sounds good to...

I think normalizing after each operation is the way to go here. Also, is this a good definition of normalized? - positive denominator - fully reduced (p/q) - p and...

Thumbing through the code, it indeed appears as if every ratio is reduced after an operation on it. If this is the desired behavior, and I think it should be,...

Now that #42 is merged, for any operation, if input `Ratio`s are reduced and the result of an operation is in range for the underlying type, no overflow will occur...

I think we should deprecate it. I was not aware of `std` doing so, but if they did and no one complained (I think?) we could probably get away with...

My sketch can overflow, but that is essentially how it works for `isize`, `i8`, `i16`, `i32` and `i64`. From the source code: ```rust #[inline] fn abs_sub(&self, other: &$t) -> $t...

Okay, I see what you mean. So if I changed that sketch to be the same as the current implementation, like ```rust fn abs_sub(&self, other: &Self) -> Self { self

> If previously-working code now fails to compile, this is a breaking change I generally agree with this, but the only things that fail to compile are the `Into` and...

Hm... I hadn't thought of that. In a language with more dynamic types, I could imagine this not being a breaking change. It would be breaking, but it would also...