This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-03
Channels
- # announcements (1)
- # babashka (22)
- # beginners (176)
- # calva (10)
- # cider (4)
- # circleci (5)
- # cljsrn (20)
- # clojure (28)
- # clojure-europe (11)
- # clojure-italy (5)
- # clojure-nl (5)
- # clojure-spec (1)
- # clojure-sweden (2)
- # clojure-uk (29)
- # clojuredesign-podcast (4)
- # clojurescript (38)
- # code-reviews (25)
- # conjure (1)
- # core-typed (1)
- # data-science (16)
- # datomic (23)
- # figwheel-main (16)
- # fulcro (48)
- # helix (9)
- # jobs (3)
- # juxt (5)
- # kaocha (17)
- # malli (19)
- # mount (9)
- # nrepl (4)
- # off-topic (35)
- # pathom (7)
- # re-frame (28)
- # reagent (26)
- # reitit (1)
- # releases (1)
- # remote-jobs (5)
- # sci (6)
- # shadow-cljs (36)
- # spacemacs (3)
- # sql (8)
- # tools-deps (13)
- # unrepl (1)
- # vim (4)
- # xtdb (8)
given two vectors of maps; [{:id 1 ….} …]
what’s a good way to join the maps on id
?
currently I’m reducing both into a new map using id
as key
user=> (require '[clojure.set :as set])
nil
user=> (set/join #{{:id 1 :name "vlaaad"}} #{{:id 1 :age 29}} {:id :id})
#{{:id 1, :name "vlaaad", :age 29}}
@peder.refsnes ^great! thanks.. in hindsight I probably should have search the docs for join
🙂
Hi, let's say I have a map {:foo :bar :baz {:buz :biz}}
and want to destructure that l know that this works: {{:keys [buz]} :baz}
But what if I want to destructure different levels at the same time. So I need the :foo from the first and the :buz from the second level. Is that possible?
also, you are allowed to use let to do separate destructure calls, which is usually more readable and clear, and doesn't have an extra performance cost
Yea, I usually do that, but I wanted to experiment a bit as I never used nested destructuring before.
Does anyone know of a library that allows you to express regexes that operate over clojure data structures? I’m basically looking for spec’s regex ops, but in a format that allows for lightweight anonymous expressions, e.g. ephemeral matchers that aren’t placed in a registry. My usecase is expressing something like the following:
(t/is (dr/match (dr/data-regex-of-some-kind :a dr/* :b) [:a :a :a :b]))
Have you looked at meander? https://github.com/noprompt/meander
oh, interesting - I hadn’t considered meander for this case. I’ve been looking for an excuse to play around with it for a little while now, too.
Hi all, what ways do clojure devs deal with async streaming? I'm coming from Kotlin mostly where coroutines/flows are used but I've also played around with Scala where Monix and fs2 compete for this use case. I watched a conference talk where the speaker seemed to imply its common to provide a callback style api to the user and then use core.async's channels behind the scenes, is that a good route to take?
a huge gotcha is that you should not do IO or CPU intensive work inside core.async go blocks
core.async is a coordinator, and go blocks are not designed appropriately for execution
Okay thanks, how do you manage that when using core.async? I'm used to libraries where you specify which thread pool you run a specific task on (io-bound, cpu-bound, etc).
in some cases you just want to hold onto the channel that thread returns and use it elsewhere of course - but that's the 95% idiom for sure
You may want to specify a dedicated thread poll for this blocking ops to avoid spawning thousands of threads
that's something core.async go
blocks are actually good at, you can use them to implement backpressure, which regulatest the number of threads in flight
Thread-limiting at the i/o layer is usually about in-memory bulkheads. (You can’t reliably abandon a call on a thread you don’t own.) That’s good, but you usually want to consolidate that in a single object. It’s generally better to backpressure processes at higher layers if feasible.
Note sure what you meant by "in-memory" bulkheads but threadpools are bulkheads. And when you interrupt a thread which is blocked on IO it will throw an InterruptedException (which misbehaving thread may ignore but otherwise it should be a good mechanism).
I agree that backpressure at higher levels is a good thing but also think that a separate thread pool is preferrable to the potentially unbounded thread creation via a/thread
what I'm advocating for is using core.async structure to provide backpressure, rather than doing it via the size of a thread pool. It's the kind of thing core.async is actually good at (eg. you can start N go-loops, reading from one channel, in order to limit parallelism of the work derived from that channel to N)
And I’m reiterating exactly what @U051SS2EU is saying 😉