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
David Flynn
@WickedUk_gitlab
Main task is also an IO and runs with unsafeRunSync
James Rockett
@jrockett6
I'm new to cats, so I may not be very helpful. But have you taken a look at Bracket or Resource?
https://typelevel.org/cats-effect/typeclasses/bracket.html
https://typelevel.org/cats-effect/datatypes/resource.html
Raas Ahsan
@RaasAhsan
Concurrent.background is the recommended way to start an IO concurrently and "ignore" its outcome
which does return a Resource :)
David Flynn
@WickedUk_gitlab
Is there any documentation for this?
looks like Gitter doesn't recognize the whole link, but the Scaladoc is the most comprehensive description we have of the method I believe
David Flynn
@WickedUk_gitlab
Okay thanks, there should be a rule, no documentation on the webpage, the feature doesn't exist :-)
Otherwise you're getting misdirected by the documentation that is there to do it another way.
Raas Ahsan
@RaasAhsan
Yeah, I'm with you all the way there. The majority of the documentation on the website was written before 1.x was released, and new features and changes since then are more or less neglected by it
one of which was Concurrent.background IIRC
David Flynn
@WickedUk_gitlab
I'd be happy to help out, but I'm still pretty much an effect newbie. With a certain other tech doing all it can to establish itself, if that becomes easier to get up to speed with, then cats effect will begin to decline, which would be a shame given the work gone into it.
val longProcess = (IO.sleep(5.seconds) *> IO(println("Ping!"))).foreverM

val srv: Resource[IO, ServerBinding[IO]] = for {
  _ <- longProcess.background
  server <- server.run
} yield server

val application = srv.use(binding => IO(println("Bound to " + binding)) *> IO.never)
What's server.run ?
Raas Ahsan
@RaasAhsan
That would be very much appreciated! We've identified gaps in documentation as an issue and have been taking some steps to address it. For the next CE release, there will actually be a completely new documentation site (content will remain unchanged for now). Most of the current maintainer efforts are dedicated towards CE3 though, where we're aiming to be much stricter on documentation standards
So, in that example, Resource is being used to scope the lifecycle of some dummy application that starts a longProcess and some kind of network server, both of which are captured via Resource
David Flynn
@WickedUk_gitlab
so server.run is something else that also runs, but we don't care what it is or how it does it, just that longProcess.background doesn't block the flow ?
Raas Ahsan
@RaasAhsan
yeah, exactly. as long as you're inside the scope of that nested Resource, longProcess will continue to run (unless it terminates on its own)
David Flynn
@WickedUk_gitlab
And I suspect if it was a complete example it would be pinging the server
Raas Ahsan
@RaasAhsan
Yeah, we should honestly have complete examples for things like this.
David Flynn
@WickedUk_gitlab
so in my case I've got two servers, and one can cause the other to exit, so I could do two background calls inside a resource, and some kind of wait until both are to be killed at the end
Raas Ahsan
@RaasAhsan

and one can cause the other to exit

What's the nature of this?

David Flynn
@WickedUk_gitlab
I have a server that I can issue commands to (effectively a telnet server), and another server that is acting like a cps / rss feed. If the user shuts down the command server, you want the feed server dead as well. You don't want the application to exit until both servers have shut and cleaned up.
Raas Ahsan
@RaasAhsan
got it, Resource is perfect here then
one detail about use is that once it exits, it will free all the Resources that are currently bound. In the example above, IO.never was used so that the server never terminates
David Flynn
@WickedUk_gitlab
It's because I'm a server side engineer and I don't have time to learn react.js properly to write a nice front end
Raas Ahsan
@RaasAhsan
If you want to instead have it wait on some shutdown condition, you can introduce a Deferred and block on that inside use with get. Then Deferred should be completed whenever the shutdown command is issued
David Flynn
@WickedUk_gitlab
okay, that helps. Thanks
Raas Ahsan
@RaasAhsan

It's because I'm a server side engineer and I don't have time to learn react.js properly to write a nice front end

I completely sympathize with that :joy:

James Phillips
@jdrphillips
Sorry if this has been asked before. Is there a library or an integration somewhere for testing using Resource?
My use-case is that a Resource, say an http client, has to be opened in beforeAll and closed in afterAll
Obviously this is not possible using Resource and the test framework directly. I figure it must have been solved by someone?
Paul Snively
@paul-snively
@jdrphillips: cats-effect-testing?
James Phillips
@jdrphillips
Is that the solution? I found it but assumed it was a random guy doing his own thing
I'll look more into it! Thanks
Michael Pilquist
@mpilquist
that random guy is the founder of cats-effect :)
James Phillips
@jdrphillips
hah
Probably legit then
Michael Pilquist
@mpilquist
:)
Paul Snively
@paul-snively
I mean, he can be kind of random, I guess? ;-)
Fabio Labella
@SystemFw
also look at weaver
Paul Snively
@paul-snively
Right. If you can possibly change test frameworks: Weaver, MUnit's cats-effect module, Kallikrein...
Daniel Spiewak
@djspiewak

Okay thanks, there should be a rule, no documentation on the webpage, the feature doesn't exist :-)

Yes. This. 100%

I mean, he can be kind of random, I guess? ;-)

tbh I'm pretty random :-)

We're starting to see a trend towards tighter integration with functional effects in testing frameworks. Weaver was really the first one here, but munit and even scalacheck now have support (via external modules). I would expect the next version of Specs will be in a similar boat.
In a sense, cats-effect-testing is a short-term "catch all" shim that fills in the gaps for frameworks which haven't already added this kind of support
I'd like to see it disappear someday :-)
Paul Snively
@paul-snively
@djspiewak: Right now, I think it fills a crucial role in integrating with the major frameworks that are already in heavy use and tend to have painful backward-compatibility stories upon upgrading.
Someone says "We're using ScalaTest," and they (probably) won't have much pain using cats-effect-testing with it.
Daniel Spiewak
@djspiewak
that's the goal exactly!
I don't want people to have to use a separate testing framework to have a nice experience with IO and Cats Effect in general
also part of my motivation here is exceptionally selfish, since you can pry Specs2 from my cold, dead hands :-P