Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 05 14:43
    @typelevel-bot banned @jdegoes
  • Jan 31 21:17
    codecov-io commented #484
  • Jan 31 21:08
    scala-steward opened #484
  • Jan 31 18:19
    andywhite37 commented #189
  • Jan 31 02:41
    kamilongus starred typelevel/cats-effect
  • Jan 30 00:01
    codecov-io commented #483
  • Jan 29 23:51
    deniszjukow opened #483
  • Jan 29 23:37
  • Jan 29 23:22
  • Jan 29 20:26
    Rui-L starred typelevel/cats-effect
  • Jan 29 18:01
    jdegoes commented #480
  • Jan 29 17:04
    thomaav starred typelevel/cats-effect
  • Jan 28 17:43
    asachdeva starred typelevel/cats-effect
  • Jan 28 07:12
    alexandru commented #480
  • Jan 28 05:45
    codecov-io commented #482
  • Jan 28 05:35
    daron666 opened #482
  • Jan 27 13:56
    codecov-io commented #481
  • Jan 27 13:46
    lrodero opened #481
  • Jan 27 05:47
    codecov-io commented #460
  • Jan 27 05:37
    codecov-io commented #460
Michael Pilquist
@mpilquist
Gavin Bisesi
@Daenyth
What's the state of scalatest generators vs scalacheck? Are they similar idea and competing implementations? Are the scalatest ones supposed to be one you migrate to? Is there any kind of interop path?
Kai(luo) Wang
@kailuowang
Thanks @mpilquist. Those are cool apis. I will put it on the "I’ll make it a microlib when I have time" list.
Daniel Spiewak
@djspiewak
@kailuowang @milessabin @mpilquist there's https://github.com/djspiewak/cats-effect-testing if you want to contribute such a thing. it currently has support for specs2, µtest, and minitest, but not scalatest
Fabio Labella
@SystemFw
I have to say after Michael's work on integration, and the improvements of scalatest, I'm quite happy with the choice for fs2
also now the split on style has been modularised, so you have a bit less of analysis-paralysis
Michael Pilquist
@mpilquist
The ScalaTest 3.2 generator stuff is a competitor to ScalaTest. Most ScalaTest users use GeneratorDrivenPropertyChecks. With the new ScalaTest 3.2 property testing support, you mix in a different trait and still use the same forAll syntax, so the biggest impact to test writers is needing to write ScalaTest Generator instances instead of Arbitrary/Gen/Shrink instances
Gavin Bisesi
@Daenyth
I'll have to look into that. Is there a compelling driver for one or the other version for you?
Michael Pilquist
@mpilquist
Only ScalaTest’s supports effectful assertions
ScalaCheck fundamentally requires a property to be synchronous
e.g. I want forAll { (…) => /* return Future[Boolean] or IO[Boolean] here */ }
Gavin Bisesi
@Daenyth
Indeed - right now we have unsafeRunSync in there
Kai(luo) Wang
@kailuowang
@djspiewak thanks, if I get the time I will contribute a scalatest integration to it.
Michael Pilquist
@mpilquist
Right, which you can’t call on Scala.js
Daniel Spiewak
@djspiewak
:thumbsup:
@mpilquist I feel like fixing that would be a candidate for scalacheck 2.0
like having a forAllF or something
Michael Pilquist
@mpilquist
Yeah, then waiting 3 years for ScalaTest and rest of community to adopt
Kai(luo) Wang
@kailuowang
Yeah, I remember that I have to use Scalatest’s asyncFunSuite to support scalajs.
Michael Pilquist
@mpilquist
I’d much prefer a new property testing framework
Daniel Spiewak
@djspiewak
LOL
Kai(luo) Wang
@kailuowang
@djspiewak just copy pasted a PR
djspiewak/cats-effect-testing#18
I didn’t include the property checking part for now, since it’s more involved with scalatest property test, which I suspect will add more future maintenance to this integration code.
Michael Pilquist
@mpilquist
BTW ScalaTest 3.1 has removed the new generator stuff and will add back in 3.2. Hence, FS2 is stuck on a 3.1 snap release until the 3.2 rcs start
Rafi Baker
@BakerRafi_twitter
I was listining to Fabio’s talk on Fibers and have a question. If Async callback is key in implementing Fiber based operations and I see Async moved down below Concurrent in CE3 proposal, wouldn’t this be a problem?
Fabio Labella
@SystemFw
@BakerRafi_twitter mm, yes and no (in practice, no)
first of all, you could actually decouple async and fork by making fork a primitive operation in the AST which is interpreted by sending the io directly to the EC (with a Fiber-Like handle to avoid losing it)
however in the talk I was really keen to stress the link between those two concepts (and cats-effect IO does implement Start with an Async node)
now coming to your more specific question, the key question is whether:
  • Async extends Concurrent
  • Concurrent extends Async
  • they don't extend each other at all
