## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
• 15:20
Daenyth commented #3950
• Jul 24 20:10
smarter commented #3950
• Jul 24 18:38
djspiewak commented #3950
• Jul 24 17:48
smarter commented #3950
• Jul 24 17:42
djspiewak commented #3950
• Jul 23 18:40
Daenyth opened #3950
• Jul 23 04:41
djspiewak opened #3949
• Jul 22 13:12
scala-steward opened #3948
• Jul 20 15:33
catostrophe opened #3947
• Jul 20 12:46
keyno63 closed #3927
• Jul 20 12:46
keyno63 commented #3927
• Jul 20 11:22
joroKr21 commented #3946
• Jul 20 09:48
froth commented #3927
• Jul 20 09:45
ziggystar edited #3946
• Jul 20 09:45
ziggystar opened #3946
• Jul 19 18:54
rossabaker commented #3945
• Jul 19 17:33
danicheg opened #3945
• Jul 18 01:25

rossabaker on main

• Jul 18 01:25
rossabaker closed #3937
• Jul 17 12:52
SimY4 synchronize #3944
Tim Spence
@TimWSpence

I got hit by typelevel/cats#3762 when doing some work on ContT and I realized that I’m a bit confused by the anti-symmetry law

def antiSymmetryEq(x: A, y: A, f: A => A): IsEq[Boolean] =
(!E.eqv(x, y) || E.eqv(f(x), f(y))) <-> true

It seems to me that it need not hold in general. I commented in the ticket but if anyone can un-confuse me, I would appreciate it! :joy:

posco
@posco:matrix.org
[m]
that should pass… that is saying, if x and y are Eq.eqv, then any function of them should be too (if it is a valid function, like it isn’t using .hashCode, system hashCode, toString)
Tim Spence
@TimWSpence
But surely that assumes that f is well-defined (x == y => f x == f y) wrt Eq? And in fact the test fails precisely because the functions created by the Cogen instance are not well-defined - they take FiniteDurations that are equivalent (eg 51 days and 1224 hours) and map them to different values by pattern-matching on the time unit. Which is a perfectly reasonable scala function but not well-defined wrt Eq
Luka Jacobowitz
@LukaJCB
that’s an interesting case
I think we should fix the cogen instance rather than get rid of the law for now
hmmm I’m not sure how this came to be given that the cogen instance looks like this: https://github.com/typelevel/scalacheck/blob/8645105297ff26512d002e87d413717212892977/src/main/scala/org/scalacheck/Cogen.scala#L146
Tim Spence
@TimWSpence
Yeah I think that’s probably the only non-trivial Cogen instance you can define for FiniteDuration. But there is some history here that I didn’t quite get to the bottom of - the instance was removed in typelevel/cats#3470 and then that was reverted but I didn’t have time to dive into why
@arosien
i'm sorry to barge into this conversation, but talk of antisymmetry and cogen won't let my brain stop repeating "i know you are, but what am i?" like an 8-year old. sorry, i'll disappear now.
(this remark has no logical content. do not attempt to infer one.)
Georgi Krastev
@joroKr21
Hmm since we added scala native support to cats running test:compile hangs for me - anyone else have that problem?
Anton Sviridov
@keynmol
GC?
[warn] In the last 8 seconds, 7.465 (95.3%) were spent in GC. [Heap: 0.97GB free of 4.44GB, max 4.44GB] Consider increasing the JVM heap using -Xmx or try a different collector, e.g. -XX:+UseG1GC, for better performance.
[warn] In the last 6 seconds, 5.089 (95.0%) were spent in GC. [Heap: 0.93GB free of 4.44GB, max 4.44GB] Consider increasing the JVM heap using -Xmx or try a different collector, e.g. -XX:+UseG1GC, for better performance.
[warn] In the last 7 seconds, 6.254 (90.0%) were spent in GC. [Heap: 0.93GB free of 4.44GB, max 4.44GB] Consider increasing the JVM heap using -Xmx or try a different collector, e.g. -XX:+UseG1GC, for better performance.
Georgi Krastev
@joroKr21
Yes - I tried with upto 6g heap, same problem
Looks like linking the cats tests is really difficult :sweat_smile:
Anton Sviridov
@keynmol
I don't know if cats is already doing it, but I have a project which I can only build if I heavily restrict concurrency in SBT. SJS linker and SN linker running concurrently are the definition of bad time :D
Georgi Krastev
@joroKr21
Ah that could totally be it - the more cores you have, the worse it gets, counterintuitively
I don't think there is any care taken about that in the cats build
Anton Sviridov
@keynmol

I usually have this:

ThisBuild / concurrentRestrictions ++= {
if (sys.env.contains("CI")) Seq(Tags.limitAll(2)) else Seq.empty
}

In SBT builds with a ton of parallel modules. I also have something that puts SJS linker into batch mode on CI, to avoid it keeping state in memory

