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
Assen Kolov
@kolov
What can I be doing wrong to get an [error] ... Symbol 'type cats.Parallel.Aux' is missing from the classpath. [error] This symbol is required by 'method cats.effect.IOInstances.ioParallel' on implicit val ec = implicitly[ExecutionContext] implicit val cs: ContextShift[IO] = IO.contextShift(ec) val sync = implicitly[Sync[IO]]
I see cats-effects 1.5.0 is evicted by 2.0.0 in the project, but in this code excerpt it is the same IO, isn't it?
Paul Snively
@paul-snively
No; that's your issue. Something that depends on cats-effect 1.5.0 is getting 2.0.0 instead.
Assen Kolov
@kolov

That is the whole class: ```class ClientTestEnv extends AsyncFlatSpec with Matchers with BeforeAndAfterAll {

implicit val ec = implicitly[ExecutionContext]
implicit val cs: ContextShift[IO] = IO.contextShift(ec)
val sync = implicitly[Sync[IO]] }```

Paul Snively
@paul-snively
Of course you have a cats-effect dependency. The question is, what's evicting 1.5.0 in favor of 2.0.0?
Assen Kolov
@kolov
Me, I defined cats-effect 2.0.0 in sbt. Actually, cats-core 1.5.0 is evicted in favour of 2.0.0, no cats-effect conflicts.
Paul Snively
@paul-snively
Well, you can’t do that without upgrading the library with the 1.5.0 dependency.
Assen Kolov
@kolov
it comes through circe 0.9. Do you think there's any circe code executed in the class above?
Paul Snively
@paul-snively
You need to upgrade Circe, then.
Daniel Spiewak
@djspiewak
actually there seems to be a more serious issue here
cats-effect should be binary compatible between 1.5 and 2.0, and cats itself should be as well, so the evictions shouldn't matter, but that's exactly at it looks like is happening
@kolov can you tell me what your cats-effect, cats, and circe versions are? circe 0.9 I take it?
Oleg Pyzhcov
@oleg-py
it actually sounds like cats-core 1.5.0 is used instead of 2.0.0. Parallel.Aux - which is missing - is cats 2 thing
Daniel Spiewak
@djspiewak
yeah, so cats is backwards compatible, it is not forwards compatible
so if cats-effect is pushed forward to 2.0.0, then cats must be as well
cats-effect would not be compatible at all with cats-core 1.x
Assen Kolov
@kolov
@djspiewak from sbt evicted : org.typelevel:cats-core_2.12:2.0.0 is selected over 1.5.0, io.circe:circe-core_2.12:0.12.1 is selected over 0.11.0, cats-effects is 2.0.0.
After I posted this I noticed that in another class with different extends in the same project very similar code compiles without problems. I'll look further tomorrow.
Paul Snively
@paul-snively
OK, so something depends on circe-core 0.11.0, which depends on cats-core 1.5.0.
@kolov: If we can figure out what depends on circe-core 0.11.0, that'll help.
@kolov: I recommend the sbt-dependency-graph plugin.
Daniel Spiewak
@djspiewak
sbt-coursier has an even better coursierDependencyTree command, which I've always found to be more helpful than sbt-dependency-graph. It's a bit weird now though given that coursier is baked into sbt 1.3.0+
Paul Snively
@paul-snively
:+1:
davidnadeau
@davidnadeau

If I have an IO with a timeout:

IO(somefn).timeout(100 millis)

Is it possible for somefn to create an IO which doesnt get timed out?

def somefn = {
   readDb >> computeSomething >> fireOffaTask >> updateDb
}

I'm trying to have the fireOffaTask run without being effected by timeout.

davidnadeau
@davidnadeau
I'm thinking to just use Future to fire it off, but I'd rather keep it IO if possible.
Gabriel Volpe
@gvolpe
Maybe ioa.start.void? @davidnadeau
Not sure what you're trying to achieve exactly
Do you care about error handling in that task you want to run in the background?
davidnadeau
@davidnadeau
yes, but it can handle that itself.
im trying to implement a fire and forgot. That won't get a timeout exception.
also ioa.start.void will still get timeout exception.
Gabriel Volpe
@gvolpe
You would only get the timeout if the timeout happens before calling ioa.start.void
If you don't want that, then you'd need to do things differently
davidnadeau
@davidnadeau
it will timeout even after calling ioa.start.void
Gabriel Volpe
@gvolpe
that shouldn't happen, are you sure?
davidnadeau
@davidnadeau
  def firenforgetExample: IO[Unit] = {
    (for {
      _ <- IO(println("start"))
      _ <- IO.shift >> longTask.start.void
      _ <- IO(println("end"))
      _ <- IO.never
    } yield ()).timeout(500 millis)
  }

  def longTask: IO[Unit] =
    for {
      _ <- IO(println("first part"))
      _ <- IO.sleep(600 millis)
      _ <- IO(println("second part"))
    } yield ()
never prints second part
start
first part
end
Gabriel Volpe
@gvolpe
are you running this program in intellij idea by any chance?
davidnadeau
@davidnadeau
ya i am
Gabriel Volpe
@gvolpe
run it from the terminal using sbt and see if the behavior changes, normally that's just Idea being wrong
davidnadeau
@davidnadeau
oh, it works from sbt.
ok great, this is the behaviour i wanted. Thanks for the help.
Gabriel Volpe
@gvolpe
No problems :)
Ivan Aristov
@Ssstlis
I rerun this example for i few times and it not always do println("second part"), also i see that @davidnadeau using shifting, but you shift to default runloop ContextShift, is this doing nothing, am i right?
Gabriel Volpe
@gvolpe
That's due to the main thread being killed when the main program finishes. You need to keep the main thread alive in order to keep other fibers running in the background, otherwise they get killed too.
And yes, that IO.shift doesn't do anything. start already introduces an async boundary IIUC.
@Ssstlis
Ivan Aristov
@Ssstlis
Thanks :)
Kai
@neko-kai

@djspiewak

it's interesting that it's actually slower than the new Throwable().getStackTrace() approach and less flexible

The only way to get new Throwable in the correct place is to modify every IO constructor – if you do that it’s impossible to turn tracing on/off NON-globally – ZIO supports _.traced and _.untraced regions for lexically-scoped control of tracing, which allows you to omit tracing overhead for the parts that are heavy on flatMaps and low on information (fs2, Gen, etc.) or in hot spots and gain back 2x performance before tracing patch

Kai
@neko-kai
That was the main reasoning for choosing bytecode parsing – users should never be faced with a dillemma “do I run with tracing to debug my problem or run at high performance?”, because IMHO the worst problems are the problems you don’t expect and can’t reproduce – tracing should be always on to provide the most info in a bad situation and the odd monadic hotspots can be wrapped ad-hoc.