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
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
is there a point to prefer def foo[F[_]: Sync[F]]() = ??? over def foo[F[_]]()(implicit F: Sync[F]) I kind of like the flexibility by the implicit setup, but I was wondering because the tutorial use the former version. Am I doing it bad, is it taste, or?
Rohde Fischer
@rfftrifork
sorry [F[_]: Sync] of course :)
Ross A. Baker
@rossabaker
I think the context bound makes the signature more readable, and the named implicit makes the implementation more readable.
Fabio Labella
@SystemFw
I start from F[_]: Sync] and switch over to implicit F: Sync[F] if the body contains too many Sync[F].delay
Gabriel Volpe
@gvolpe
I prefer context bound as well whenever possible.
If you have some spare time I wrote about the different approaches and its performance implications @rfftrifork.
(shameless plug 😄)
Rohde Fischer
@rfftrifork
@gvolpe nice, will take a look :)
@SystemFw and @rossabaker good points, thanks for the input :)
anil chalil
@capacman
Hi all, i am writing a simple program that access to db via jdbc but i currently i dont want to use doobie. In my code i prepared a small utility like below. Is it enougn to handle local transactions or is there any edge cases that i miss? Thank you in advance:
implicit class richIODatasource[D <: DataSource, F[_]:Sync](val ids: F[D]) extends AnyVal {
    import cats.effect.ExitCase.{Completed, Error, Canceled}

    def use[T](f: Connection => F[T]): F[T] =
      Resource.fromAutoCloseable[F, Connection](ids.map(_.getConnection())).use(c => f(c))

    def transaction[T](f:Connection => F[T]):F[T] = use{ c =>
      Sync[F].bracketCase(Sync[F].pure(c).map{c =>
        c.setAutoCommit(false)
        c
      })(f){
        case (in, Canceled | Error(_)) =>Sync[F].delay(in.rollback())
        case (in,Completed) => Sync[F].delay(in.commit())
      }
    }
  }
Rohde Fischer
@rfftrifork
@capacman I'm fairly new to effects, but to me it looks correct. I'm wondering though if you'd need a begin transaction call. I seem to recall the ExitCase of bracket is a sealed trait, so I think you'll get a compiler warning if you don't cover all cases possible, but if I remember wrong then you might consider a default case where you do a rollback. Also slightly beside your point, I'll strongly urge you to log errors, including the input that cause them ;)
anil chalil
@capacman
Hi @rfftrifork , thank you for comments. Yes some logging absolutely necessary. I just wonder what happens in case of a exception in bracketcase? Because in documentation it say behavior depends on impl of F. Probably i need to write a test. Thanks again