and yeah, I have 8 cores and I can't do things Github Actions' 2-core nodes can :D
Georgi Krastev
@joroKr21
Interesting, I think the CI doesn't have this problem somehow
Because it builds each platform separately probably
Anton Sviridov
@keynmol
But also SBT has heuristics of limiting everything (with Tag.CPU) to the number of CPUs - and there's fewer on CI. But you can still break it
Georgi Krastev
@joroKr21
Hmm or maybe it does - the native job is considerably slower: https://github.com/typelevel/cats/pull/3792/checks?check_run_id=1893482771
Can you restrict the parallelism only when the link task is involved?
Anton Sviridov
@keynmol
I know Scala.js puts special tags on the linking tasks, let me check if native has that.
Georgi Krastev
@joroKr21
It doesn't look like it - it's a bit weird that you have to use tags. You can't scope the setting to the task?
Diego E. Alonso Blas
@diesalbla
Good evening!
Could somebody with repo access close this issue? As reported, it is now fixed. typelevel/cats#1473
Diego E. Alonso Blas
@diesalbla
Should we close this one? typelevel/cats#1723
It seems that the traverse_ vs foreach question is now decided on favour of the former.
Anybody willing to reopen before 3.0 release ?
Tim Spence
@TimWSpence
I opened a PR for adding compose to Representable. If anyone wants to look at it, that would be much appreciated! :) And speaking of Representable instances, another obvious one would be for Product (https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Functor-Product.html#t:Product) I don’t think this type exists in Cats. Would there be interest in me adding it?
Diego E. Alonso Blas
@diesalbla
Should we close this issue? typelevel/cats#1667
Tim Spence
@TimWSpence
I discovered that Product does exist as Tuple2K so I added a representable instance for it as well - typelevel/cats#3832
Tim Spence
@TimWSpence
If anyone has time to review typelevel/cats#3831 and typelevel/cats#3832 that would be much appreciated! :)
Diego E. Alonso Blas
@diesalbla
Should we mark this issue as "won't do"? typelevel/cats#157
Diego E. Alonso Blas
@diesalbla
Good evening! I have started to look in typelevel/cats#3834, using Scala 3 Opaque types.
However, who else is considering how to use newer Scala 3 features to reimplement or restructure the cats type-classes and data types?
Or would like to take a look at it? Apart from @keynmol in typelevel/cats#3820
Ross A. Baker
@rossabaker
If I understood that one right, it effectively means dual maintenance of all the opaque data types. I'd be a lot more enthusiastic about that one if the implementations could share more across versions.
I do think it's neat. I don't mean to be discouraging. Just hoping a more concise encoding emerges.
Diego E. Alonso Blas
@diesalbla

Hmmmm :thought_balloon: :thought_balloon: Given that many Scala 3 new features, like type-classes, or extension methods, or opaque types,
are to an extent driven from the lessons learned by the efforts and contortions of cats code for Scala 2 (as well as that of other libraries) ,
perhaps we should get used to the idea of Scala 3 given different enough to merit a different coding for cats

Of course, dropping all ties to Scala 2 was already laborious enough... I know it is important, and hard, and urgent, and has taken over a year to get there...
After that, though, one-code-fits-both seems to lose some good features...

mpilquist
@mpilquist:matrix.org
[m]
Duplicate maintenance for things that result in significant improvements for users seems like a good tradeoff. Breaking changes which just make cats code itself easier to read or maintain aren’t a good tradeoff.
Ross A. Baker
@rossabaker
Opaque types for transformers are conceivably the former.
But I'm having nightmares about downstream libraries trying to crossbuild.
mpilquist
@mpilquist:matrix.org
[m]
Oh definitely should be source compatible
Ross A. Baker
@rossabaker
Right. And we don't have tooling to enforce that, other than grumpy downstream library maintainers.
Maybe tooling would emerge. I bet there are Stupid Scalameta Tricks that could translate one to the other.
Diego E. Alonso Blas
@diesalbla

Another idea with Scala 3 would be to define type class methods as extension methods... typelevel/cats#3841
In essence, we would no longer need the TC and the syntax extension, only one place would give both.

Perhaps we could set up a TypeLevel community build?

Ross A. Baker
@rossabaker
Much of Typelevel is already in the community build, and it's a ton of work to maintain from what I understand.
Diego E. Alonso Blas
@diesalbla
I mean, some project of "Git clone this list of repos, with their top branches, and build them with the current HEAD of cats.....
Not the Scala compiler community build, but the one from cats upwards...
mpilquist
@mpilquist:matrix.org
[m]
I’d like to see extension methods work without imports or conflicts for something as large as cats. Last time I tried it, which admittedly was a while ago, I couldn’t get it working without implicit conflicts
See the now archived spotted leopards project
Seth Tisue
@SethTisue

Not the Scala compiler community build, but the one from cats upwards.

The community build is subsettable. you can e.g. ./run.sh -l http4s and it only builds http4s and its dependencies. there is no automation for the reverse, "please build only things that depends on cats" but dependencies.txt has the needed information and you could extract it with a shell one-liner, grep cats dependencies.txt and a little string munging to assemble the ./run.sh -l a,b,c command line

There's also a ./narrow script to prevent stuff you don't want from even being looked at, to speed it up