-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
2.13.0-RC1 #2792
2.13.0-RC1 #2792
Conversation
a82916d
to
757c13b
Compare
Codecov Report
@@ Coverage Diff @@
## master #2792 +/- ##
==========================================
- Coverage 94.28% 94.15% -0.13%
==========================================
Files 367 368 +1
Lines 6926 6914 -12
Branches 304 296 -8
==========================================
- Hits 6530 6510 -20
- Misses 396 404 +8
Continue to review full report at Codecov.
|
These two changes in 2.13.0-RC1 make a huge mess of some of the
I really wish In any case it seems to work now, and I've tried to minimize the version-specific code. |
Ugh, there are some stray These aren't the only instances that seem out of place. At a glance:
We're stuck with these in the wrong place until 3.0? |
This is probably off-topic for this PR, but I have to say my experience contributing to Cats this weekend (for the first time in a year or so, at least with non-trivial changes) has been pretty miserable. There are so many little broken things—these misnamed / misplaced instances, inconsistencies everywhere, #2790, stuff like The worst part is that this is entirely self-inflicted: Cats 1.0 is almost a year and a half old—it would be perfectly reasonable to release a 99% source-compatible 2.0 that would break binary compatibility but also make the build hugely simpler and the code more consistent. Okay, that's my rant—as I've been saying over and over for months I think the 2019 roadmap is a big mistake. Hopefully the build will pass this time and you can publish for 2.13.0-RC1 and I can go back to being just a reasonably happy library user instead of an extremely frustrated contributor. |
Oh, cool, now I'm getting export-hook related errors locally in alleycats-tests, |
Okay, the only failure is now the 2.13.0-RC1 JVM tests, and that's just an OOM. It might need attention but I just restarted to see if it was a one-off thing. |
Now seeing the alleycats export-hook errors on 2.13.0-RC1 in CI:
|
I plan to remove export hook. Will take on it tomorrow now that it is a blocker. |
+1 to removing the export-hook dependency, but even so ... why an |
@milessabin Yeah, it doesn't make sense to me. I've tried a full clean, etc., but it still happens maybe a quarter of the time both locally for me and in Travis CI. |
@travisbrown, export hook is removed on master, if you merge master back in. |
@kailuowang Great, thanks! Trying it out locally now. |
@@ -357,6 +357,9 @@ sealed private[data] trait WriterTFlatMap1[F[_], L] extends WriterTApply[F, L] w | |||
implicit override def F0: FlatMap[F] | |||
implicit def L0: Monoid[L] | |||
|
|||
override def ap[A, B](f: WriterT[F, L, A => B])(fa: WriterT[F, L, A]): WriterT[F, L, B] = |
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 curious, was this an optimization opportunity you happen to come across or was it broken on RC1?
Also would it be simpler to just call fa.ap(f)
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.
This is from @SethTisue's commit, but the issue is that 2.13 sees the ap
definitions in FlatMap
and WriterTApply
as conflicting. I personally think picking out the appropriate implementation via super
is the right thing to do in this case, but I also don't think it matters much, and am happy to change it to fa.ap(f)
if you'd prefer.
Thanks so much! Shall we remove the |
@kailuowang I'd been thinking we'd merge #2791 separately and then I'd merge master back here, since the catalysts removal is logically separate—it just makes this update easier. We could also just merge this directly, though, so I've removed the |
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 so much!
@travisbrown sorry I misunderstood your intention in regards to #2791. I agree that it's more logical to merge that as a separate PR. I am going to squash merge that one, and one you merge master back in this PR, please don't worry about sort of duplicated commits (the ones originally in #2791), we are going to squash merge this one too. |
Well that's helpful. |
@tpolecat Somehow in the merge build.sbt picked up a stray newline. But yeah, it's funny how irrationally annoying scalafmt's contentless error messages are, given that they're specifically not intended to be acted on (beyond indicating that you need to run scalafmt). |
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.
Anyway 👍 thanks for your work on this! With luck the scalafmt thing will be the last nit.
Includes #2783 and #2791. Running the full build locally is apparently a mystery beyond my skill level so I'm just creating my own version of #2783 to run it here.