-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make no_std
into an optional feature on protocols
crates
#932
Conversation
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
🚨 2 ALERTS: Threshold Boundary Limits exceeded!
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
🚨 9 ALERTS: Threshold Boundary Limits exceeded!
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
no_std
as an optional feature on protocols
cratesno_std
into an optional feature on protocols
crates
bfec4ff
to
dc98ab3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not fully sure adding anyhow
is a great solution for our error handling.
We could maintain different errors internally and expose one single error that maps to the rest. Our minimum for adding a new crate should be more than "it makes this thing slightly easier", in this case its preferable to write our own code.
Disadvantages of adding anyhow could be: slower compiling time, we could be imposing anyhow
for downstream users, its more appropriate for app layer..
that's actually a good point, and @rrybarczyk just made a similar argument just a while ago. |
A little late to the party, but as @plebhash pointed out, I also think we should handle our own errors in the roles rather than using |
I'm trying to unblock #985 (comment) and it seems that this (amongst other reasons) is a blocker there. regardless of |
dc98ab3
to
f7ef878
Compare
Many of the low level libs under
protocols
areno_std
. That is great, since it allows for potential firmware integrations usingrust-embedded
and targets without MMUs (e.g.: Xtensa ESP32, ARM Cortex-M, etc).Some projects in the community even have some potential to leverage SRI
protocols
crates for firmware integration, e.g.: https://github.com/bitaxeorg/esp-miner-rsHowever, for most common deployment scenarios (e.g.: x86-64), high level application code (e.g.:
roles
) has no hard requirement forno_std
. Also, having it as a mandatory feature becomes a blocker to many desirable changes.