Sliding / dropping buffer

[simonpure]

Thanks for this awesome library. Personally, I've found it to be the most friendly csp implementation for JS and enjoy using it.

Is it already possible to have a channel with a sliding or dropping buffer? If not, any plans to add it?

I haven't seen anything mentioned in the docs and didn't dig too deep into the source code yet, so apologies if this is already mentioned somewhere.

Thanks!

[dvlsg]

Thanks!

It's certainly on the wishlist. I had a partial implementation at one point during early development and opted to drop it because it was adding unnecessary complexity during the development cycle, but I definitely kept it in the back of my mind while developing the core functionality of the library.

Now that the spec has started to settle and a lot of the internal complexity is hammered out, it may be a good time to revisit these sometime soon. Or, as always, pull requests are welcome if anyone else would like to take a swing at it.

So the tl;dr is -- not yet, hopefully some day soon!

[simonpure]

Awesome, thanks for the quick response! Depending how urgently I need it,
I'll take a crack at it.
On Apr 10, 2016 9:54 AM, "dvlsg" notifications@github.com wrote:

Thanks!

It's certainly on the wishlist. I had a partial implementation at one
point during early development and opted to drop it because it was adding
unnecessary complexity during the development cycle, but I definitely kept
it in the back of my mind while developing the core functionality of the
library.

Now that the spec has started to settle and a lot of the internal
complexity is hammered out, it may be a good time to revisit these sometime
soon. Or, as always, pull requests are welcome if anyone else would like to
take a swing at it.

So the tl;dr is -- not yet, hopefully some day soon!

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#16 (comment)

[dvlsg]

Of course! If you beat me to it, take a look at the data structures. I tried to intentionally abstract away all of the required data interface methods (full(), put(), etc) so it would be easier to integrate with additional data types. There is definitely some dead code / unused classes in there (still on my todo list for cleanup), though. Just a heads up.

I'm sure there's still something else that will need to be refactored, though, once we really dig into it.

[dvlsg]

Alright, turns out this isn't too bad (for the most part). I have a DroppingBuffer complete locally.
SlidingBuffer is more or less complete. Getting a SlidingBuffer to work with the unbounded unshift (for the multiple-value-transforms) is fairly complicated, though.

Here's a quick rundown of the issue. Assume we have the following:

let buffer = new SlidingBuffer(3); // size of 3
let transformer = (x, push) => {
    push(x);
    push(x + 1);
    push(x + 2);
};
ch.put(1);
ch.put(4);
ch.put(7);
// current state => Channel(1, 4, 7)
await ch.take(); // => 1
// should Channel hold (2, 3, 4, 7)?
// or should it hold (2, 3, 7)?
// what happens if we ch.put(10) here?
// should it end up outputting (2, 3, 4, 7, 10)?
// or should it output (3, 4, 7, 10)?
// or maybe even (4, 7, 10)?

[dvlsg]

I have committed an implementation of DroppingBuffer and SlidingBuffer to the development branch. DroppingBuffer should be fully functional (pending some additional tests), but SlidingBuffer won't work with multi-return-value transforms until we figure out / decide how they should actually function (if at all).