There are tests for this for all the FromChunkerator adapters, but no tests yet for the ToChunkerator adapters.

Current implementation limitations:

• requires a Bimonad instead of just a Monad. I'm not sure if this is negotiable or not. It seems like we need to call F.extract on the iteratee to get it to "run".
• Uses promises for communication between producer and consumer. Maybe this is okay for, say, and Play converter. But there has to be a more catsy way to do this. Right now, my cat-fu is not strong enough to pull it off. Maybe in the future, I will figure it out. But if you are good with this kind of thing and want to take a stab at it, that would be great.
• Steals a Future from the global execution context to kick off the producer asynchronously. A more catsy approach, as described in the last bullet point, should do away with this. I didn't want to add an implicit ExecutionContext argument here, as that seems like an implementation detail, and a rewrite of this method without it would not be backwards compatible. Maybe there is some way to pull this off with Task? I tried, couldn't figure it out

Current implementation limitations:

• Task effect is hardcoded. We should be able to adapt regardless of the effect type (so long as it's monadic).
• Uses promises for communication between producer and consumer. Maybe this is okay for, say, and Play converter. But there has to be a more catsy way to do this. Right now, my cat-fu is not strong enough to pull it off. Maybe in the future, I will figure it out. But if you are good with this kind of thing and want to take a stab at it, that would be great.
• Steals a Future from the global execution context to kick off the producer asynchronously. A more catsy approach, as described in the last bullet point, should do away with this. I didn't want to add an implicit ExecutionContext argument here, as that seems like an implementation detail, and a rewrite of this method without it would not be backwards compatible. Maybe there is some way to pull this off with Task? I tried, couldn't figure it out

We might get better performance using chunking here. Shouldn't be too hard to implement if you don't mind putting in, say, a private var currentChunk: Seq[A] between def apply and def applyInternal.

I've seen a few of these errors come back really hammy. We should be able to provide custom error messages for implicit resolution problems that make more sense. I don't have any examples at the moment, but if I see any, I will comment on it here. (Please do the same, okay?)

Once again, two adapters, from and into Chunkerator, would give use adapters between Monix and all the other streaming libraries.

We should be able to implement this regardless of the effect type.

Right now, I only target the most recent versions of all the various streaming libraries. It would be nice to support a range of versions, from the most recent, down to the latest version that is compatible with the most recent. This would involve a test suite that would test across all these library versions. Some SBT-fu required.

This would really be great to have, but a little too much effort for me at the moment.

Two adapters, from and into Chunkerator, would give us reactive streams adapters for all the streaming libraries.

Note that when we do this, we should probably special-case streaming libraries that already have reactive streams adapters, such as Akka and Play. At this point, we will need to make sure the implicit resolution picks up the direct adaptation, and not the one from chain that uses Chunkerator in the middle.

How do I change timeout programmatically ? It's hardcoded to 5 seconds for some reason.

And what's the meaning of this timeout ? Is it time within which I should materialize and complete consumption of resulting akka Source ? What if I process it for hours ?

I haven't thought too hard about this. Either it's a silly idea or it's a good one and a lot of work.

Once again, two adapters, from and into Chunkerator, would give use adapters between RxJava and all the other streaming libraries.

All three of the type arguments to adapt should be inferrable by the compiler. The first and the third argument are inferrable from the argument, fs2Stream, and the second argument should be inferrable from the left-hand side. But I haven't figured out how to get the compiler to infer any of them yet. Can you help? It's not as simple as you might think, because the implicit resolution has to navigate between types with two type parameters, such as Enumerator[Eval,Int], and types with a single type parameter, such as streamadapter.iterateeio.EvalEnumerator[Int].

The current implementation of this method is a little lame, using promises to communicate between the producer and the consumer. There's got to be a better approach. I'd like this method to work without any dependencies besides Play and Scala standard library, so that's a limiting factor.