-
Notifications
You must be signed in to change notification settings - Fork 0
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
Support other units #1
Conversation
600ff08
to
be2ec8d
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1 +/- ##
===========================================
+ Coverage 72.72% 84.37% +11.64%
===========================================
Files 2 2
Lines 77 96 +19
===========================================
+ Hits 56 81 +25
+ Misses 21 15 -6 ☔ View full report in Codecov by Sentry. |
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 added a few comments.
NewHistory = [{ConsumeNow, DelayMs, NewShaper} | History], | ||
NewDelay = AccumulatedDelay + DelayMs, | ||
NewToConsume = TokensLeft - ConsumeNow, | ||
case is_integer(DelayMs) andalso DelayMs >= 0 of |
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.
The type of DelayMs
should be non_neg_integer()
, so why would you expect anything else?
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'm checking in tests that that is actually the case, because the type definition might end up failing, disadvantage of dynamic typing 🥲
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.
But it looks like we accept a bad result (not matching the type spec), because the test doesn't fail in the false
clause.
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.
Hmm... but we stop running and will fail later. Actually, I've just noticed here I'm returning a 4-tuple, which will fail with an error. I'll return a value that will always fall outside of the conditioned range 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.
Looks good in general. I appreciate splitting the logic. I added some minor comments. I haven't checked all the maths in detail, because it is checked in test cases.
NewHistory = [{ConsumeNow, DelayMs, NewShaper} | History], | ||
NewDelay = AccumulatedDelay + DelayMs, | ||
NewToConsume = TokensLeft - ConsumeNow, | ||
case is_integer(DelayMs) andalso DelayMs >= 0 of |
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.
But it looks like we accept a bad result (not matching the type spec), because the test doesn't fail in the false
clause.
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.
Thanks for the corrections, it all looks good to me now.
Also solves an issue where the penalisation added to the
last_update
element was inmillisecond
units unconverted to the correctly usednative
.