-
Notifications
You must be signed in to change notification settings - Fork 518
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
Defensive
ops API design
#221
Comments
Please, go ahead :) |
So after some experimentation, I've hit the following blockers:
TLDR is that this can't be done in a backwards-incompatible way (afaict on a Friday night 😛). If I'm missing something, please let me know! Otherwise, if this refactor is deemed worthy of a breaking change (which IMO it is, lest these traits get even larger and more unwieldy) then I can open a PR with the changes and relevant fixes. (mostly just replacing |
Arithmetic crates like num_traits should support big nums, so they should pass by reference. You might as well pass by value if you're just trying to be even more precise than regular Rust about how you handle u64s. |
IMO, the traits should take their parameters by reference, since the traits should be usable by types that aren't
|
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
* Add Prometheus and Grafana to Docker Compose * Expose relay's Prometheus metrics port * Use Docker network references intead of localhost When you have containers on the same network they don't communicate over localhost, they instead refer to their container names * Move dashboard components into deployment folder * Update folder structure for Grafana and Prometheus config files The new folder structure more closely matches the expected defaults by Grafana and Prometheus, which allows us to clean up the paths in our docker-compose file a bit. * Add documentation about Prometheus and Grafana * Refer to Prometheus server instead of node
The current API design for the
DefensiveSaturating
trait isn't great - it's unnecessarily monolithic. It should be split into several smaller traits, and thenDefensiveSaturating
can be retained as a super trait so this won't be a breaking change.I propose
DefensiveSaturating{Add,Sub,Mul}
, and thenDefensiveSaturatingInc
as a super trait ofDefensiveSaturatingAdd + One
andDefensiveSaturatingDec
as a super trait ofDefensiveSaturatingSub + One
. This will allow users more granular control over the functionality they need, and removes this issue: https://github.com/paritytech/substrate/blob/master/frame/support/src/traits/misc.rs#L367-L368 (why does a type need to meMul
to usedefensive_saturating_sub
?)I'm happy to implement this if it's accepted 🙂
The text was updated successfully, but these errors were encountered: