Fork me on GitHub
#clojure-uk
<
2016-06-08
>
korny07:06:25

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

mccraigmccraig08:06:38

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

thomas15:06:40

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).

thomas15:06:39

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

thomas15:06:57

once timer expires take action

thomas15:06:16

just wondering if people have done something like this already

xlevus15:06:20

what do you do with the bounced updates?

thomas15:06:50

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

thomas15:06:04

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

thomas15:06:16

presses on a button

xlevus15:06:52

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

xlevus15:06:46

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

thomas15:06:33

aah… not debouncing in that way...

glenjamin15:06:40

coalescing perhaps

glenjamin15:06:54

or maybe collapsing is a sufficient term

xlevus15:06:07

aggregate?

thomas15:06:24

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

thomas15:06:31

so yes. debouncing is the wrong term here.

thomas15:06:48

collapsing sounds much better indeed

xlevus15:06:55

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

thomas15:06:37

@xlevus I like that idea…

thomas15:06:53

I’ll give that a try.

xlevus15:06:29

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

xlevus15:06:56

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.

glenjamin15:06:46

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

glenjamin15:06:57

not sure about timing though

thomas15:06:17

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

thomas15:06:26

but need testing of course 😉

xlevus15:06:08

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)

thomas15:06:12

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

xlevus15:06:43

probably easier. managing buffers is a pain.

thomas15:06:41

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

thomas15:06:57

(only 1.5 hours each day)

glenjamin15:06:38

the way requestAnimationFrame works in browsers is a decent model

glenjamin15:06:51

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

thomas15:06:47

that is more or less what I was thinking about.

thomas19:06:58

thanks @rohit that looks very useful at well

rohit19:06:05

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