I have a very faint memory of that error. Is your clj up to date?

you probably have an empty dir in your gitlibs directory

at ~/.gitlibs/libs/com.cognitect/test.runner/209b64504cb3bd3b99ecfec7937b358a879f55c1

there was some bugs in the recent prereleases that would cause this

you can rm -rf that sha dir and clojure -Sforce -M:test:runner to fix up

Ah, yes, I am still running the prerelease, probably. Sorry for the noice!

in that case, you might want to clean your whole ~/.gitlibs when you update

Yes, that did it. Thanks!

@U0ETXRFEW Also, if you make a fresh clj-new project, the test runner should be an https URL:

(! 885)-> clojure -X:new :name pez/example
Generating a project called example based on the 'app' template.
(! 886)-> cat example/deps.edn 
{:paths ["src" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.10.2"}}
 :aliases
 {:run-m {:main-opts ["-m" "pez.example"]}
  :run-x {:ns-default pez.example
          :exec-fn greet
          :exec-args {:name "Clojure"}}
  :test {:extra-paths ["test"]
         :extra-deps {org.clojure/test.check {:mvn/version "1.1.0"}}}
  :runner
  {:extra-deps {com.cognitect/test-runner
                {:git/url ""
                 :sha "b6b3193fcc42659d7e46ecd1884a228993441182"}}
...

Maybe you have a rewrite rule in your Git config?

Nah, I had just been testing some different variants. 😃

Actually this probably is in the right direction. I couldn’t get it to work, because I didn’t really know how to do it. But adding a short pause between tapping and untapping makes it work.

#?(:cljs (set! *exec-tap-fn* (fn [f] (f))))

(def tapped (a/chan (a/sliding-buffer 1)))
(def save-tap (fn [v] (a/offer! tapped v)))

(deftest let>
  (testing "Evaluates as `let`"
    (is (= [:foo :bar] (sut/let> [foo :foo
                                  bar :bar]
                                 [foo bar]))))

  (testing "Taps the binding box"
    (add-tap save-tap)
    (is (= [:foo :bar]
           (sut/let> [foo :foo
                      bar :bar]
                     [foo bar])))
    #?(:clj (a/<!! (a/timeout 10)))
    (is (= '[[foo :foo]
             [bar :bar]]
           (a/poll! tapped)))
    (remove-tap save-tap))
...

(Probably would have worked with the atom as well, but I had already switched to channels and it does make for less boilerplate so I let it be like that.)

1, 2, and 4 are the same on 1.10.3. 3 is not legal on 1.10.3:

Clojure 1.10.3
user=> (let [{:keys [] :as m} {:a 1}] m)
{:a 1}
user=> (let [{:keys [] :as m} [{:a 1}]] m)
[{:a 1}]
user=> (let [{:keys [] :as m} (list {:a 1})] m)
Execution error (IllegalArgumentException) at user/eval143 (REPL:1).
No value supplied for key: {:a 1}
user=> (let [{:keys [] :as m} (list {:a 1} {:b 2})] m)
{{:a 1} {:b 2}}

So there already was a difference between 2 and 3.

@nilern FYI since you thought it was a bug.

Okay more like it is an opportunity to create bugs by writing a map pattern and giving it a seq where one of those was a mistake and then it just works but ignores the rest of the seq

Ok, so this is logical actually I believe. Vectors are associatives as well. So if you say destructure associative as m and use m you get back the associative as-is. But sequence are not associative, and when destructured as an associative they are coerced into one. So #3 used to throw because it doesn't have an even number of key/value pairs for the coercion. While in #4 it does so you get a map where the first element in the seq is the key and the second is the value. And with 1.11, sequence of a single or trailing map destructure as an associative of that map. So now in #3 you get single map back.

Though I'm curious, what happens in 1.11 for:

(let [{a :a}
      (list :a 1 :b {:a 2})]
  a)

(! 893)-> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.11.0-alpha1"}}}'
Clojure 1.11.0-alpha1
user=> (let [{a :a}
      (list :a 1 :b {:a 2})]
  a)
1

Does this no longer works in 1.11?

(let [{:keys [a b]}
      (list :a 1 :b 2)]
 [a b])
;;> [1 2]

it does work

Ah I see. Only the ((partial addn 100 :a 1) {:b 2}) tests still fail on Clojure 1.10.x with this backport. Will be automatically fixed for whoever uses sci with Clojure 1.11.1.

On that note, could you imagine a linter that warned on usages of the lazy arities of those core fns? I find myself looking for those in PRs

you mean, force users to use transducers?

that doesn't seem a good idea?

Maybe (->> stuff (map inc) (filter even?) (into #{})) type of thing which I too optimize quite often

Not forcing, just nudging. But at least in our case laziness is rarely if ever justified, and the overhead is a lot less using transducers

As a side note, I too enjoy the ’ing qualifier/naming convention for transducers - so expressive and meaningful.

https://github.com/metosin/jsonista is faster and the API is less crufty

But Cheshire seems still more common and I am actually working on a PR to it as we speak

Much appreciated! thanks.

data.json is rapidly getting faster thx to @U04V5VAUN ...

Depending on the use-case, (for rest, payloads around 1k with shallow maps) data.json is at the same speed as at least Cheshire now. When payloads get bigger, data.json suffer a bit, but not all that much. I haven’t worked that much on writes yet, but I’ve gotten some fairly nice speedups there as well. Regarding crufty api, was that for cheshire or data.json, and if data.json, what do you find crufty about the api? I’m curious since I’m working in that area now (not saying the api will change, just interested).

Meanwhile @nilern’s PR to speed up encoding of cheshire with 15% was merged :)

by replacing doseq with reduce, haha

On the topic of JSON/jackson, don't the same arguments of trying to avoid jackson apply to transit-java?

for data.json, having no deps is a primary goal. for transit, performance is a higher priority (but I'd love for it to lose it's deps too)

Or are there any plans to move transit to data.json eventually?

well note that transit-java is java and having it depend on data.json (clojure) is maybe weird

For the more significant speedups, all of these libs spend a significant amount of time calling assoc! , so I got some code where I wrap a java map so it looks like a persistent map. I’m currently looking into wrapping java lists so it looks like a persistent vector, but couldn’t find the exact interfaces I needed to implement.

I'm not convinced any of that is a good idea :)

(but for reference, for payloads above 10b data.json (and cheshire) seem to be spending about 60% of their time calling assoc!)

true. Recently jackson was bumped for cheshire related to a security thing. Would transit-java also be open to such a bump if there was a security risk (or just for keeping up with the ecosystem)?

yes, of course

I think the issue with transit-java is that it is on a pretty old version of jackson and there have been some (many?) breaking changes in the intervening time so it's a non-trivial change

if I remember correctly from the last time I looked at it

I meant Cheshire, which has parse-string parse-string-strict, parse-stream, parse-stream-strict etc. and cannot parse InputStream even though Jackson can... while Jsonista just has read-value with protocol dispatch.

but putting this in a transit-java issue is the best place for it (there may be one)

https://github.com/dakrone/cheshire/commit/44f3785201f87942ac84558fbe189fb1bbee276b

@alexmiller FYI I am running cheshire and transit within the same project(s) and never saw an issue so far

well, that's good to know, put all that in a transit-java issue :)

We have exclusions on jackson in our project-clj (for whatever reason)

Ah, the Jackson CVE is only relevant to cbor which isn't used in transit-java, so I would not have a good case to bump it in that lib

But according to their docs, newer minor versions should not break libs using older ones: https://github.com/FasterXML/jackson/wiki/Jackson-Releases#general

(with a caveat about deprecated methods)

This is awesome!

We also just merged a bunch of changes on dev to actually take advantage of the new feature by simplifying a lot of apply / apply concat / (into [] cat ..) style code that was dealing with named arguments being passed around.

You're not a bit worried that this release is meant for "early feedback" on the feature which could mean breaking changes?

We’ve run alpha builds of Clojure in production since 2011. Sometimes we’ve had to revert a few early changes, but it’s very rare.