Async API #214
Async API #214
Conversation
|
As usual the circleci pipeline files (would be nice if it's removed at some point :p; @eldruin hope you don't mind me giving a ping as i don't know if you already notifications in new PR's :) |
.github/workflows/ci.yml
Outdated
| @@ -29,15 +29,17 @@ jobs: | |||
| - run: cargo test --doc --target x86_64-unknown-linux-gnu | |||
|
|
|||
| test-msrv: | |||
| name: build with MSRV | |||
| name: test with MSRV | |||
There was a problem hiding this comment.
I would prefer to only build with the MSRV and test with stable like it is currently done because we have a significant number of dev-dependencies and so it is quite probable that these will break the MSRV test although the failure is not related to this library.
There was a problem hiding this comment.
Happy to do so; but mind that with these patches the only dev-dependency on x86 left is embedded-graphics itself; Which is a lot more tractable then all the bigs required for arm (which is primarily for the examples)
There was a problem hiding this comment.
@eldruin sorry the previous message was meant to ask if you'd reconsider with that background :) Fwiw the main thing we do test with MSRV in this case is the doctest which imho is useful (and should really work with the MSRV)
If you'd still prefer to just build with MSRV then i'll do that change
There was a problem hiding this comment.
I understand the utility from a software engineering perspective.
This is a matter of differing expectations w.r.t. what MSRV means. As a user, the MSRV means to me: can I use it as a dependency?
If the doctests do not compile anymore due to changes in MSRV in, say, embassy, does it mean that this crate must change its MSRV? I would say no. The ecosystem around it changed but this crate or its actual dependencies did not.
It should be noted that there are a whole bunch of dependencies that need to be compiled for this.
What do you think?
There was a problem hiding this comment.
Right my point was that with the changes i've done for x86 the only dev-dependency left is embedded-graphics itself (which any users is expected to also use).. So the whole bunch of crates is essentially the same betweenthe test and a build a user will do :)
There was a problem hiding this comment.
I see. Sorry, I missed that change.
There was a problem hiding this comment.
Hah; Well i rolled it back now as i didn't see the point in blocking on this for longer :) Happy to send a quick follow-up pr to re-introduce testing in ci if you changed your mind ofcourse
Ofcourse; e.g. the async-i2c-spi example running on a breadboard async_i2c_spi.mp4 |
Only add dev-dependendencies that are needed for the example on arm targets as they're not needed anywhere else.
That's for you to judge! but from my point of view yes |
use maybe_async_cfg to add an async interface as well, enabled by the "async" feature. When enabled an Ssd1306Async struct is added with the same api as Ssd1306, only async.
eldruin
merged commit ad2f001
into
rust-embedded-community:master
Could you bump version as well? |
|
I have just released this in version 0.9.0 |
Hi! Thank you for helping out with SSD1306 development! Please:
masterif you're not already up to dateCHANGELOG.mdentry in the Unreleased section under the appropriate heading (Added, Fixed, Changed, etc)rustfmton the project withcargo fmt --all- CI will not pass without this stepPR description
Add async support to crate; API stays the same just async