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
Fabio Labella
didn't check at the time, might well be :)
Anton Sviridov
I force-pushed for a different reason (commit email), which is a dumb thing to do when you're trying to demonstrate a stuck build :D basically previous build on adopt11 spent 45 minutes on " Run sbt ++2.12.11 ci"
Raas Ahsan
ah :D do you know if it was stuck on a particular test?
thankfully actions keeps track of every workflow run
it seems like like all the tests passed and then got stuck before running mima checks
Daniel Spiewak
on rare occaisions, Actions instances can die randomly
this used to happen a lot
what causes it is the underlying Azure Pipelines instance going away
when that happens, teh build just... hangs roughly forever
that sounds like what happens

Beyond that, I discussed with @marcraminv the contents of the current TCP echo server - concurrent system with Fibers section. And we conclude that most of it is hard to read and understand. As I'm the author it pains me to admit it :) , but it is likely we should replace it with something easier to follow. E.g. we considered implementing a solution for the producer-consumer problem. What do you think?

Producer-consumer seems a lot easier to follow! Like, I love the TCP echo server concept, but it's definitely difficult to follow and requires some setup.

Something I've struggled with sometimes is whether or not it's worth referencing ecosystem projects

Like, you wouldn't implement a TCP server from scratch with vanilla CE, you would use another library which builds on top of CE and exposes that kind of fucntionality, then you would implement an echo server
Daniel Spiewak
Basically what I'm saying is it's hard to write tutorials :-)
Anand Krishnan
Hi is there a way to use ConcurrentEffect[F].start{...} inside Resource.use() in a safe way?
Gavin Bisesi
Yes, but start is very low level, and you're better off using another abstraction
depending on what you want to do
fs2 allows a very high level and composable api for dealing with concurrency
basically, you want to spend your time writing business logic, not writing concurrency-safe low level stuff
Anand Krishnan
Yeah I have an aws client as resource that is pushed in from the top level. I need to use that resource in my business logic. One part of the business logic can be executed concurrently (which makes use of the above resource). So I want the resource to be freed only when the concurrent task also is completed. What are other options than start? I tried background get back the concurrent execution as a resource. That also is not completing the work somehow.
Gavin Bisesi
Streams would make that easier, definitely
Does it have to be released before your app closes? Not appropriate to open/close on init/shutdown?
Anand Krishnan
Actually I assumed it will be better to start up a client for each request, not for the full app.
Daniel Spiewak

Actually I assumed it will be better to start up a client for each request

Sounds relatively expensive. If the client is shareable across threads, then you're definitely better making it at app startup rather than per-request

Gavin Bisesi
Depends what the client is and if you need to have multiple of them
If it's something like an http4s client, you absolutely want one for the whole process lifetime
because the resource is expensive to construct, and what it gives you is more efficient per-usage actions
(it does connection pooling, keep-alive, etc)
most resources you want to construct once and then pass down to your app already-alive
it's relatively rare that you really want to be dealing with Resource inside your biz logic
Anand Krishnan
Yeah I am not happy the way I coded it, thanks for the suggestion @Daenyth and @djspiewak I will try to make it application level.
Hello awesome cats-effect team! Thanks for all your hard work :)
Adam Rosien
they are awesome!
Luis Rodero-Merino

Basically what I'm saying is it's hard to write tutorials :-)

Yes, absolutely :) . So, ok, agreed. @marcraminv and I will try to work on it. Thanks for the feedback!

Do you guys use explicit Kleisli in a "tagless-final" code, or hide it behind another parametric type, having (say) F and G for a types with and without context?
I'm aware of cats-mtl, but what if you need to eventually provide a context and convert reader-like G to a non-reader F?
Adam Rosien

@rnd4222_gitlab like

trait Train[F[_]] {
  def toot(): F[Unit]

object Train {
  def apply: Train[Kleisli[IO, Whistle]] = ???


trait Train[F[_]] {
  def toot(): Kleisli[F, Whistle, Unit]


i usually use the former, and usually add

trait Train[F[_]] {
  def toot(): F[Unit]
  def mapK[G[_]](f: F ~> G): Train[G]

(cats-tagless can auto-generate these also)

@arosien more like
trait Train[F[_]]
trait Sound[F[_]]
class Whistle[F[_] : ApplicativeAsk[*[_], Volume], G[_]]
Adam Rosien
does Whistle[F, G] extends Sound[F]?
sorry, i must be missing something
there's using Kleisli vs. ApplicativeAsk, that's one choice
I'm now working in a project where "tagless-final-to-the-max" approach was taken.
There is always different types for Fs with different contexts.
Lots of custom Lift/Unlift classes for conversion back and forth.
Oh, and it uses doobie, so add another two types - one is instantiated to ConnectionIO and second to Kleisli[ConnectionIO, ...], both with its own lifts-unlifts
So I wanted to know if its usual approach or not
Adam Rosien
hmm. so for the impls/interpreters of those algebras there isn't 1 type like IO that's used for F, there are multiple, so you end up translating a lot?
is there some intermediate type like class BizLogic[F[_]](alg1: Alg1[F], alg2[Kleisli[F, Dependency]])? because something like that would be difficult.
or at least more complicated than it probably should be. but i'm just guessing because i'm not sure of the structure you are describing.
It's usually in a places where some context is added/eliminated, for example in HttpRoutes or SomethingRepository
typical signature is
def withRequestId[F[_], G[_] : WithRun[*[_], F, RequestId[F]](routes: HttpRoutes[F]): HttpRoutes[G]
Adam Rosien
i definitely know that there are good reasons to need to lift/unlift between types, especially with Kleisli. but where that happens is the question.