Bacon zipAsArray does not appear to conform to contract
cefn opened this issue · comments
I have encountered a behaviour as demonstrated by the gist at https://gist.github.com/anonymous/b053aa54750db5c5fd01 which uses fromArray(arr) zipped with repeatedly(0, arr) and causes the Mocha test to hang on the promise of zipped stream completion for more than 2000ms and therefore fail.
The behaviour seems contrary to the bacon documentation which claims "A zipped stream will publish only when it has a value from each stream and will only produce values up to when any single stream ends." The fromArray stream ends, but because the repeatedly stream remains alive, the zipped stream somehow does not end.
Surely zipped streams can't be intended to hang forever even though they will never produce any future values and they should in fact end as soon as any of their contributing streams ends.
It would be useful to know how to workaround this e.g. by asserting a number of events before the promise is fulfilled. Is this a behaviour which can be achieved within the Bacon API somehow without me wrangling my own stream-handling logic?
Holy shit! There's been a bug in zip and when for a looong time without anyone noticing it. This caused zip not to end when one of its sources has ended. I suspect people are not really using zip too much. Personally I've still never used it :)
That's fixed now, in release 0.7.70.
Hey thanks for this fix.
As for nobody using zip, I imagine it's only bloody-minded people like me that assume it's the library at fault when they hit this kind of bug :)
I've found zip pretty handy for Test-Driven Development - means you can put together an array indicating the series of events which some stream should serve, then zip this against the eventstream with assert.deepEqual, then a toPromise back to Mocha to assert that the values actually match as expected. The gotcha is that you need to add a toValues() listener else the zip function isn't called except for the last (Promised) event.
I was starting to edge towards Kefir as a result of this and a few other things I'd run into, and wondering how live it was as a project but I'll revisit Bacon again, now, especially given your responsiveness. Only refactored one file so far so not too hard to reverse.
By way of answering my own embedded question, take() creates a new stream which will stop itself after hitting a specific count of items (unless the stream itself stops sooner).