by

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 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
@kubukoz
you can make sure it starts (and cancels immediately afterwards) with a promise
Deferred[IO, Unit].flatMap { deff =>
  mod(deff.complete(()) *> io).start.flatMap(deff.get *> _.cancel)
}
The default implementation of uncancelable will have cancel wait for the effect
IO's impl overrides that to make cancel a no-op
I was experimenting just now, see https://scastie.scala-lang.org/cTQWIR8mRPOT0m4VPwRuRA
sadly the scastie isn't consistent with master since your change ;)

local scores

0ms: good: Sleep completed
7ms: good: Cancel completed

0ms: good alt: Sleep completed
1ms: good alt: Cancel completed

0ms: bad: Cancel completed
5003ms: bad: Sleep completed

(low diff means cancel kept waiting)

Jakub Kozłowski
@kubukoz
here's a polymorphic version in case you want to give other effects a try https://scastie.scala-lang.org/gL9rkl9rQp2v2fgYOV88Ew
Piotr Gawryś
@Avasil

I thought you meant something like this

  val io = for {
    pa <- Deferred[IO, Unit]
    fiber <- (pa.complete(()) >> IO(Thread.sleep(5000))).start
    _ <- pa.get
    _ <- fiber.cancel
  } yield ()

(no bracket)

and nevermind, it seems to be waiting for zio
Jakub Kozłowski
@kubukoz
well, the bracket in the examples was just to show the difference between the standard and IO's impls
the easiest thing to do to fix IO's uncancelable would be to... stop overriding the default :D
it'll reduce the amount of code, too
the whole IOCancel seems to be redundant then
I'll submit a PR with some tests and we'll see where it goes
Jakub Kozłowski
@kubukoz

hmm are law tests broken?

  def uncancelableIsDerivedFromBracket[A](fa: F[A]) =
    F.uncancelable(fa) <-> fa

this passes for IO...

Piotr Gawryś
@Avasil
Can uncancelable be written in terms of bracket if Bracket's implementation is using it?
Jakub Kozłowski
@kubukoz
if the implementation is indeed using it, then it's a problem...
and I can see it does
I'm out of my depth here...
and someone just messed in that code! ;)
Piotr Gawryś
@Avasil
It's a bit tricky :P I want to trim my backlog first and then I could try to attempt this but I feel like it will require major changes in cancelation implementation
Jakub Kozłowski
@kubukoz
yeah... and honestly the cancelation code feels quite complex
Jules Ivanic
@guizmaii
Hi everyone :)
Happy New Year :tada:
Daniel Spiewak
@djspiewak
🎉
Jules Ivanic
@guizmaii
I have a question.about the diff between Sync[F].pure and Sync[F].delay.
Fabio Labella
@SystemFw
shoot
Jules Ivanic
@guizmaii
In my head, the first one should only be used with values
Fabio Labella
@SystemFw
yep
Jules Ivanic
@guizmaii
and the second one should be used to purify a function call
Fabio Labella
@SystemFw
that's not the main difference (talking about the function call)
well, it depends on your definition of "value"
do you mean val, or something else?
Jules Ivanic
@guizmaii
so something like that is a bug: Sync[F].pure(logger.info(“…"))
Am I right?
Fabio Labella
@SystemFw
that's right
Jules Ivanic
@guizmaii
Hum. Maybe the best definition of a value I can give you is that it’s something already computed
Fabio Labella
@SystemFw
I would define a value as a referentially transparent expression. Applying pure to a value yields another value (another referentially transparent expression). Applying pure to a non-value yields a non-value. delay is magic because you can apply it to a non-value and get a value out
does that make any sense?
Jules Ivanic
@guizmaii
Yes, it does. Totally
if something like that Sync[F].pure(logger.info(“…")) is used, the logger will only be called once, right?
Fabio Labella
@SystemFw
informally yes. Slightly more formally, the semantics of execution are now linked to the semantics of evaluation
i.e. now performing effects depend on whether you have a def or val, normal parameters vs by-name, etc
Jules Ivanic
@guizmaii

now performing effects depend on whether you have a def or val

Not sure to understand that part

🤔
Adam Rosien
@arosien_twitter
a val is a value, but a def is something that produces a value (when it is evaluated)
Jules Ivanic
@guizmaii
Can’t we consider def a = 1 as a value?
Adam Rosien
@arosien_twitter
in what way?
like, is a a value? or the literal expression you wrote?
Gavin Bisesi
@Daenyth
@guizmaii It's a method that returns a value. Coincidentally, it returns the same value every time you call it
Consider the difference between def x = Random.nextInt vs val b = Random.nextInt when you see x + x vs b + b