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
Daniel Spiewak
@djspiewak
I like last
well, last in the first argument block
Adam Rosien
@arosien
go crazy and use lexigraphic ordering
PandaSeal20
@PandaSeal20
Hi, I am struggling to find what I am after. I have a future that I want to terminate after a certain amount of time has passed (e.g. is being too slow). I am writing this using cats and I have a ConcurrentEffect representing the future. Should I use a Timer to measure how long the call is taking? I think there must be a simpler way to get to what I am trying to achieve. Feel free to point me to examples if any exist.
Gavin Bisesi
@Daenyth
Futures can't be cancelled or terminated
if you have an IO instead of a Future, then it's .timeout(duration) or timeoutTo(duration, someOtherIO)
Gavin Bisesi
@Daenyth
methods like timeout on generic F come from import cats.effect.implicits._
Adam Rosien
@arosien
it is basically implemented as Concurrent.race between the task and a Timer.sleep
Ashkan Kh. Nazary
@ashkann
Hi guys, I have a pretty basic question I'm not sure this is the right place to ask :
I realized ContextShift.evalOn(fa) is blocking as in : the calling thread is blocked until fa is finished evaluating. Whats the point of an API that evaluates a piece of code on another thread but blocks for it to finish as well ? Isn't the whole point of this to shift a (potentially blocking) piece of code to another thread so the current thread does not block and can continue ?
Gavin Bisesi
@Daenyth
No threads are blocked
If you wrap impure thread-blocking code using Sync you can use the ContextShift to make that thread blocking execute on an EC you pick, usually one marked by Blocker
Nothing in cats-effect blocks threads though
semantic blocking is different
Fabio Labella
@SystemFw
I think you might be misunderstanding synchronous (fa completes when the underlying task completes), with blocking (the underlying thread blocks)
if you want to spawn something, you need to look at start
Ashkan Kh. Nazary
@ashkann
@SystemFw I well might be ... care to elaborate ? or point me to a link or something ?
Fabio Labella
@SystemFw
I explain this in depth in my fiber talk
Ashkan Kh. Nazary
@ashkann
@SystemFw 404 Not Found :(
Fabio Labella
@SystemFw
edited
it should work now
Ashkan Kh. Nazary
@ashkann
Thanks. Will watch and get back at you :D
Fabio Labella
@SystemFw
:)
Ashkan Kh. Nazary
@ashkann
@Daenyth Thank you :pray:
Fabio Labella
@SystemFw
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
@djspiewak

@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
@dabd
what are the applications of Cokleisli?
Daniel Spiewak
@djspiewak
I've honestly never used it
I would ask in the typelevel/cats channel though
Dario Abdulrehman
@dabd
thanks, I got confused and thought it was from cats-effect
Daniel Spiewak
@djspiewak
:-) quite understandable
Ashkan Kh. Nazary
@ashkann
@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
@SystemFw
@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
@ashkann
@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 ?
ybasket
@ybasket
@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
@ashkann
@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 ?