-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Fix LazyList.range [ci: last-only]
#10767
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
base: 2.13.x
Are you sure you want to change the base?
Conversation
| .range(start = 0L, end = totalElements) | ||
| .foldLeft(0L) { case (acc, _) => | ||
| acc + 1L | ||
| } |
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 with inlining turned on, it's a lot to ask of a unit test. Maybe it's sufficient to test construction and head.
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.
Yeah I was wondering the same.
However, not sure if just asking for the head ensures there are more than Int.MaxValue elements.
So not sure if there is a smart way to test this without it being a CPU trap.
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.
Using a reverse range we don't need to compute a lot of elements.
Let me know what you think of the new test.
C.C. @NthPortal
|
added the magic title to avoid testing every commit |
| .range(start = 0L, end = totalElements) | ||
| .foldLeft(0L) { case (acc, _) => | ||
| acc + 1L | ||
| } |
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.
Yeah I was wondering the same.
However, not sure if just asking for the head ensures there are more than Int.MaxValue elements.
So not sure if there is a smart way to test this without it being a CPU trap.
Co-authored-by: Marissa | April <[email protected]>
NthPortal
left a comment
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.
just two small changes; otherwise lgtm.
I agree with @som-snytt's concern about the cost of iterating over Int.MaxValue elements, though I'm not really sure what the alternative is. I will defer to others' judgement about whether or not to just skip it
β¦tion Co-authored-by: Marissa | April <[email protected]>
Co-authored-by: Marissa | April <[email protected]>
| } | ||
|
|
||
| private[this] def rangeImpl[A](start: A, end: A, step: A)(implicit ev: Integral[A]): State[A] = | ||
| if (ev.lt(start, end)) sCons(start, newLL(rangeImpl(ev.plus(start, step), end, step))) |
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.
Uhm, wait, this does not allow reversed ranges, does it? Like LazyList.range(start = 100, end = 0, step = -2)
I guess rather than check for lt we have to check for !ev.equiv(start, end)?
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.
Also, this made me think. This could be a good way to test this without a CPU trap. We just request the reversed range and then we can indeed ask for the head and check it is bigger than Int.MaxValue
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.
good point, the check is incorrect, hmm. probably need to check the sign or something as well. I'll have another look shortly
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.
my thought is to check the sign of step in the 3 parameter overload of range, and then pass it as a Boolean parameter (probably named positiveStep) to rangeImpl, thus checking the condition only once rather than for each element
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 just pushed an implementation that allows for reverse ranges.
Let me know what you think about it.
|
@BalmungSan have you looked at the MiMa failures...? |
|
@SethTisue hey, thanks for the pointer, I actually haven't noticed about the MiMa errors and was thinking the reason why the CI was red was that it was testing each commit. |
|
It looks to me like we're running into the problem described at https://github.com/scala/improvement-proposals/blob/main/content/drop-stdlib-forwards-bin-compat.md#adding-overrides-for-performance . The overridden methods have return types of SIP-51 is accepted and has been implemented in at least one build tool (sbt), but we haven't actually started taking advantage of it yet. At the moment we are still trying to ship 2.13.15, but once that is done, we can consider whether 2.13.16 is the release where we start actually using the new freedom. |
update: 2.13.16 will be a modest compat/bugfix release, so 2.13.17 is now where we're looking to start bincompat breakage |
Since
LazyListis not strict, there is not reason to makerangedelegate throughfrom(NumericRange)which doesn't allow more thanInt.MaxValueelements.