Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:20

    rossabaker on main

    Add `raiseWhen` and `raiseUnles… (compare)

  • 13:20
    rossabaker closed #3950
  • Jul 27 19:56
    djspiewak commented #3949
  • Jul 27 14:46

    djspiewak on main

    Update sbt-mdoc to 2.2.22 Merge pull request #3948 from s… (compare)

  • Jul 27 14:46
    djspiewak closed #3948
  • Jul 27 14:45
    djspiewak commented #3950
  • Jul 27 14:42
    djspiewak synchronize #3949
  • Jul 27 12:45

    djspiewak on main

    Restored fail-fast and split ou… Removed `--client` flag to ensu… Merge pull request #3952 from d… (compare)

  • Jul 27 12:45
    djspiewak closed #3952
  • Jul 26 23:36
    SimY4 commented #3944
  • Jul 26 23:32
    SimY4 commented #3944
  • Jul 26 20:38

    djspiewak on main

    Override `map2Eval` in `FlatMap` Merge pull request #3951 from v… (compare)

  • Jul 26 20:37
    djspiewak closed #3951
  • Jul 26 19:38
    armanbilge commented #3944
  • Jul 26 16:19
    djspiewak ready_for_review #3952
  • Jul 26 15:29
    djspiewak synchronize #3952
  • Jul 26 14:59
    djspiewak synchronize #3952
  • Jul 26 14:46
    djspiewak synchronize #3952
  • Jul 26 14:44
    djspiewak edited #3952
  • Jul 26 14:43
    djspiewak synchronize #3952
Georgi Krastev
@joroKr21
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
Tim Spence
@TimWSpence
I opened a PR for adding a Representable instance for Cofree - typelevel/cats#3858. I’m pretty sure the implementation is sound but laws testing it is an interesting challenge. The issue is that sum types are not representable (as far as I know and it certainly seems intuitively obvious) and neither are trivial product types like Const. But if we have a genuine product type F[A] with a hole of type A then Cofree[F, A] is necessarily infinite so we can’t construct an Eq instance for checking the laws. My only thought is that we construct an Eq instance that evaluates the tree to some fixed depth and asserts that the sub-trees are equal?
I think the instance is still useful because it seems reasonable for an application to generate this infinite tree structure but only index some finite subtree
Ross A. Baker
@rossabaker
Variance terrifies me. Is this right: https://github.com/typelevel/cats/pull/3864/files?
Georgi Krastev
@joroKr21
Looks right to me
Arman Bilge
@armanbilge
Does cats publish snapshots? I found them in sonatype up to 2.3.0-M1 but then they stop.