Usually it’s my Monday train trip that is full of terrors. Or was that torrents. I get confused.

moaning

morning

@korny: i have confirmed that thameslink is full of terrors, independent of the time of day

Has anyone ever had to debounce updates to an Atom? (ie. I will get several updates in quick succession, but only want to take some action 1.5 seconds (or so) after the first one arrived).

I was thinking about starting a timer (maybe at-at) when not already started… and doing it that way

once timer expires take action

just wondering if people have done something like this already

what do you do with the bounced updates?

I want to keep track of how many passenger have joined a bus...

but each passenger added to the bus is an individual MQTT message

presses on a button

but if two people get on the bus, and the second guy gets de-bounced. You only record one person?

then at some point, everybody gets off, and your bus has -1 occupants.

aah… not debouncing in that way...

coalescing perhaps

or maybe collapsing is a sufficient term

aggregate?

I’ll get three message, one for each passenger.. and I only want to take action after the third...

so yes. debouncing is the wrong term here.

collapsing sounds much better indeed

@thomas: I'd just put them on a channel/queue/buffer and process the buffer every so often.

@xlevus I like that idea…

I’ll give that a try.

On your first write, you could spawn a 'singleton' worker, that sleeps for X seconds and then gets to work.

but in other systems I've found the singleton ends up shitting the bed and locking the system up, and a periodic check is more reliable.

you could implement your own buffer which knew how to combine messages

not sure about timing though

The timing would be arbitrary anyway… I reckon somewhere between 1 and 2 seconds would be good.

but need testing of course 😉

alternatively, just do all the write to your atom as much as you like, but prevent the changed trigger from firing too frequently (the only reason I can think of you wanting to do this)

I was thinking about writing to the atom regardless (already do that), but then after a small delay do something with it

probably easier. managing buffers is a pain.

I guess the downside of using a buffer is that I would check the buffer at a set interval. even though most of the time there isn’t any traffic on it

(only 1.5 hours each day)

the way requestAnimationFrame works in browsers is a decent model

something like: (defn [evt] (if timer (append timer evt) (new-timer evt)))

that is more or less what I was thinking about.

Just looking at the https://github.com/overtone/at-at docs

@thomas: have you had a look at this: https://stackoverflow.com/questions/35663415/throttle-functions-with-core-async

david nolen’s blog has a debounce function using core.async - https://github.com/swannodette/swannodette.github.com/blob/e8a26994fcf4e2bdf0cca67e165f5e1706fc192b/code/blog/src/blog/utils/reactive.cljs#L279

thanks @rohit that looks very useful at well

@thomas: if you are using react, you could also try using the timer-mixin: https://github.com/reactjs/react-timer-mixin

i’ve got a demo here: https://github.com/ducky427/reagent-timer-demo

Anyone here used http://hackerrank.com before?