@sideeffffect what do you think of mixing the platform-specific trait directly into ZStream and using implicit evidence instead of implicit classes?

Oh actually someone pointed out in another PR that ScalaJS has InputStream. So we can move this code directly into ZStream.

Should we read more than a single byte on every read call?

close on the InputStream looks to me like a noop

there is toInputStream for all ZStream, StreamEffect, ZStreamChunk and StreamEffectChunk, as proper (non-extension) methods

Ok, needs a quick rebase and we're good

@iravid so are we sure that the overhead of Chunk is low enough that we don't need also toInputStream from Stream[_, Array[Byte]]?

@sideeffffect Chunk definitely has some overhead, but I believe that's offset by the utility of combinators available on ZStreamChunk. We're also designing the rest of the library to always return chunks, rather than arrays, when applicable - e.g. ZStream.fromInputStream.

my builds are now failing with

[warn] Thread[scala-execution-context-global-672,5,zio-timer] loading zio/RTSSpec.class after test or run has completed. This is a likely resource leak.

java.lang.OutOfMemoryError: GC overhead limit exceeded

and

[warn] Thread[ForkJoinPool-1-worker-1,5,zio-default-blocking] loading zio.RTSSpec$$anonfun$testTimeoutOfLongComputation$1$$anonfun$apply$10$$anonfun$apply$mcZ$sp$2$$anonfun$apply$321$$anonfun$apply$11 after test or run has completed. This is a likely resource leak.
java.lang.OutOfMemoryError: GC overhead limit exceeded
	at scala.collection.mutable.ListBuffer.$plus$eq(ListBuffer.scala:174)
	at scala.collection.mutable.ListBuffer.$plus$eq(ListBuffer.scala:45)
...

I don't know how my changes could introduce such a problem... :-/ does it happen also in master?

@iravid ready to merge