Nelson Earle

I agree that hat selection should be a step before being ready. I'm going to start work on this if there's no concern about this approach.

> Maybe it's logged to stderr instead of stdout and that's why piping wasn't working? Yep, you can do this to pipe the logs: ```sh ./target/debug/jumpy 2>jumpy.log ```

@zicklag I've been trying to cut down on duplicate dependencies, but a lot is blocked by crates using different (old) versions of crates. I was able to get a couple...

I'm stumped on this one. For revisions that have this error ([cca4233](https://github.com/fishfolk/bones/commit/cca42339951e2960c668ae2856b1d8c8513f0ad2) and before) `cargo b --workspace` succeeds, you only see the error with `cargo b -p bones_matchmaker`. I think...

@zicklag thanks for weighing in. I think I ran into that issue once already 😆 My first push had some failing tests and it looked like it was because of...

I've been giving this issue some thought,,, > Maybe we need to differentiate specifically between missing input in stored settings and write default, and a none input that was set...

Yeah, totally. I kept flip-flopping between that idea -- resolving mappings up front into a struct -- and the one I fleshed out more in the comment above -- resolving...

I also wonder if there's any caches we can combine? I don't think we can do that with any of the target-specific ones (x86 & wasm32) but like the check...

I recently ran into this issue with similar logs: ``` 2024-10-21T01:04:35.770888Z ERROR bones_framework::logging: A panic occurred panic.payload="called `Result::unwrap()` on an `Err` value: TryFromIntError(())" panic.location="/Users/nelson/.cargo/registry/src/index.crates.io-6f17d22bba15001f/mdns-sd-0.10.5/src/service_info.rs:633:39" panic.backtrace=disabled backtrace panic.note="run with RUST_BACKTRACE=1 environment...

This problem originates from `bones_framework`, see tracking issue [bones#485](https://github.com/fishfolk/bones/issues/485)