Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-12-14

Channels

#missionary
<
2021-12-14
>
martinklepsch12:12:55

random q: given a flow, how do I take values in a throttled way? (i.e. take value, ignore all values for 500ms, wait for next value)

refset12:12:03

there's an example for debounce which is conceptually similar enough that it might be helpful to you https://github.com/leonoel/missionary/blob/8c34d5e11e11960f905cddec88fb49cd9b2ecfa0/src/missionary/core.cljc#L193-L211 (but I've never used missionary so perhaps it's not helpful at all) I found this explanation helpful when I was thinking about throttling & debouncing a few months back https://css-tricks.com/debouncing-throttling-explained-examples/

👍 1
Dustin Getz15:12:18

you can sample a continuous flow once every 500 ms (pulling a lazy value through every 500 ms based on a clock stream), is that what you want? https://cljdoc.org/d/missionary/missionary/b.24/api/missionary.core#sample

Dustin Getz15:12:41

events are eager/push, signals are lazy sampled, so i think here the idea of throttling implies signal

Dustin Getz16:12:37

Note that event streams are backpressured so they are self-throttling, which is different than controlling the throttling with a userland clock

martinklepsch09:12:40

@U09K620SG thanks for that explanation, you’re making some interesting distinctions with terminology that made me understand the problem better!

martinklepsch09:12:50

@leonoel that page is awesome, thank you very much!

martinklepsch09:12:52

(If you eventually want to incorporate those docs into cljdoc you might need to put them into the repo)

leonoel09:12:09

@U050TNB9F is there a way to import a separate doc repo in cljdoc ? The wiki has different write permissions and I'd like to keep it as the single source of truth

martinklepsch09:12:27

There isn’t currently. You might be able to get it to work with embedding the wiki as a submodule but I haven’t really played around with that. Overall I like the fact that putting documentation inside the repo 1. recognizes contributors to documentation more 2. is versioned alongside the code But I agree, the contribution process to a wiki is a bit more straightforward.

martinklepsch12:12:47

searching the API docs for “throttle” didn’t yield anything

Dustin Getz15:12:18

you can sample a continuous flow once every 500 ms (pulling a lazy value through every 500 ms based on a clock stream), is that what you want? https://cljdoc.org/d/missionary/missionary/b.24/api/missionary.core#sample

Dustin Getz15:12:41

events are eager/push, signals are lazy sampled, so i think here the idea of throttling implies signal

Dustin Getz16:12:37

Note that event streams are backpressured so they are self-throttling, which is different than controlling the throttling with a userland clock

Ben Sless16:12:00

Something Leo said in his talk which I'm not sure made sense to me is that returning thunks that will do IO is function all and pure. Is that correct? They still hide potential side effects, effects aren't reified in a fully pure manner

Dustin Getz16:12:50

it's true - it means invokinng that thunk is unsafePerformIO

Dustin Getz16:12:03

IO actions can be reified in several ways – thunks, symbolically using lisp quoting `(http! ~request) - both these things encode an effect as a value

Ben Sless16:12:39

I think where I'm iffy in thunks is that their resolution is at allocation time and not run time

Ben Sless16:12:37

Which means they're less testable. Unless you provide on top of that an effect handling system

Dustin Getz16:12:48

testability meaning equality on IO Action instances? #() == #()

Ben Sless16:12:27

You know what, maybe I'm approaching this wrong. How should I go about testing code and systems written with missionary?

Ben Sless16:12:18

I should ask about the result I want and not the way I think I need to take to get there. It may be the wrong way

Dustin Getz16:12:43

Testing is why ZIO bundles dependency injection, right?

Ben Sless16:12:13

Never used it

Ben Sless16:12:10

DI defers the problem to instantiation time, which is still not run time

ribelo23:12:16

@leonoel if you feel like it, you can also show how to implement dropping/sliding buffer

leonoel20:12:30

this is equivalent to core.async 's dropping buffer : 

(defn dropping-buffer [cap >in]
    (->> >in
      (m/relieve (fn [x _] x))
      (m/buffer cap)))

leonoel20:12:23

sliding buffer makes no sense to me, it looks like a failed attempt to emulate continuous time on top of channels. Could you describe a problem that would be solved by a sliding buffer ?

ribelo21:12:06

I don't really have a problem, it's just stuff I haven't been able to implement

ribelo21:12:19

I couldn't figure it out