The crate is now no_std with no breaking changes with default-features.

[Grinkers]

(Edited a second time, after running on real hardware)

This ended up being a lot easier than I expected. The one breaking change is anybody using --no-default-features (likely only me, introduced only recently with sets) probably wants to add --features std.

https://github.com/Grinkers/pico-edn/blob/main/pico-edn/src/lib.rs
It runs on real hardware!

dev-dependencies rely on std, so things get really weird with examples. We couldn't run them anyway, so I think examples should live in a separate repo. Running tests and test coverage is also likely going to be really hard/impractical. We still test everything, logically, with a std env though.

I'll probably write a tiny little lisp that controls some hardware via s-expressions over serial as a more complete example for the org.

I think this is ready. Any thoughts?

[Grinkers]

Rebased and cleaned. Still waiting on 125. sets also work, but json doesn't work. even with the no_std version of regex, it can't target the hardware I regularly use. I'll leave it for now and see what I have for more powerful embedded boards available. A relatively small thing.

[Grinkers]

Update, it's running on real hardware! Fully working project here
https://github.com/Grinkers/pico-edn

It's running on an $0.80 processor with sets. Full deserialization and serialization.
https://www.digikey.com/en/products/detail/raspberry-pi/SC0914-7/14306009

I'm running it on custom hardware, but it should work on a https://www.raspberrypi.com/products/raspberry-pi-pico/

hello edn {:bar 9042.123, :count 1, :foo #{1, 2, 3, 42, }, }
hello edn {:bar 9042.123, :count 2, :foo #{1, 2, 3, 42, }, }
hello edn {:bar 9042.123, :count 3, :foo #{1, 2, 3, 42, }, }
hello edn {:bar 9042.123, :count 4, :foo #{1, 2, 3, 42, }, }
hello edn {:bar 9042.123, :count 5, :foo #{1, 2, 3, 42, }, }

output looks like this via serial

[Grinkers]

Marked as ready, although it has conflicts with #125. It would be nice to get that done first, then I can resolve conflicts that pop up.

@evaporei Additionally, a macro sanity check with edn-derive would probably be good too. derive has dependencies on std but all the underlying std types should be exposed when using the std feature. It should be easy easy to test after evaporei/edn-derive#32

I will benchmark and write details about memory usage after #123, which will include an optimization pass.

btw it should also be easy to compile to wasm now too, if anybody wants to play with that.

[naomijub]

LGTM

[Grinkers]

Actually, edn-derive is in our tests already. Going ahead with the merge.