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
Ashkan Kh. Nazary
@Daenyth Thank you :pray:
Fabio Labella
it doesn't go into Blocker specifically, but it gives you the background to understand the different layers involved here, which I suspect is the source of the confusion (blocking/concurrent/async/semantically blocking)
Daniel Spiewak

@ashkann As a pale (but more concise) shadow of Fabio's talk…

Threads are basically an implementation detail. They're an abstraction around CPUs. We tend to think of threads as strictly a mechanism for parallelism, but really they're a mechanism for evaluation just as the underlying processor is. Parallelism is when multiple sequences of computation are scheduled to run simultaneously or pseudo-simultaneously (by suspension and interleaving). We generally refer to those sequences as "fibers".

In Cats Effect, we talk a lot about spawning fibers (using start) and getting their results (often using join). Fibers can be scheduled to run in parallel with other fibers using threads as an implementation mechanism. The threads themselves though are not something we often consider (outside of making sure that our thread pools are correctly configured so the runtime behaves nicely) because they're really just an implementation detail of the runtime.

Fabio's talk is really good you should watch it :-)

Dario Abdulrehman
what are the applications of Cokleisli?
Daniel Spiewak
I've honestly never used it
I would ask in the typelevel/cats channel though
Dario Abdulrehman
thanks, I got confused and thought it was from cats-effect
Daniel Spiewak
:-) quite understandable
Ashkan Kh. Nazary
@SystemFw @djspiewak So I watched the video, thanks for the amazing talk ! learned quite a lot of stuff. But I'm still having trouble understanding the purpose of this semantics : "take fa , move it to another execution context, evaluate it and return back" while blocking the calling fiber (I understand the point is that the thread is not blocked, but fiber is blocked and it's ok to block a fiber). But can be achieved by that ? if we have to block then why take the trouble to evaluate it on a different ec?
Fabio Labella
@ashkann ok, the question makes more sense
I'm going to say "semantically blocking" for fiber blocking, and blocking for "jvm thread blocking"
so when you use evalOn, at a fiber level nothing changes
in the sense that everything is synchronous
like flatMap
however, you use evalOn when you're wrapping code which is actually thread blocking
typically java code
if you ran it in the normal pool, it would clog things
so you normally one (ore more) dedicated pools
run that that bit of thread blocking code there, then you hop back to the normal pool (the compute pool that ultimately comes from IOApp, which is meant to be used for semantically blocking code only, it's a fixed thread pool with a small number of threads)
so evalOn is only there to help you deal with code which was not designed with the fiber model in mind
does that make more sense? feel free to ask further questions if not
Ashkan Kh. Nazary
@SystemFw oh yes it makes a a lot of more sense now. So:
evalOn doesn't magically create asynchrony. It simply shifts the undesirable property of (true) blocking to an execution context that is designed for that kind of work. The logical flow of steps is still (semantically) blocked from a programmer's perspective because the calling fiber is blocked (not the underlying thread) and this is whole point.
So programmer gets to keep a synchronous interface (semantic blocking) and avoid blocking the underlying thread (some other thread on another pool runs the blocking part).
@SystemFw on a different note, why such explanations are not given on the official cats' docs ? Is it well known by everyone who is using cats-effect ?
I mean these are considered basics ?
@ashkann There’s a bit in https://typelevel.org/cats-effect/datatypes/contextshift.html, are you aware of this? The docs could have a bit more detailed explanations though…
Ashkan Kh. Nazary
@ybasket yep. read that page alone multiple times ... but now that I have a much better understanding , that page makes a lot more sense. I think that's a problem : the docs are not to teach you the underlying principles, they teach you how a particular project is using/implementing/integrating those principles. If you don't know enough of those principles from somewhere else then the docs confuse you :D
@djspiewak where would be the appropriate place to ask for your opinion on ZIO :D ?
Fabio Labella
@ashkann the docs are always a wip
it's mostly a matter of time/resources

If you don't know enough of those principles from somewhere else then the docs confuse you

note that when the docs are just about general principles, people struggle with lack of practical how-tos. You need both ideally, and that's very time consuming

I've been using talks for the foundational stuff as it takes less time
I think at the very minimum we should have a page for the relevant talks, and then I encourage everyone to help us out with the docs :)
Adam Rosien

@ashkann @SystemFw i'm working on a course + book. but i agree about always improving public docs. and i happen to have extra time available.

are there any existing issues that capture some things? i guess i'll have to take a look

also, translate the links on @SystemFw's pages to docs
Fabio Labella
the one thing I remember off the top of my head is the idea of adding a page for videos
monix and fs2 both have that
they aren't a replacement for docs but they help
Adam Rosien
@gvolpe's book has a lot of related stuff https://leanpub.com/pfp-scala
Fabio Labella
after that, I trust you :)
Adam Rosien
the current docs tend to focus on the implementation details of the library itself, which is natural and sometimes necessary. but yes, adding both general principles and practical applications are good steps forward
something something 4 types of documentation
tutorials, how-to guides, technical reference and explanation
Fabio Labella
yeah the only problem I have with that article is the amount of time required to do all that :)
Gavin Bisesi
I think a good first step would be making sections that people can edit into
Ashkan Kh. Nazary
I would say a curated list of "material" is a nice way to start. A newcomer has literally books to learn before the can even make sense of the project docs
Arulselvan Madhavan
Beginner question: How do I create ContextShift[IO] without having to mixin IOApp? I'm working on introducing cats-effect into an Akka codebase and would like to use specific execution contexts to create different ContextShift[IO]. It seems IOContextShift is there but it's part of cats.effect.internals package
Fabio Labella
Arulselvan Madhavan
Thanks @SystemFw I wish I had a working emacs setup to get suggestions on methods
Fabio Labella
tell me about it :P
Mark Tomko
Is there a pattern for doing something like this:
  type Thingy
  def x[F[_]: Concurrent]: Resource[F, MVar[F, Thingy]] =
    for {
      sem <- Resource.liftF(Semaphore[F](1L))
      mvar <- Resource.liftF(MVar.empty[F, Thingy])
      fiber <- // construct a fiber that uses the semaphore and mvar and cancels when the resource is closed
    } yield mvar