You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 15, 2021. It is now read-only.
Hello! I encountered this while exploring the use of CBOR as an alternative to JSON for something I'm working on. My project will require moving around a bunch of floating point numbers, and if I can I'd prefer to avoid the precision loss of converting them to text and back as JSON does. Unfortunately, I also can't guarantee that the two sides of the communication will be running the same code, so I need some flexibility to evolve the messages without breaking things. CBOR seems to fit that bill quite nicely!
Hello! I encountered this while exploring the use of CBOR as an alternative to JSON for something I'm working on. My project will require moving around a bunch of floating point numbers, and if I can I'd prefer to avoid the precision loss of converting them to text and back as JSON does. Unfortunately, I also can't guarantee that the two sides of the communication will be running the same code, so I need some flexibility to evolve the messages without breaking things. CBOR seems to fit that bill quite nicely!
However, I did find something odd:
The enum test fails with this error message:
thread 'test_roundtrip_cbor_enum' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorImpl { code: Message("invalid type: floating point `3`, expected f64"), offset: 0 }', tests/criterion_tests.rs:559:32
As a workaround, removing the tag from the enum allows it to deserialize just fine.
The text was updated successfully, but these errors were encountered: