@iravid can you please assist me with the tests? Thank you.

I'm curious how bufferFastProducerSlowConsumer works exactly and how it doesn't lead to a race condition.

Editing that seems to hang on my machine.

private def bufferFastProducerSlowConsumer =
  unsafeRun(
    for {
      ref   <- Ref.make(List[Int]())
      latch <- Promise.make[Nothing, Unit]
      s     = Stream.range(1, 9).tap(i => ref.update(i :: _) *> latch.succeed(()).when(i == 8)).buffer(4)
      l <- s.process.use { as =>
            for {
              _ <- as
              _ <- latch.await
              l <- ref.get
            } yield l
          }
    } yield l.reverse must_=== (1 to 8).toList
  )

...when(i == 4)).buffer(2) must be hitting some special case, tap is evaluated before the value 4 is accepted into the buffer (because 1 is dequeued, 2 and 3 are in the queue and 4 is waiting).

Obviously in the above example 8 is not close enough to be evaluated, so it hangs.

Anyways, I don't think the test is very good in the first place.

Update:
I looked at the git history prior to the process change and it seems to me that this test has undergone a major change.

@vasilmkd Hey, nice work on this! The test works exactly as you described it. Happy to accept improvements if you have any suggestions :-)

I'm curious why the test was changed.

I think I changed it a while back because it wasn't very accurate before.

To be honest I have no idea how to test the other buffer implementations.

For the unbounded case, I think your tests are fine.

For the other implementations, you need to work with a couple of latches to control the stream's progress, apply backpressure after the first element and release the backpressure once enough elements have passed. Then you consume the rest of the stream and verify that the intermediate elements have been dropped, in the sliding case, or that the last elements were dropped in the Dropping case.

@iravid I require help for the failing bufferSliding test. The implementation of bufferSliding seems fairly innocent to me and should work.
I was much more worried about bufferDropping but it seems I have done a decent enough job of implementing. I don't believe this was anticipated when this issue was opened.

Ok, looking now!

Oh yes, I definitely forgot about the fact that we're signalling Take.End and Take.Fail too.

@iravid I'm happy to leave this for after the hackathon.

I started a fresh StreamSpec2 because any additions that I made to StreamSpec resulted in UTF8 string too long compiler error, very nondescript.

As a bonus, I have reduced allocations in unTake by not going through Option.

@iravid Thanks for your help. Ready for review.

@iravid This is ready for review once again. Hopefully the code comments make sense.

I'd like to know whether we should keep toUnboundedQueue. Same in ZStreamChunk.

@vasilmkd Yes, this one looks good! There's still a slim chance for a skipped element there in signalFirst but I don't know how to solve that currently. For this type of combinator I think this is good enough though.

Could you do a rebase?

@iravid Rebased.

My pleasure. Let's just wait for CI first. I don't trust my rebasing skills yet.