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
TomasStanek
@TomasStanek
@alexandru I've tried compiling against branch pr/305 (commit: bbb15854098d5eb3887a10702de5fe41fb886911) and the leak is still there (there are java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask stacking up and java.util.concurrent.RunnableScheduledFuture[] array keeps growing).
The issue with queue.peek1 deadlock also persisted.
I'll open a proper issue hopefully tomorrow evening
Luciano
@lJoublanc
I'm looking at Resource and struggling to understand why it's there; it appears superfluous to Bracket, as Resource.use requires an implicit Bracket. Is this just so that if your clean-up code is unwieldy, you can avoid writing F.bracket(<my huge initialization/finalization code>)?
Fabio Labella
@SystemFw
@lJoublanc are you aware of the difference between a streaming bracket (like fs2.bracket), and a IO bracket, like F.bracket?
Luciano
@lJoublanc
no. I assumed that the fs2 was just wrapping this op.
Fabio Labella
@SystemFw
nope
forget about Resource for a second
look at this code
for now I'll be talking about fs2 0.10, we changed the signature to make things clearer in 1.0, which will hopefully be clear soon
Luciano
@lJoublanc
ok, been using 1.0-M3
I did notice that you changed e.g. io.Socket into a Resource. I guess that' swhere this is going ... but go on.
Fabio Labella
@SystemFw
Stream.bracket(openFile)(file => Stream.emit(file), file => file.close).flatMap(readFromFile)
F.bracket(openFile)( file => IO.pure(file), file => file.close).flatMap(readFromFile)
how do you think each will behave?
Luciano
@lJoublanc
Ok ... this is the path I was going down that made me ask this question.
The second bit of code looks dodgy, because of the pure.
Fabio Labella
@SystemFw
yeah
with the Stream version, you can just emit the resource, and it will all be fine (emit is also pure)
with the F version, by the time you flatMap the file is closed, and readFromFile fails
if you want to understand this inconsistency, this is the mental model
bracket closes a resource as soon as the F finishes emitting elements
now, IO can emit one element at most
so when you do pure, you emit, so you have finished emitting, so the resource gets closed
when you do emit on Stream, the stream has not finished emitting, because a Stream, unlike IO, can emit multiple elements, and therefore the thing is still fine
Luciano
@lJoublanc
:rage1:
This explains a problem I've been having for a few weeks...
Fabio Labella
@SystemFw
does that make sense, this first part?
Luciano
@lJoublanc
Right so the Stream version only releases the resource when there is a 'complete' for lack of a better expression.
Whereas the F version releases as soon as the first (and only) element is emitted.
Fabio Labella
@SystemFw

when there is a 'complete' for lack of a better expression.

When the stream finishes emitting, yeah

so when you do stream1 ++ stream2
it will release things at the end of stream1
you got the F version right
now
Luciano
@lJoublanc
hold on
Fabio Labella
@SystemFw
yep
Luciano
@lJoublanc
What if you do say Stream(1).flatMap( one => Stream(one) ++ Stream.sleep(3 seconds))
(I'm assuming that the flatMap prevents it from releasing the resources at the end of the first stream, right?)
My point here is that the sleep (or delay or whatever) doesn't produce any values, it is only evaluated for effects.
Fabio Labella
@SystemFw
yes, in that case the lifetime is Stream(1)
Luciano
@lJoublanc
Sorry - so the question is, in the example I gave, when would a resource be relesed?
Fabio Labella
@SystemFw
well, your example doesn't allocate any resources :laughing:
Luciano
@lJoublanc
got you ... right right ok - just wanted to check I was following.
Fabio Labella
@SystemFw
right, now notice how the F version is less composable
Luciano
@lJoublanc
yes
Fabio Labella
@SystemFw
because you need to bake all the use resource logic in use
whereas with Stream you can just emit
so, the first point of Resource is to allow you writing more composable code
because in the Resource monad you can just emit
and then when you "run" the Resource
if you run it with Stream it will just flatMap, since Stream can do that
if you run it with F, it will build the right use for you, and put it in bracket