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've seen people use it as a singleton semaphore for tests
but even that seemed a bit less useful than… Semaphore
Piotr Gawryś
@Avasil
Maybe some producer-consumer scenarios but there is also just 1-element async queue
Fabio Labella
@SystemFw
@rzeigler I reached the same conclusion, which then led me to design Ref + Deferred the way they are, to avoid conflating concurrent state and synchronisation
ruslan
@unoexperto
Guys, I've asked few questions about fiber cancelation yesterday and look like release handler of IO.bracketCase() is called in the same thread I'm executing IO with. For me it means if IO contains blocking operation I can't really cancel it. Is there a way to overcome it ?
Dan Di Spaltro
@dispalt
@rzeigler I was thinking like token refreshes on some client side api
Ryan Zeigler
@rzeigler
ah, like it has expired so don't use it until we insert a new one that can be consumed?
Oleg Pyzhcov
@oleg-py
@unoexperto in case of cancellation, finalizer call originates on thread that triggers cancellation.
https://scastie.scala-lang.org/4CnzLEZfRG6ze79PY150Fg
Gavin Bisesi
@Daenyth
So far we've bit ourselves multiple times by having failures preventing our IOApp from coming up. Does anyone have a pattern or example of some kind of automated testing? Maybe some kind of scalatest src/it magic that can launch an IOApp main process into a separate jvm or something and perform some kind of health check -> sigterm ?
Ross A. Baker
@rossabaker
What is "not coming up"? Not working and not exiting?
Gavin Bisesi
@Daenyth
Latest example was a deadlock on a lazy val on the object which was trying to lzyCompute$ from inside an IO
but I also have hit classpath issues which got masked by the "doesn't exit jvm when not NonFatal" bug
Ross A. Baker
@rossabaker
I don't know how we'd implement a universal health check. There isn't really a life cycle beyond List[String] => IO[ExitCode].
Gavin Bisesi
@Daenyth
Well, the deadlock didn't respond to SIGTERM :)
If I could get "launch jvm with main, capture stdout + exitcode" that would be enough to see whether it crashed or locked
and I could have it emit a positive message to stdout once successfully initialized, and check for that with if I had the output
Rohde Fischer
@rfftrifork

I'm trying to make a very simple looping function with a delay using CATS effects (2.0.0-RC1 due to Scala 13).

import cats.effect._

import scala.concurrent.duration.FiniteDuration

object TaskScheduler {
  def loop[F[_] : Sync](delay: FiniteDuration, fun: () => F[Unit])
      (implicit timer: Timer[F]): F[Unit] =
    for {
      _ <- timer.sleep(delay)
      _ <- fun()
      _ <- loop(delay, fun)
    } yield ()
}

however, when I try to compile this I get:

sbt:root> tickets/compile
[info] Compiling 15 Scala sources to /home/rohdef/git/smart-tickets/tickets/target/scala-2.13/classes ...
[error] /home/rohdef/git/smart-tickets/tickets/src/main/scala/dk/rohdef/scheduler/TaskScheduler.scala:11:23: value flatMap is not a member of type parameter F[Unit]
[error]       _ <- timer.sleep(delay)
[error]                       ^
[error] /home/rohdef/git/smart-tickets/tickets/src/main/scala/dk/rohdef/scheduler/TaskScheduler.scala:12:15: value flatMap is not a member of type parameter F[Unit]
[error]       _ <- fun()
[error]               ^
[error] /home/rohdef/git/smart-tickets/tickets/src/main/scala/dk/rohdef/scheduler/TaskScheduler.scala:13:16: value map is not a member of type parameter F[Unit]
[error]       _ <- loop(delay, fun)
[error]                ^
[error] three errors found
[error] (tickets / Compile / compileIncremental) Compilation failed
[error] Total time: 2 s, completed Aug 10, 2019 1:23:20 PM
sbt:root>

which puzzles me thoroughly, since Sync is a Monad as far as I can see, so both map and flatMap should be present to my knowledge. So, what am I doing wrong?

Piotr Gawryś
@Avasil
@rfftrifork you're probably missing import cats.syntax.all._
btw if F is Sync then you don't need () => F[Unit]. It should be equivalent with F[Unit]
Rohde Fischer
@rfftrifork

@Avasil bingo, thanks a lot :) Now it's giving unrelated error, which I expected :) neat

regarding () => F[Unit] vs F[Unit] I have have a def task[F[_]: Concurrent](): F[Unit] = ??? that I'm currently intending to pass to the loop. Would it be better to do loop(task()) rather than loop(task), or am I completely missing the point

?
Piotr Gawryś
@Avasil
With () => F[Unit] you will be evaluating a description of your task with each call and it's redundant because it should always evaluate to the same thing. So I think you could just use def task[F[_]: Concurrent]: F[Unit] (without parentheses)
You would need something like this with Future but fortunately that's not necessary with IO implementations
Rohde Fischer
@rfftrifork
@Avasil ok, thanks :) I'll play around. Always good to improve
Rohde Fischer
@rfftrifork
according to https://typelevel.org/cats-effect/tutorial/tutorial.html#polymorphic-cats-effect-code it's recommended to write effects in terms of F[_] rather than IO, cool I like that. But I ran in to an issue, mainly how to do this with a Futurefrom an external API? I cannot seem to find any general trait having a fromFuture or similar. How is it best to approach this?
Daniel Ochoa Rodríguez
@tzimisce012
In the last release Async has a fromFuture method
If you are still on 1.x
You have to do the transformation manually :D
Rohde Fischer
@rfftrifork
@tzimisce012 I'm on 2.0.0-RC1 due to Scala 13, so I guess that is there too, two secs, will check :)
Daniel Ochoa Rodríguez
@tzimisce012
I think the last version is RC5
It has couple days
Rohde Fischer
@rfftrifork
are you sure? There's an M5 and RC1, and I assume RC comes after M :S
dates seems to agree with my assumption :)
anyhow, it seems it's not there, thanks for the response @tzimisce012 :)
Daniel Ochoa Rodríguez
@tzimisce012
Rohde Fischer
@rfftrifork
@tzimisce012 thanks, then I can copy that until it reaches a release. I haven't checked how the releases deal with changes, but I guess it would make sense if it arrives in 2.1.0 :)
Daniel Ochoa Rodríguez
@tzimisce012
It just arrived!
Rohde Fischer
@rfftrifork
strange, hmm that must mean my dependencies are resolved in a wrong way :/ (checking)
it is resolving M4, that explains why fromFuture is missing at least
Daniel Ochoa Rodríguez
@tzimisce012
👍
Rohde Fischer
@rfftrifork
@tzimisce012 thanks :) Will see if I can't make it work then
Ross A. Baker
@rossabaker
RC1 is the latest.
Don't mix cats.syntax with cats.implicits. I always just choose the latter.
And fromFuture is right. You can't just use Future as F because it's strict and therefore can't have a Sync instance.
Rohde Fischer
@rfftrifork
@rossabaker thanks, changed it to implicit. I'm not going to Future as F, I'm going for getting rid of the Future as fast as possible in favor of a cats instance, so I have referential transparency etc. :)
Ross A. Baker
@rossabaker
:+1: That's my standard lecture when someone mentions Future.
Rohde Fischer
@rfftrifork
understandable :) had to wrap my head a bit, but thanks to Fabio Labella's talk it became a lot easier :)
Ross A. Baker
@rossabaker
Usually the next part of the lecture is to send people to Fabio. :)
Rohde Fischer
@rfftrifork
xD makes sense