Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Sep 05 2019 14:43
    @typelevel-bot banned @jdegoes
  • Jan 31 2019 21:17
    codecov-io commented #484
  • Jan 31 2019 21:08
    scala-steward opened #484
  • Jan 31 2019 18:19
    andywhite37 commented #189
  • Jan 31 2019 02:41
    kamilongus starred typelevel/cats-effect
  • Jan 30 2019 00:01
    codecov-io commented #483
  • Jan 29 2019 23:51
    deniszjukow opened #483
  • Jan 29 2019 23:37
  • Jan 29 2019 23:22
  • Jan 29 2019 20:26
    Rui-L starred typelevel/cats-effect
  • Jan 29 2019 18:01
    jdegoes commented #480
  • Jan 29 2019 17:04
    thomaav starred typelevel/cats-effect
  • Jan 28 2019 17:43
    asachdeva starred typelevel/cats-effect
  • Jan 28 2019 07:12
    alexandru commented #480
  • Jan 28 2019 05:45
    codecov-io commented #482
  • Jan 28 2019 05:35
    daron666 opened #482
  • Jan 27 2019 13:56
    codecov-io commented #481
  • Jan 27 2019 13:46
    lrodero opened #481
  • Jan 27 2019 05:47
    codecov-io commented #460
  • Jan 27 2019 05:37
    codecov-io commented #460
Jakub Kozłowski
there any reason why Clock/Timer/ContextShift weren't encoded as abstract classes back in the day?
related: is it recommended to write custom typeclass-like algebras as abstract classes for fewer 2.11 problems?
haven't looked at the code yet but it looks relevant
(however I have to say that, at a glance, the number of bracket calls seems concerningly low for such a complex concurrent problem @ChristopherDavenport )
Otto Chrons
ok, thanks guys!
Gavin Bisesi
Can scalafix locate any call sites in the codebase where a value of IO is returned from a signature that asks for Any?
scalatest specs want .. => Any so it's very easy to omit an unsafeRunSync
it seems like something scalafix should be able to lint for
Jakub Kozłowski
NoInfer.symbols = ["scala.Any"]?
Gavin Bisesi
I don't think that would help
the library explicitly declares Any, there's no inference going on
only subtyping
@monadplus re: your question, this is the place to ask btw :)
Jakub Kozłowski
oh :(
I think it might be possible but it's better to ask @gabro or @olafurpg
Gavin Bisesi
I suppose I should see if they have a gitter
Christopher Davenport
@SystemFw that was contributed externally and at a time I had less of an understanding of concurrency and cancellation semantics. Reviews/Issues very appreciated so that we can improve it.
Jakub Kozłowski
Fabio Labella
@ChristopherDavenport oh yeah ofc, it was only meant as a heads up, there's a lot of code out there that needs to be upgraded. There's a good chance that that code was perfectly safe when written. Tbh the best thing to do in this case would be a PR. I'm very short on time but I'll try and schedule it :)
Ólafur Páll Geirsson
@kubukoz @Daenyth scalafix has no builtin rule for that kind of analysis
Arnau Abella
What is the usage of handleErrorWith ? This won't handle boom :(
(for {
    _ <- IO.unit.handleErrorWith { error =>
          IO(println(s"handling error: $error"))
    _ <- boom
  } yield ()).unsafeRunSync()
Gavin Bisesi
IO is composable
fa.handleErrorWith handles errors in fa
whatever you flatMap after that does whatever you tell it
Arnau Abella
I was thinking it the other way :O
Gavin Bisesi
I'm fairly certain an implementation that would make your example above handle boom would need to end up violating some applicative/functor laws somewhere along the way
I don't feel like writing that all out :P
but anyway - it doesn't work like that
Fabio Labella
you can actually see why the behaviour your seek is impossible as soon as you have things that don't return Unit
def ints: IO[Int] = 3.pure[IO].handleErrorWith(e => 4.pure[IO])
  // this is handleError
def string: IO[String] = (ints <* boom).map(_.toString) 
  // if handleErrorWith worked here you'd try to return an Int instead of a String
if handleErrorWith installed a handler which is valid for all IOs flatMapped after this, which type should it return?
it can only be IO[Nothing], which can only be something that never terminates (IO cannot emit zero values)
Arnau Abella
Makes sense, the signature also gives some hints avoit it
Fabio Labella
the behaviour which is closest to what you seek is the release action in Stream or Resource
Arnau Abella
I'll have a look at them tomorrow
Then, what is the purpose of handleErrorWith ?
Running a piece of code that is suspicious of throwing errors ?
Fabio Labella
handling the errors of the current IO
it's the equivalent of catch
e.g. imagine wanting to return different http responses on success or failure of an operation
or perhaps wanting to retry something when there's an error
like, I don't see why this model is confusing
you have
IO.unit.handleError(...) >> boom, which doesn't handle errors in boom
just like
try {
} catch {

doesn't handle errors in boom
Arnau Abella
It's not confusing now at all
Fabio Labella
ah, nice ;)