This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-20
Channels
- # announcements (2)
- # architecture (5)
- # beginners (118)
- # cider (5)
- # clara (13)
- # cljdoc (8)
- # cljs-dev (49)
- # cljsjs (2)
- # clojure (107)
- # clojure-dev (9)
- # clojure-europe (3)
- # clojure-italy (58)
- # clojure-japan (2)
- # clojure-nl (6)
- # clojure-spec (89)
- # clojure-uk (27)
- # clojurescript (9)
- # core-async (33)
- # cursive (2)
- # datascript (2)
- # datomic (31)
- # duct (4)
- # emacs (1)
- # events (1)
- # figwheel-main (1)
- # fulcro (69)
- # hoplon (7)
- # hyperfiddle (16)
- # incanter (4)
- # instaparse (4)
- # kaocha (1)
- # mount (2)
- # nrepl (19)
- # off-topic (40)
- # onyx (6)
- # other-languages (3)
- # pedestal (2)
- # re-frame (48)
- # reagent (2)
- # reitit (10)
- # ring-swagger (9)
- # shadow-cljs (63)
- # spacemacs (13)
- # sql (8)
@hiredman thanks!
How can I create a channel in such a way that it combines multiple other channels and changes when a message is passed to only one of those channels (keeping the most recent value for the others)?
@ghopper that reminds me of dataflow systems where there's a "hot" input and multiple "cold" inputs
Right, I could use alt!
/ alts!
in a go-loop
and manually keep track of the most recent. I was just curious if core.async
has this functionality already in a simpler way.
@noisesmith, yeah, I guess what I'm looking for is something along those lines. Have you seen this implemented with core.async
before?
Should I just be using atoms with watchers instead?
@ghopper I could see using a go-loop where you call alts! on each loop, and call some f with all the values when the "hot" channel gets a value
and use the loop bindings to preserve the most recent values seen from each channel
I suppose I could create some sort of macro to make creating this cleaner.
I dunno what you should be doing, but the words you are using when you talk about channels kind of lead me to believe you don't have a good mental model for them
I think that's the best bet at the moment.
throwing macros on top of a bad mental model for channels is not likely to result in something good
Well, I do think I'm perhaps using them in the wrong way. I do understand what they are/do though. I'm looking to have a single final value that's the result of multiple input channels. Whenever any of the inputs update, it should flow through to the output.
Heh, no, it probably wouldn't. ๐
"Whenever any of the inputs update, it should flow through to the output." seems to contradict "How can I create a channel in such a way that it combines multiple other channels and changes when a message is passed to only one of those channels (keeping the most recent value for the others)?"
it sounds like you are trying to do some kind of functional reactive programming thing
right - the first description sounded like the hot input / cold input model from dataflow (capturing changes in cold inputs, firing some function with the most recent value for all the inputs hot and cold for a hot one), but the new description is much simpler to implement
Yeah, I wouldn't make any distinction between the inputs. If any of them updates, that should be passed on and 'trigger' updates of things that depend on it.
Thinking about it more, I'd use a single hash-map with a key updated per channel in a go loop.
@hiredman, what would you use?
Ok, I may look into doing that. I may just need to try it both ways to see what the benefits are.
so you have a data structure like {:a {:deps [:b :c] :f ...}}
would would be read as value :a
is the result of applying function :f
to the values of :b
and :c
and you do a topo sort on the graph and traverse it building up values for each thing
Makes sense :thumbsup::skin-tone-2:
you could construct a graph of channels with go loops consuming from the channels to compute a value and emit it, but like, why? maybe if you want concurrency that makes sense (each f as like a little actor ), but you are likely better off building a single threaded graph traversal thing, and debugging your ideas, before trying to get it to run concurrently
Yeah, I think you're right. I'm not getting much benefit out of the route I'm going, and it can be done much simpler.