Zac Berkowitz

I'm having the same issue as @rnestler with a STM32L071RTZx and disabling double buffering per his patch seems to fix it for me as well. This problem is forcing me...

Is it possible to have it as a library option so that upstream crates like `cargo-flash` could add a command-line argument like `--disable-double-buffering` that would flip the switch? Having it...

I followed `serde_json`'s lead and abstracted out the formatting. Then added "to_slice_pretty", "to_vec_pretty" and "to_string_pretty" functions (as well as *_with_format versions if one wanted to define their own formatter) using...

I can build up some comparisons over the next few days to explore things like that. Anything else you'd like to see besides binary size? Would size be a good...

I think it's a no-go as implemented in my fork. Some quick tests show some sizable increases in binary size for armv6m targets using the "compact" version of the formatter...

I took another stab at it: https://github.com/rust-embedded-community/serde-json-core/compare/master...berkowski:serde-json-core:pretty-print2 - Added an optional "pretty-print" feature - Moved serialization macros into their own module for use with both serializer options - Modeled pretty-print...

Thinking on and off about this. I haven't looked too closely to the internals of Tokio/Mio but my first impression is.... maybe. You could try modeling some new traits after...

Need a bit more information, but it looks like maybe you're trying to cross compile and it's trying to link against libudev.so on the host instead of the target?

It's certainly possible, though the actual low-level file handle work in windows should be taken care of by upstream `mio` code. I'm in the middle of bringing tokio-serial up to...

There was a possible double-drop in mio-serial for windows that has been addressed in the latest round of cleanup. If you're still interested, please try against the latest 5.4.0-beta on...