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
if f calls cb and then goes on to do other things asyncly, then yes
Ross A. Baker
Yes, exactly.
I think this is what we need.
Fabio Labella
yeah, I think that works then
Ross A. Baker
Writing a test for this issue is a huge pain.
Fabio Labella
Ross A. Baker
It only happens under load, and as asynchronous logging in a Jetty-owned thread.
Fabio Labella
yeah, sounds beautiful
Ross A. Baker
I added a unit test to ensure I didn't break the happy path and have a manual reproduction.
Even the unit test sucks, because I can't pass around a Clock in this world. It's wall-time timeouts in a scheduler I don't own.
Fabio Labella
ah, that sucks
I have a similar situation in upperbound because I haven't migrated to TestContext yet
forget about running that on CI with any semblance of reproducibility
Ross A. Baker
Yeah, I'm afraid this is going to be the next generation of our flaky Travis tests.
I can make it less flaky by waiting longer and increasing the run time of every build.
Maybe we can port jetty to cats-effect. :trollface:
Fabio Labella
heh, I tinkered with those two knobs (how flexible each test should be, and how long do I want the whole suite to run ) for ages :joy:
same thing for fs2 retry, until those tests are ported as well (I think we turned them off altogether )
Ross A. Baker
Is fs2 RC still on track?
I guess I should ask there.
Fabio Labella
yes it is
two PRs
and I want to add an absolutely trivial combinator as well, if I get the time
well, I feel like I've done my daily (weekly?) bit of http4s maintenance, off to sleep :P
Ross A. Baker
If you have insomnia, I've got like five PRs queued up.

Guys, I have a question about error handling. Imagine I have OptionT[IO, Value] like this

case class FailureMsg(code: String, ex: Option[Throwable])

val fff: IO[Either[FailureMsg, Int]] = OptionT.some[IO](12345)
  .map { value ⇒
    println("Mapping over")
  .flatMapF[Int](_ ⇒ IO.raiseError(new RuntimeException("err1")))
  .toRight(FailureMsg("Code0", None))
  .recoverWith {
    case ex ⇒ // Not Throwable!
      EitherT.leftT[IO, Int](FailureMsg("Code1", Some(ex)))

How can I catch err1 and wrap it into Left[FailureMsg]. I expected recoverWith help me but surprisingly it's alias of mapLeft. What should I do ? (SO copy

Fabio Labella

If you have insomnia, I've got like five PRs queued up.

Thankfully I didn't see this...

Alex Milkov
The docs say that unsafeRunSync will throw an exception upon encountering an async boundary. Can't seem to create this behavior and I think it's because I'm misunderstanding something. For example this doesn't throw an exception:
IO(IO.async((cb: Either[Throwable, Int] => Unit) => cb(Either.catchNonFatal(5))).runAsync{
    case Left(err) => IO(println(s"Err ${err.getMessage}"))
    case Right(res) => IO(println(s"Res: $res"))
Fabio Labella
@amilkov3 where do the docs say that?
that's not what unsafeRunSync will do
it will wait on an async boundary
Alex Milkov
Fabio Labella
ah, on scala.js
Alex Milkov

From docs:

If any component of the computation is asynchronous, the current
thread will block awaiting the results of the async computation.
On JavaScript, an exception will be thrown instead to avoid
generating a deadlock. By default, this blocking will be
unbounded. To limit the thread block to some fixed time, use
unsafeRunTimed instead.

yea sorry shouldve been more specific
Fabio Labella
sure, you didn't say you're on Scala.js :)
Fabio Labella
@amilkov3 I can't help that you much on scala.js, but
if you look at unsafeRunSync, you see that it calls unsafeRunTimed
which in turn calls unsafeResync an Async nodes
which calls a method on IOPlatform
IOPlatform differs between the two platforms, so you need to look at the js one
your code doesn't throw because you are using runAsync first
if you look at runAsync scaladoc
 * The returned `IO` is guaranteed to execute immediately,
   * and does not wait on any async action to complete, thus this
   * is safe to do, even on top of runtimes that cannot block threads
   * (e.g. JavaScript):
try IO.never.unsafeRunSync on JS and the JVM
on the JVM it should never terminate
on JS it should throw