Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
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

    Add DeadlineInstances (#3937) … (compare)

  • Jul 18 01:25
    rossabaker closed #3937
  • Jul 17 12:52
    SimY4 synchronize #3944
Georgi Krastev
@joroKr21
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.