by

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
Gavin Bisesi
@Daenyth
Once use completes the client is released
It won't work to return a closure over it
Whatever needs to use the client needs to be in use, whatever needs to observe the lifecycle invokes use
Types can't help with this unfortunately, it's something you just kind of need to get a feel for
Mark Kegel
@littlenag
yeah, that was my intuition that the closure would just throw errors
Gavin Bisesi
@Daenyth
https://typelevel.org/blog/2018/06/07/shared-state-in-fp.html
^ This is a critical read for how to get a handle on data sharing in FP
tldr: Scope of shared data === scope of shared call graph
as your base intuition
Adam Rosien
@arosien
the code https://typelevel.org/cats-effect/datatypes/contextshift.html#blocker doesn't seem to ever unblock when something is written to stdin... any ideas?
i type something and press enter and... nothing
def readName[F[_]: Sync: ContextShift](blocker: Blocker): F[String] = 
  // Blocking operation, executed on special thread-pool
  blocker.delay {
    println("Enter your name: ")
    scala.io.StdIn.readLine()
  }

object MyApp extends IOApp {

  def run(args: List[String]) = {
    val name = Blocker[IO].use { blocker =>
      readName[IO](blocker)
    }

    for {
      n <- name
      _ <- IO(println(s"Hello, $n!"))
    } yield ExitCode.Success
  }
}
newline doesn't seem to be detected, thread is blocked in FileInputStream.readBytes
"cats-effect-blocker-0" #12 daemon prio=5 os_prio=31 tid=0x00007fc749808800 nid=0x5603 runnable [0x0000700006001000]
   java.lang.Thread.State: RUNNABLE
        at java.io.FileInputStream.readBytes(Native Method)
        at java.io.FileInputStream.read(FileInputStream.java:255)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
        - locked <0x000000076ab1cd28> (a java.io.BufferedInputStream)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        - locked <0x000000076d6bf650> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:184)
        at java.io.BufferedReader.fill(BufferedReader.java:161)
        at java.io.BufferedReader.readLine(BufferedReader.java:324)
        - locked <0x000000076d6bf650> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:389)
        at scala.io.StdIn.readLine(StdIn.scala:30)
Daniel Spiewak
@djspiewak
dumb question, but are you sure newline is actually being sent?
Gavin Bisesi
@Daenyth
yeah I'm suspicious. Pretty sure I've used raw readLine before and it worked
Adam Rosien
@arosien
weird, i'm running via bloop run. if i run via sbt run, i get
[info] [ioapp-compute-0] waiting for input
[info] Enter your name: 
[info] Hello, null!
[success] Total time: 11 s, completed Jun 4, 2020 11:25:22 AM
Gavin Bisesi
@Daenyth
hm, strange
Are you sending EOF? I thought that's what gives null

Huge thanks btw to everyone here for adding Parallel[Resource]. I just updating my http application with some parMapN and startup time cut in half
Daniel Spiewak
@djspiewak
:-D
that was @SystemFw
Gavin Bisesi
@Daenyth
@SystemFw How many /dev/beers do I owe you now? I think I lost count ;)
Daniel Spiewak
@djspiewak
@arosien I wonder if something is all wonky with pipes and things. Have you tried forking?
Gavin Bisesi
@Daenyth
@arosien maybe also try with sbt-revolver, I think I used that over sbt run before
but forking likely would result in the same
Adam Rosien
@arosien
fork := true
something wonky indeed
Fabio Labella
@SystemFw
glad you found it useful. I mostly did it since it was an interesting challenge tbh :P
Gavin Bisesi
@Daenyth
Very useful. Heroku imposes a hard cutoff 90sec timeout on binding a port for your http node before it kills it
uh I think actually 90s is what you get if you beg their support, IIRC the default is actually lower
Initialize enough hikari pools and other things in serial order and that 90sec vanishes rapidly
RafaƂ Krzewski
@rkrzewski
@arosien bloop run doesn't work well with stdin at the moment: scalacenter/bloop#882
Adam Rosien
@arosien
@rkrzewski ah thank you!
Ben Kirwin
@bkirwi
:wave: hi! question about fiber cancellation - the docs have for cancel have: "Depending on the implementation, this task might await for all registered finalizers to finish, but this behavior is implementation dependent." What happens in the case of IO? (Or is it implementation-dependent in some different way?)
Gavin Bisesi
@Daenyth
I think the wording may be dated
If an acquire completed, release will happen if you cancel
Ben Kirwin
@bkirwi
cool! and that release is guaranteed to happen by the time the cancel token finishes running? ie. resource.use(a => whatever).start.flatMap(_.cancel)
will definitely have run the release action by the time it's done running?
(i'm looking at implementing some "graceful shutdown" code for something, and i'm trying to figure out if it's evil / safe to have some long-running cancellation action...)
Gavin Bisesi
@Daenyth
If the wording is correct and not dated, I believe that is the point that it says is impl-defined. I don't know the answer
I'd avoid a long-running cancel action because you're likely to get some process manager upset enough to kill -9 your nice cleanup
Daniel Spiewak
@djspiewak
yeah the wording is dated. in fact, in ce3 cancel is constrained by law to await finalizers
the reason for this is backpressure
if you really really want to have non-blocking cancelation, you can do f.cancel.start.void and it won't await the finalizers anymore :-P
Gavin Bisesi
@Daenyth
@bkirwi A PR updating the wording would be very very welcome! Dated prose about api behaviors is the hardest part of the docs to keep right
Ben Kirwin
@bkirwi
ah, wonderful! and even ce2 has that behaviour for IO as well? just wasn't constrained by the laws before?
Gavin Bisesi
@Daenyth
Not sure. Daniel could say better than me, likely
I think so
Ben Kirwin
@bkirwi
(and yep, definitely happy to send a pr when I'm clear on the behaviour!)
Raas Ahsan
@RaasAhsan
CE2 IO fiber.cancel will backpressure on finalizers yeah
Adam Rosien
@arosien