Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 01 2021 10:11
    @SystemFw banned @Hudsone_gitlab
  • Jan 31 2019 04:19
    404- forked
    404-/fs2
  • Jan 31 2019 03:01
    SethTisue commented #1232
  • Jan 30 2019 17:22
  • Jan 30 2019 13:45
  • Jan 30 2019 10:48
    pchlupacek commented #1406
  • Jan 30 2019 10:47
    pchlupacek commented #1406
  • Jan 30 2019 10:39
    pchlupacek commented #1407
  • Jan 30 2019 09:58
    lJoublanc commented #870
  • Jan 30 2019 09:42
    vladimir-popov commented #1407
  • Jan 30 2019 08:10
    vladimir-popov closed #1407
  • Jan 30 2019 08:10
    vladimir-popov commented #1407
  • Jan 29 2019 19:20
    SystemFw commented #1407
  • Jan 29 2019 19:20
    SystemFw commented #1407
  • Jan 29 2019 18:57
    SystemFw commented #1406
  • Jan 29 2019 17:47
    pchlupacek commented #1406
  • Jan 29 2019 17:42
    pchlupacek commented #1406
  • Jan 29 2019 17:39
    pchlupacek commented #1407
  • Jan 29 2019 17:39
    vladimir-popov edited #1407
  • Jan 29 2019 17:38
    vladimir-popov commented #1406
Ross A. Baker
@rossabaker
It's interesting that all our integrations give the appearance of hard dependencies. The core is actually fairly light.
Christopher Davenport
@ChristopherDavenport
An argument for multi-repo.
Ross A. Baker
@rossabaker
Yeah, well, when someone has a long weekend to devote to setting up umpteen Travis configurations... :smile:
Christopher Davenport
@ChristopherDavenport
@SystemFw or others who might time to look. Put a PR up establishing an fs2 module for atto. Comments appreciated tpolecat/atto#91
Pavel Chlupacek
@pchlupacek
@rossabaker would be excellent to see how we can move forward. I don’t see any reason why fs2-io backend couldn’t perform in pair with blaze-ds. If it does not, it means we still have work to do on perfromance, and this may be perhaps the focus of fs2-http to really make sure the core perfromance does not suffer
Then I love to have one single stack for Headers/Request/Response algebra, namely if you are in thoughts of revorking them.
I think pairboiled dependency is ok if we can prove its perfromance is far better than scodec one (btw could pairboiled be used with scalajs too?)
Michael Pilquist
@mpilquist
It would be nice to have a version of concurrently that took a stream of streams -- something like s.concurrently(Stream(u1, u2, u3))
Christopher Davenport
@ChristopherDavenport
Why not just join in the concurrently block?
Michael Pilquist
@mpilquist
I think that's the best we can do with the current API
Pavel Chlupacek
@pchlupacek
perhaps just as snytax-sugar concurrently may take proe streams to run and then perfrom join behind the scenes ?
Fabio Labella
@SystemFw
I wouldn't like a syntax-sugar only version
s.concurrently(SoS.join) is not onerous syntactically
it's just that it creates a queue and all that to collect values to SoS that you then throw away
but that being said, I moved away from really caring about that
Pavel Chlupacek
@pchlupacek
ah, so we actually speaking here for alias for Stream(s1,s2,s3…).map(_.drain).join right?
Michael Pilquist
@mpilquist
yeah I noticed some code like s.concurrently(u1).concurrently(u2) which seemed inefficient to me
Christopher Davenport
@ChristopherDavenport
It feels a bit odd adding extensions like this which are easily built using the primitives
I do that occasionally to be sure. :laughing:
Fabio Labella
@SystemFw
because in my code I have a lot of cases where I join streams in module A, join streams in module B, and then (moduleA, moduleB).join, and that is not fixable without destroying modularity
Michael Pilquist
@mpilquist
I didn't really mean an alias
Pavel Chlupacek
@pchlupacek
well we could have join, that does effects only :-)
Fabio Labella
@SystemFw
@mpilquist yeah, I guess you meant a version where you don't run join at all, just compile.drain.start + concurrently machinery
I guess the generalisation of this problem is what Pavel proposes
Michael Pilquist
@mpilquist
And Stream(s, u1.drain, u2.drain).parJoinUnbounded is bad b/c of different shutdown semantics
Fabio Labella
@SystemFw
a Stream[F, Stream[F, A]] => Stream[F, Unit]]
that mean you do nested join without allocating all the queues
Michael Pilquist
@mpilquist
right
Fabio Labella
@SystemFw
but you still have to allocate the deferreds and so on
Pavel Chlupacek
@pchlupacek
yeah. Lets open issue, i this it is worth of investigating ...
Fabio Labella
@SystemFw
this isn't fixable completely without destroying modularity
Pavel Chlupacek
@pchlupacek
@SystemFw I am not 100% sure on that. if bracketCase and cancel works now as expected, I think we may have few winnings there - a) we may not need interrupt anymore, (so no race at every eval) and b) we may just simple cancel running streams
Fabio Labella
@SystemFw
ah ok, that doesn't fix the general problem
but it reduces the amount of things you need to allocate in the first place
Pavel Chlupacek
@pchlupacek
yeah, but allows to run streams much more effectivelly as you can specialize it here
Fabio Labella
@SystemFw
yeah, it improves the perf of individual stream combinators, I agree with that :)
Pavel Chlupacek
@pchlupacek
Also, this makes ever Stream.eval(…) much more effective
I experimented with this in like M3, but it didn’t work, partly in bugs in cats effects I think. But now I am quite confident this shall work.
Fabio Labella
@SystemFw

I'm just saying that you can't solve this:

def a = Stream(streamA1.drain, streamA2.drain).join
def b = Stream(streamB1.drain, streamB2.drain).join
def c = Stream(a.drain, b.drain).join

you can reduce the initial cost of join, but you can't make the above be the same as

def c = Stream(streamA1.drain, streamA2.drain, streamB1.drain, streamB2.drain).join

unless you make join cost 0 (allocate no new primitives per join)

I do agree that a joinDrain or something can be useful to reduce the cost of a single join in the first place, given the very common use case of just concurrently running things for their effect
unless we start doing magic things like introducing concurrency in the Stream algebra tree, with on-the-fly rewriting and stuff like that
but basically 1) modularity in the code, 2) modularity in the interpreter, or 3) extra allocation of machinery seem mutually exclusive
our current situation gives us 1) and 2) without 3) -- first code snippet
or 2) and 3) without 1) -- second code snippet
Pavel Chlupacek
@pchlupacek
@SystemFw In fact, I think we may perhaps, solve even this nested situation. That would, hoverer require addition to algebra and more experimenting :-)
Fabio Labella
@SystemFw
yeah, that would be 1) and 3) without 2)
the interpreter needs to know about concurrency
:P
Pavel Chlupacek
@pchlupacek
yup
Fabio Labella
@SystemFw
I'm a bit scared of going that direction unless we can make it very general