Fork me on GitHub
#clojure-spec
<
2019-08-10
>
norton13:08:16

@alexmiller Hello. I have a question regarding spec-alpha2. Specs and tests written with specs stopped working from this commit. https://github.com/clojure/spec-alpha2/commit/2bd68ffee3a775e6fa0f925260b94a9c421787c0 I am reviewing the diff and I spotted one item that I’m curious about. The third argument to conform* on this line 220 https://github.com/clojure/spec-alpha2/blob/2bd68ffee3a775e6fa0f925260b94a9c421787c0/src/main/clojure/clojure/spec_alpha2.clj#L220 and on line 326 https://github.com/clojure/spec-alpha2/blob/2bd68ffee3a775e6fa0f925260b94a9c421787c0/src/main/clojure/clojure/spec_alpha2.clj#L326 looks inconsistent. Is this difference intentional … x on line 220 and spec on line 326?

alexmiller13:08:08

Yeah, the first one should be spec

alexmiller13:08:47

Do you have an example of what’s not working for you?

norton13:08:27

Sorry, I do but not a small sample that I can share.

alexmiller13:08:07

Ok, would be happy to take a look if you can describe

norton13:08:54

Or … can you share a recipe how I can test out locally by making this change?

norton13:08:02

The essence of the test is as follows: (doseq [spec (filter #(contains? STRING-NAMESPACE (namespace %)) (keys s/registry)))] (let [p (prop/for-all [g (s/gen spec)] (s/valid? spec g))] (is (= {:result true} (abbrev-result (tc/quick-check 100 p))))))

norton13:08:24

where STRING-NAMESPACE is a string used to filter keys from the s/registry

norton13:08:58

I might not have all of the parens correct … just pseudo-code 😉

alexmiller14:08:01

that conform thing above was fixed in the next commit btw

alexmiller14:08:51

so what fails? which spec and what's the failure?

norton15:08:19

Here is a subset of the stack trace. I bumped up to the latest version 'ca131c1bec353a6ebe4fe8e0a8b6f8825734ef42'.

norton15:08:27

Here is a subset of the stack trace. I pinned it at the version '000d7d83a98ca3af58a44c20d7bd9fea0f4b03ab'

norton15:08:24

Interestingly, there seems to be a different failure(s) between these two commits.

norton15:08:26

The commit '922b0f5886735641e0cdded58fc85011f79cc292' has the same stack trace as 'ca131c1bec353a6ebe4fe8e0a8b6f8825734ef42'. This commit introduced the second failure.

norton15:08:04

As I posted originally, the commit '2bd68ffee3a775e6fa0f925260b94a9c421787c0' introduced the first failure.

norton15:08:20

I will try to narrow down the issue to a small repository.

alexmiller15:08:38

sorry, hard for me to do much without seeing the spec

norton15:08:04

Understand

eval202016:08:05

I would expect the first (s/valid?...) to be without the {:closed ...}

alexmiller17:08:53

yes, I whiffed some copy/pasta on the example, fixed

1