Could someone explain this result? I thought that the value of an atom is always fully realized (not lazy), so I would expect the pr-str to take much less time.

=> (let [a (atom (take 10 (repeatedly #(Thread/sleep 1000))))]
    (time (pr-str @a)))
"Elapsed time: 10043.797237 msecs"

You're deref'ing the atom to get its value -- which is a lazy seq -- and then you're printing it to a string which is realizing the value.

So the 10 seconds is the time it takes pr-str to realize the take 10 -- the deref @a would have been near-instantaneous.

user=> (let [a (atom (take 10 (repeatedly #(Thread/sleep 1000))))]
         (time @a))
"Elapsed time: 0.007343 msecs"

An atom can contain anything -- it's just a container, and it doesn't "do" anything to its contents.

^ @wei does that help?

well, it should only contain immutable values since the swap! function can be applied more than once in the case of concurrent updates

@seancorfield I see, so if I want the value to be realized before any derefs, I'd need to do that explicitly, like wrap the computation with doall. thanks for the insight

Yes, the same applies to laziness vs eagerness anywhere in Clojure really.

I’m thinking of writing a boot task for replacing shortcodes in a markdown file using user-defined functions that return hiccup. Based on other libs I think there should be a defshortcode macro for defining them. How are those handled in other libs? Does it update an atom with a map of properties and a function body?

I think data wise it’s important to know the defined shortcodes up front

is there any way to run some simple fns inside a clojure jar on android with a much faster startup speed?

how are people dealing with communication between components in stuartsierra/component?

started trying out spec after having used schema and core.typed. one thing I noticed, compared to core.typed, spec’ing records is kind of laborious and overly verbose. is this something spec proper would ever address (even if just a macro) or should every one fend for themselves and write their own macros? I suppose there’s a third option which is the core team wants to discourage the use of records and/or their use with spec?

kind of a latent question

you can spec them as maps with s/keys and :req-un

there are some ideas we have in spec 2 that might apply better but TBD

yep, I have, and it’s gross. =P we wrote a macro to fix that, but curious if the need to write such a macro indicates we’re using Clojure in a way not intended by the core team

(or if it’s just because spec is alpha)

nah, just have never resolved what to do about records

spec is centered around the idea of semantics associated with (qualified) attributes

records sit in a weird place with that as the attributes are unqualified but records types themselves are qualified

we’ve kicked around a bunch of ideas but never got something we liked

yeah, exactly part of the pain I was feeling with registering specs for record fields

ok, thanks for the info. wanted to make sure I wasn’t missing anything about the design or philosophy of spec

nope, just some unfinished business

Hi guys, I am in doubt about what is the better way to solve the following problem. Scenario: Base: {:response [{:users [{:id 1} {:id 2}]} {:users [{:id 3} {:id 4}]}]} Path to: [:response :users] Replace with: [[{:id 1, :name "Rafa"} {:id 2, :name "Ana"}] [{:id 3, :name "Jonas"} {:id 2, :name "Leo"}]] Expected: [{:users [{:id 1, :name "Rafa"} {:id 2, :name "Ana"}]} {:users [{:id 3, :name "Jonas"} {:id 2, :name "Leo"}]}] I am thinking about recursion but I would like to know if there is a better way (using something like clojure.walk). Any thoughts?

@lucelios It looks like you want to join on the :id attribute. See https://clojuredocs.org/clojure.set/join

The changelogs of Clojure only go back to 1.3. I want to know if I remember this correctly: binding was allowed to rebind any var instead of only dynamic vars in the early versions of Clojure. Later on you could only do that with dynamic vars. with-redefs was introduced for rebinding the root values of vars e.g. for testing. Was that related to the change to binding?

https://github.com/clojure/clojure/commit/178d8c42609d899208e745b76b89297c4287c078

https://dev.clojure.org/jira/browse/CLJ-665

http://clojure-log.n01se.net/date/2010-10-29.html#09:11

by which I’d say, yes

cool

is there a nice idiomatic way to take a vector of maps [{:a 1 :b 2} {:c 3 :d 4}] and turn it into a map based off some key in the vec’s map? {1 {:a 1 :b 2} 3 {:c 3 :d 4} ...?

obviously a reduce would work, but it feels icky

(reduce #(assoc %1 (:the-key %2) %2) {} the-vec)

(now i see that the above is confusing, assume each map entry in the vector has the same keys)

(into {} (map (juxt :a identity)) coll)

group-by

! group-by is exactly it, thanks @hiredman

well, it seems you assume that the vector of maps has a unique value for the same key in each map?

yes, i do — which fits for this particular dataset

good heads-up thinking though

so then it’s slightly different than group-by. we have a function called index-by for that, I can look it up

(defn index-by
  "Returns a map which indexes values by the result of calling kfn
  with given value."
  ([kfn values]
   (index-by kfn values nil))
  ([kfn values flat?]
   (tzipmap (map kfn values) values flat?)))

(where tzipmap is a transient-based version of zipmap)

i think the (into {} (map (juxt :a identity)) coll) will use transients for free because of into

could be, this code probably stems from before transducers ,etc.

there's the similar clojure.set/index as well - allows multiple relations to index and multiple matches for each value of the index

egret.run=> (clojure.set/index [{:a 0 :b 1} {:a 1 :b 1}] [:a])
{{:a 0} #{{:a 0, :b 1}}, {:a 1} #{{:a 1, :b 1}}}

i love clojure.set, i use it almost everywhere

its so much easier for me to think about data as just sets and joins/unions/etc

this finds group-by as the closest built-in thing: https://re-find.it/?args=%5B%7B%3Aa%201%7D%20%7B%3Aa%202%7D%5D%20%3Aa&ret=%7B1%20%7B%3Aa%201%7D%202%20%7B%3Aa%202%7D%7D&more=true

woah. that’s a great idea for a tool…

where has this been all my life

set/index comes up first when you use [{:a 1} {:a 2}] [:a] as the args.

I’m spinning up some old projects with lein repl and getting this error:

No such var: nrepl.transport/uri-scheme

I have lein 2.8.3, clojure 1.8.0

I clearly have something out of sync somewhere

downgrade to lein 2.8.1 and try

yes | lein upgrade 2.8.1

yeah - lein changed nrepl versions with a recent release, and that could break old projects if they or their middleware relied on the way nrepl used to work

maybe you have some incompatible nrepl in your profiles.clj?

it could break all your projects if your profiles.clj pulled in a middleware for the old nrepl

Yes, I was hoping to use an older project to do some cider hacking. And it’s complaining about middleware as well. I feel a bit lost, lol.

Everything used to just work

I’m sure the new stuff is great, of course 😉

well, the CIDER maintainer also maintains nrepl, so they should at least evolve together now

ok, I have a repl… that’s good…. now let’s try cider….

Hmm. So for CIDER… can I upgrade the deps and the latest CIDER while keeping lein at 2.8.1?

no unfortunately. CIDER was straddling both tools.nrepl and nrepl/nrepl through 0.19 but the most recent 0.20 dropped tools.nrepl support. now the entire application needs to be newer nrepl throughout

So… if I want to make the leap… is there an upgrade guide?

we can chat in #cider but just check your deps for tools.nrepl.

Cool, thanks!