Jacob Lifshay

imo if we're adding `FRAC_1_SQRT_2PI` we should also add `FRAC_1_SQRT_TAU`

one related feature that could also be useful is to have a setting to quit casparcg when the producer has finished playing. idk if that's already implemented.

one objection to naming the attributes `#[blocking]`/`#[nonblocking]` is those are ambiguous since different people have different ideas of what to consider blocking or not based on which domain they're working...

> * rtsan(*) I think we shouldn't name stuff after the verification mechanism, since that could be changed/extended to use something other than rtsan. maybe name it `hard_realtime()` since that's...

> > I think we shouldn't name stuff after the verification mechanism, since that could be changed/extended to use something other than rtsan. > > Seems reasonable to me! Thanks...

I think you should use `IntoFuture` instead of `Future` here, since it will allow passing more functions as `impl async Fn(..) -> ..` and will also allow the idea for...

it just occurred to me that we may want to mark derive macro helper attributes `unsafe` instead of (or in addition to) the derive macro: ```rust #[proc_macro_derive(MyDebug, attributes(unsafe(debug_deref)))] fn my_debug...

what happens when you have `v.len() == 16`, `v.capacity() == 32` and you do: ```rust for _ in 0..1000 { v.shrink(); // now capacity == 16 v.push(1); // has to...

for comparison: `num_bigint::BigUInt` shrinks when `len() < capacity() / 4`: https://docs.rs/num-bigint/0.4.6/src/num_bigint/biguint.rs.html#866-868

> So we'd like to know how often this comes up, what it is used for and which heuristics were used when this was implemented manually. one use case that...