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
13h3r2
@13h3r2
As side effect we are also delaying the next execution after .complete
This is not only about blocking, this is also about cpu intensive operations.
Fabio Labella
@SystemFw
sure, but with cpu intensive operations I think it goes back to guarantees fo fairness
13h3r2
@13h3r2
So instead of notifying we are executing the whole other program which depends on this barrier
Fabio Labella
@SystemFw
shift on its own doesn't fix that. shift plus the fact that you happen to have lots of threads does
like, even if Deferred shifted, with 4 threads you'd still see lots of sequential behaviour
13h3r2
@13h3r2
Ah, I see it. You right.
Fabio Labella
@SystemFw
not saying that you don't have a problem ofc :)
13h3r2
@13h3r2
So shift + fairness can fix it
Fabio Labella
@SystemFw
just that your problem is more with fairness than with Deferred (or MVar, or Scala Promise)
well
with fairness guarantees you shouldn't need a manual shift
since fairness guarantees basically amount to shifting every now and then
if I were writing this code
since you know that that piece of code is very CPU-intensive
13h3r2
@13h3r2
Yes and no. The first iteration still will be sequential, right?
Fabio Labella
@SystemFw
sure
I don't think that's that big of a deal though, as long as control gets yielded back at some point
13h3r2
@13h3r2
Ok it make sense. Should we put the note about fairness and scheduling somewhere in the documentation?
Fabio Labella
@SystemFw
it's already there somewhere I think
in the differences between IO and Task
what's surprising here is the behaviour of Task
13h3r2
@13h3r2
For now (:)) it is clear for why it should not work with io. I will continue the investigation with task today.
Will start with the code from master
Thanks for your help!
Fabio Labella
@SystemFw
no worries
Oleg Pyzhcov
@oleg-py
The default for monix is to shift every 1024 binds IIRC
Fabio Labella
@SystemFw
ah, there it is
that makes sense
Oleg Pyzhcov
@oleg-py
which is a fairly large number, but it can be customized
13h3r2
@13h3r2
Thanks. I will try to lower the limit it drop you guys a line
λoλcat
@catostrophe

Hi.
Is this behavior of bracket correct?

import cats.data.{Chain, WriterT}
import cats.effect.{ExitCode, IO, IOApp, Sync}
import cats.effect.implicits._
import cats.implicits._
import cats.mtl.FunctorTell
import cats.mtl.implicits._

object Test extends IOApp {

  def bracketWithTell[F[_], A](a: A)(implicit F: Sync[F], W: FunctorTell[F, Chain[String]]): F[ExitCode] =
    a.pure[F].bracket { x =>
      F.delay(println(s"used $x")) *> W.tell(Chain.one(s"used $x")) as ExitCode.Success
    } { x =>
      F.delay(println(s"released $x")) *> W.tell(Chain.one(s"released $x"))
    }

  override def run(args: List[String]): IO[ExitCode] =
    bracketWithTell[WriterT[IO, Chain[String], ?], Int](1).run.flatMap {
      case (log, code) => IO(println(s"writer log: $log")) as code
    }
}

Output:

used 1
released 1
writer log: Chain(used 1)

We lose the writer effect in the release part. The same holds for all transformers.

If it's correct, doesn't it need clarification in docs?

λoλcat
@catostrophe
bracket implementations for all transformers just ignore additional effects
λoλcat
@catostrophe
There's no laws for release. Do we need some?
Fabio Labella
@SystemFw
@catostrophe I would open an issue with that snippet. Better to have everyone see it
λoλcat
@catostrophe
Ok. Will do
λoλcat
@catostrophe
Viktor Lövgren
@vlovgr
@catostrophe the same behaviour should happen when using asyncF, unless I'm mistaken. Have you tried it?
Luka Jacobowitz
@LukaJCB
@catostrophe I think it’s actually impossible to write a bracket implementation that does what you expect with its current signature
λoλcat
@catostrophe
@vlovgr you're right. The same behavior.
λoλcat
@catostrophe
Thanks, reading...
Viktor Lövgren
@vlovgr
@catostrophe thanks for verifying. I only noticed this because I wrote a IOLog newtype over IO and noticed I had to discard the logs in only two cases: release for bracketCase and in asyncF. (Blog post likely out tomorrow, looks related to what you're doing.)
λoλcat
@catostrophe
@LukaJCB I've read that old thread, "impossible to write ... with current signature" doesn't look as an appropriate excuse ;) @oleg-py raised a concern I agree with (https://github.com/typelevel/cats-effect/pull/113#issuecomment-363461345) and you seemed to agree but then you crossed it out (https://github.com/typelevel/cats-effect/pull/113#issuecomment-374628912) and @alexandru said it's fine. But I still don't get why it's ok to ignore last change in WriterT or StateT.
Jakub Kozłowski
@kubukoz
so whatever happens in release doesn't get propagated to the whole bracket call's result?
λoλcat
@catostrophe
@kubukoz Aux effects of transformers don't. But the main effect of F does.
Jakub Kozłowski
@kubukoz
right
upd
@prayagupd
While learning cats-effect IO- https://typelevel.org/cats-effect/datatypes/io.html#parmapn, I found an parMapN example missing ContextShift[IO]. I thought it could be helpful to add one way to provide contextShift helpful noobs like me. So created a pull request https://github.com/typelevel/cats-effect/pull/372/files
upd
@prayagupd

Learning Question: I'm trying to run the cats.effect.Resource example from https://typelevel.org/cats-effect/datatypes/resource.html#example. I get value map is not a member of cats.effect.Resource[cats.effect.IO,String]. Wondering why is it looking for map not flatMap,

 // example taken from https://typelevel.org/cats-effect/datatypes/resource.html#example
  test("cats Resource") {

    import cats.effect.{IO, Resource}
    import cats.implicits._

    def mkResource(data: String): Resource[IO, String] = {
      val acquire = IO(println(s"Acquiring $data")) *> IO.pure(data)

      def release(res: String) = IO(println(s"Releasing $res"))

      Resource.make(acquire)(release)
    }

    val out: Resource[IO, String] = mkResource("outer")
    val in: Resource[IO, String] = mkResource("inner")

//    val rr = out.flatMap { a =>
//      in.flatMap { b =>
//        Resource.pure((a, b))
//      }
//    }

    //    out.map { o =>
    //      in.map { i =>
    //        (o, i)
    //      }
    //    }

    val r = for {
      outer <- out
      inner <- in
    } yield (outer, inner)

    r.use { case (x, y) => IO(println(s"Using $x and $y")) }.unsafeRunSync

  }

Error

Fabio Labella
@SystemFw
that code compiles for me