-
Notifications
You must be signed in to change notification settings - Fork 7
chore: Fix tests + Examples, clarify docs #37
Conversation
pros/src/sensors/rotation.rs
Outdated
#[deprecate_until(remove = "1.x", note = "Please use the `set_zero` method instead.")] | ||
pub fn zero(&mut self) -> Result<(), PortError> { | ||
self.set_zero() | ||
} | ||
|
||
/// Sets the position to zero. | ||
pub fn set_zero(&mut self) -> Result<(), PortError> { |
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.
Even though you might consider the name zero
to be against common Rust conventions, I think that set_zero
could easily be confused with set_position
. I don't think that this naming change is good.
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.
Whilst I agree that the naming could be confused with setting the position, I do feel that it does clarify the meaning a bit more since the word zero is both a noun and a verb. I think it might be worthwhile in the long run to adopt either Vex's reset
terminology or PROS's tare
terminology, and have respective reset
/tare
and reset_to_position
/tare_to_position
functions on motors/sensors instead.
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 generally agree with gavin to the extent that "set_zero" is a more confusing name (could be misinterpreted as "set the zero point"). By this naming logic, all device methods should use this terminology (for example, InertialSensor::zero_euler
would be changed to InertialSensor::set_zero_euler
). At the same time using another term like reset_x
would solve both of these problems.
btw, if you want all floating point math functionality on libcore only, |
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.
Don't deprecate the zero
function on motors and re-export abs from num instead of writing your own.
The abs trait I made compiles to the same assembly instruction as the std abs function on most targets (see this post for more info). I think that what I have is a much more lightweight solution to this, and again, this is meant to be a temporary fix until rust. Looking back, I partly agree with @Tropix126 in that an |
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.
Add changes in this pr to the unreleased entry in the changelog. After that I think its good to merge.
Oh, another thing. If you are in the pros-rs discord server, what is your username? I will give you the contributor role once this is merged. If not, here is the invite: https://discord.gg/d4uazRf2Nh. Join if you feel like it. |
PR should be ready to merge. This shouldn't need a minor semver bump anymore since I removed the deprecations. Let me know if anything else needs changing.
Just joined today. My username is |
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.
LGTM! Thank you for contributing!
Describe the changes this PR makes. Why should it be merged?
This PR has a few small changes for consistency and ease of use. It was pretty much the result of me going through the codebase and fixing random things along the way.
This PR:
Abs
trait which allows finding the abs of f64 and f32 types and added to the prelude. (see this issue for more context)take_error
was being called more than once, not really sure about this one)Additional Context