all three choices offer interesting tradeoffs
Fabio Labella
@SystemFw
if you move Async below Concurrent, a few things can happen:
  • you can implement Concurrent without Async, without using real concurrency (you write a scheduler for concurrent actions that does the interleaving). This is nice but not the main point
  • you need the type that is Concurrent to also be Async to use the real implementation. But then if every Concurrent is Async, why not Concurrent <: Async (which is the current situation)? Well, because we'd like to take an F[_]: Concurrent constraint and know that we can have concurrent control flow, without also having the ability to do every possible effect ever (which Async <: Sync implies)
does the above make any sense? (the design space is fairly vast so it's a bit hard to summarise it without showing concrete code)
Rafi Baker
@BakerRafi_twitter
Yes, it does. Thanks for explaining.
Daniel Spiewak
@djspiewak
@SystemFw that's an immensely concise summary of why Async <: Concurrent is nice :-) much more concise than any of my plodding explanations have been
Fabio Labella
@SystemFw
I'll save it in my writings then :P
also current status: I'm going into a deep investigation of Haskell's masking. The initial summary in the CE3 proposal is for certain incorrect I'm afraid, I'm trying to understand how much of the complexity we can shed, and how much we cannot
Paul Snively
@paul-snively
I want a master class with @djspiewak and @SystemFw.
Jakub Kozłowski
@kubukoz
Masking?
@paul-snively don't we all?
Fabio Labella
@SystemFw
look at the docs from Control.Exception. It's in the context of cancelable/uncancelable regions (same idea)
bifunctor
@bifunctor
From the doc, I did not get it.
Jens Halm
@jenshalm
@bifunctor It deals with the scenarios where you want to safely group the effect-full acquisition and release of a resource (e.g. an InputStream) into a single type. It reduces the amount of plumbing and the opportunity for errors in the code that uses the resource (e.g. you cannot forget to close the stream). The tutorial section about Resource is a bit more detailed (and also compares Resource with Bracket): https://typelevel.org/cats-effect/tutorial/tutorial.html#acquiring-and-releasing-resources
Paul Snively
@paul-snively
You could say it’s an effectful, referentially transparent version of try/catch/finally.
Basically, a “resource” is something that must be acquired (like a socket connection), used (effectfully), and released whether used successfully or unsuccessfully.
Jakub Kozłowski
@kubukoz
@bifunctor if you like this kind of thing, I made a vid about Resource (and Bracket, if you want to understand how Resource works with multiple effect types): https://www.youtube.com/watch?v=m9cu4xUvrUs
Rafał Sumisławski
@RafalSumislawski
Hi
The docs of Blocker say that it shouldn't be passed implicitly (https://github.com/typelevel/cats-effect/blob/master/core/shared/src/main/scala/cats/effect/Blocker.scala#L31). What is the reason behind this recommendation? I used to pass it implicitly and haven't seen any obvious drawbacks so far.
Daniel Spiewak
@djspiewak
@RafalSumislawski Just general best-practices with implicits. Basically, implicit values should never hold state. The implications of this are pretty profound and far-reaching, and a lot of it comes from experience in violating this rule (and paying the price later). An analogous "best practice" is that you should never do something like implicit def strToInt(s: String): Int = .... You certainly can do this, and it'll work sometimes, but you would reject any PR that introduced something like that, wouldn't you? Same thing with implicit Blocker.
That was maybe too abstract. :-) It's hard to point to concrete examples of where implicit Blocker will bite you. I guess the best thing to look at is the frustrations that people often have around implicit ExecutionContexts in the Future ecosystem.