Fork me on GitHub

heh, just discovered that clj does not work if your path has an emoji in it. such a show-stopper bug!!

😡 1

Hi all. Clojure beginner and first-timer here 🙂 First time using Slack as well 😄 ... I have some paranormal activity when trying some core.async stuff and I am going here a good place to ask for a second pair of eyes & brains to try to find out what is going on?


both #beginners and #code-reviews are good channels for that


#core-async as well


General question about clojure.spec.alpha/fdef and testing that with clojure.spec.test.alpha/instrument - are there conditions under which the instrumentation gets bypassed? I am able to trip the spec validation from the REPL, but when the fn is called in the context of a unit test (rather deep in the call stack, mind you) I can not get the validation to fail


I have run into this problem before. If you have a function that is fdef, and then in the same namespace lower, you have a map of say {:keyword fn}to serve as a dispatch, then the reader captures the uninstrumented function. By the time it get instrumented, it is too late.


even if I put the instrument call in the unit test itself


@cpmcdaniel vars are boxes, and spec's instrument replaces the content of that box. If something has grabbed the value inside the box before instrumentation replaces it, you could observe the (non) effect that you're (not) seeing


the other reason why you may not see it is when using AOT-compiled direct linking, but I doubt that's the case here


direct linking calls directly and thus does not go through the var and does not see instrumentation


I'm once again feeling stupid (not enough sleep) what's the best/simplest way to sort vector of nested maps, e.g:

[{:foo [{:bar [{:zap 4}]}]}
  {:foo [{:bar [{:zap 3}]}]}
  {:foo [{:bar [{:zap 2}]}]}
  {:foo [{:bar [{:zap 5}]}]}
  {:foo [{:bar [{:zap 1}]}]}]
want them sorted by :zap, but it has to work for maps with arbitrary level of nesting


"arbitrary" level? So you really don't know what shape the data is, but it will always have a single :zap key in there somewhere @ag?


I think I need a fn of this signature (sort-by-nested coll & ks) where I would call it for example like this: (sort-by-nested my-list :foo :bar :zap)


can't wrap my head around it

Joe Lane21:08:33

So, you know the path ahead of time @ag?

Joe Lane21:08:47

And, for a given set of maps, it's the same path?


yeah, I know the path


(sort-by #(get-in % [:foo :bar :zap]) ...)

Joe Lane21:08:30

But the vals are not maps, their vectors, right?


(although your example above has vectors too)


But whatever the path to :zap is, that's what you need in your sort-by accessor function.


ah, @seancorfield I think you're on the right path, I'm gonna play with it. Thank you


ended up doing something like this:

(defn get-in*
  [m ks]
  (reduce (fn [acc k]
              (map? acc)  (get acc k)
              (coll? acc) (->> acc
                               (keep #(get-in* % [k]))
              :else       (reduced acc)))

   (first (get-in* x [:foo :bar :zap])))
 [{:foo [{:bar [{:zap 4}]}]}
  {:foo [{:bar [{:zap 3}]}]}
  {:foo [{:bar [{:zap 2}]}]}
  {:foo [{:bar [{:zap 5}]}]}
  {:foo [{:bar [{:zap 1}]}]}]


vectors are associative, so you can use indices as keys. for eg:

 #(get-in % [:foo 0 :bar 0 :zap])
 [{:foo [{:bar [{:zap 4}]}]}
  {:foo [{:bar [{:zap 3}]}]}
  {:foo [{:bar [{:zap 2}]}]}
  {:foo [{:bar [{:zap 5}]}]}
  {:foo [{:bar [{:zap 1}]}]}])


Yup, that's right, but in my case values can be either maps or vectors


I have a config.edn file (env variables) in the root of my project (the root is not on the classpath because it’s not specified). As a result, the following won’t work:

(io/resource "config.edn") ; => nil
But this would work
(io/as-url (File. "config.edn")) ;=> #object[ 0x6e4e60f5...]
If one wanted to continue using resource over the File. solution, I would have to add the root "." to the classpath. Is there a downside to adding the root to the classpath? or would the preference be to opt for io/resource and just move config.edn to the resources dir?


it depends. typically, config belongs outside of the program/jar so that it can be specified at runtime. what kind of config is this?


My config.edn would be configuring all aspects of the app itself e.g. secret keys, ports, database URI etc. The secrets themselves would live outside the config.edn and the config.edn pulls them in. (i’m using Aero)


i'm not sure familiar with Aero, but if config.edn is just a template for loading config values (ie. it will be the same for everyone), then putting it on the resource path seems fine. otherwise, I would load it at runtime based on some user provided path


@tkjone I too use aero, and what I’ve tended to do is have a “default” config.edn in a resources sub-folder (which is part of the classpath), but then allow an alternative config.edn file to be specified on the command line. The default is only used if nothing is provided on the command line, and generally contains aero instructions to just read from environment variables.


Here’s an example: • Default config.edn, showing delegation to env vars: for my production environment: (note mix of env vars and “hardcoded” values) • Code that reads command line and determines which config.edn to read: and (note that I also use mount for state management, so it’s where the config.edn gets managed at runtime).


Not saying it’s the “best” or even the “right” way to do this mind you, but it’s worked well enough for me in a variety of apps over the last 5 years or so.