I like to include the project name, because it makes it easier for the caller (the developer) to connect the dots when there are in a namespace.

That definitely makes sense it's also nice that project code can then be sorted together in the require portion of the namespace. I find that with my datomic schema files I'd like to use ::attr-name for a lot of my queries and I'd prefer not to clutter my entities with my project prefix, so it got me to wondering if there would be other benefits to having application code at the top level.

I guess the authors think kaocha has better ideas > For new projects or when using Clojure CLI, check https://github.com/lambdaisland/kaocha.

This project seems to be coupled with boot... right?

Parallel tests isn't really a unique feature as that is implemented by Eftest, not bat-test.

It also has a Lein plugin and CLI main function was contributed, but not merged. Supporting even both lein and CLI in the same project would be inconvenient (Boot support could be dropped at this point.)

I probably never ran tests parallel, it causes too much problems with any stateful applications and usually testing pure library code is fast enough anyway.

Dropping both lein and boot support and releasing CLI main fn as version 1 might make sense, but that would be a breaking change for any existing users and except for maybe parallel tests, Kaocha should have all the other features already.

@U3JH0P5LJ what stops you from using it?

@U0DJ4T5U1 nothing, of course! — but especially with something so crucial as testing it's nice to be on a well worn path that other people are on, and investing in, so that when we inevitably have issues or questions we are not alone

(comp vals (partial group-by rest))?

(let [coll [[1 2 3] [2 2 3] [3 4 5] [4 4 5]]]
  ((comp vals (partial group-by rest)) coll))
([[1 2 3] [2 2 3]] [[3 4 5] [4 4 5]])

these two tuples should not be included:

(->> [[1 2 3] [2 3 4]]        ((comp vals (partial group-by rest))))

They are in separate partitions. You could filter the sequence to collections that have more than one 3 tuple in them

I could filter afterward, but that's less efficient than the xforms way where it only does one pass I think?

(defn have-dupes [xs]
  (filter #(> (count %) (count (group-by identity %)))
          xs))

I doubt there is much of an efficiency difference. When in doubt, http://clojure-goes-fast.com/blog/benchmarking-tool-criterium/.

Good question. I've no idea why I wrote it like that (over four years ago): https://github.com/clojure/core.memoize/commit/e3f89e6e6337518871bd9478f70453ef4b451946#diff-7397fb2f460c18243c5269bdde7e2dfb02c76f5fea8e4b3a7b648bb9e20f2f11

:D I love that response. It'll be pleasant to look back to it when I inevitably stumble upon something that I wrote myself, and think the same exact thing.

My suspicion is that such things are the result of a refactoring, e.g. pulling a function out so you can re-use it in multiple places

@U04V15CAJ The question -- a very reasonable one -- is why I wrote it as a def for an anonymous function, instead of as a defn- (especially since in that same change, I replaced a number of defn ^:private instances with defn-).

My suspicion is that it was first an inline predicate which was moved higher up, but this is only a suspicion :)

You might be able to tell by looking at the git history of course

Neh, it doesn't make sense what I said, now I actually looked at the commit, never mind ;)

Heh, exactly my point.