Fork me on GitHub
#clojure-spec
<
2019-08-12
>
norton00:08:25

@alexmiller Thank you. That issue is resolved. I have a new one. Here is a failing example taken from the spec Guide. This is with the latest version 'e58788107ee2ab765a7d46854b2cffd85429e339'.

seancorfield00:08:07

@norton I'll defer to Alex for the final word but I think that's a case where Spec 2 and Spec 1 differ. I think I ran across something like that when I tried converting our code over to Spec 2...

norton00:08:36

@seancorfield thank you. I will take another look.

seancorfield01:08:02

I'm trying a few things locally but it isn't jogging my memory of what I had to do here. So it may be an unintended bug.

seancorfield01:08:51

Hmm, the more I look at this, the more I think it is a new bug. I pulled up the Spec 2 branch of our code and we have some specs that look very similar to the above and used to work. Right now I can't test the Spec 2 branch on my laptop so I can't dig in any further until tomorrow @norton

norton01:08:36

@seancorfield Yes, I think so. This type of spec was working with the 'dc960158ccb9cf8b5dc555842eea5e1af12f28c2' commit.

Alex Miller (Clojure team)02:08:51

fixed, just missed the expand-spec for with-gen

seancorfield05:08:06

@alexmiller That fixes the problem reported above, but you can't do (s/exercise ::kws) -- that produces

user=> (s/exercise ::kws)
Execution error (IllegalArgumentException) at clojure.spec-alpha2.protocols/eval173$fn$G (protocols.clj:11).
No implementation of method: :gen* of protocol: #'clojure.spec-alpha2.protocols/Spec found for class: clojure.lang.PersistentHashSet
user=> 

Alex Miller (Clojure team)09:08:17

That is a spec 2 difference - the gen needs to wrap s/spec around the set

seancorfield15:08:05

Ah yes. That was the difference I was thinking of when I first thought this was a Spec 1/2 difference but still couldn't get that example working! /cc @norton

norton09:08:23

@alexmiller @seancorfield Thank you. The issue above is fixed. There is one more.

norton09:08:33

This is an abridged version of a larger spec that illustrates the failure.

Alex Miller (Clojure team)14:08:00

fixed, added some tests to catch this and prior

schmee14:08:17

Can you alias a spec to another spec? I have a situation like this where I would like to not repeat the definition of task-state for both old and new:

(s/def ::task-state #{... big set ...})
(s/def ::old ::task-state)
(s/def ::new ::task-state)
(s/def ::event (s/keys :req [::old ::new]))

schmee14:08:10

the code above doesn’t work, but it hopefully shows the intent

jjttjj14:08:57

That code should work though?

Alex Miller (Clojure team)14:08:05

should work (in spec 1)

schmee14:08:12

you’re right, this was PEBKAC… facepalm sorry for the noise

ataggart17:08:17

Anyone know of guidance around organizing specs and the code being spec’d? E.g., putting specs in the same file as the things being spec’d, or in separate parallel nses, or in a separate common spec ns?

ataggart17:08:07

I swear I read that doc! 🙂

seancorfield18:08:55

@alexmiller I'm updating our branch to the latest Spec 2 at work and ran into this exception "No implementation of method: :conform* of protocol: #'clojure.spec-alpha2.protocols/Spec found for class: java.lang.String", -- would that be from this spec: (s/def ::empty-id (s/or :empty #{""} :id ::pos-int)) ?

Alex Miller (Clojure team)18:08:57

Dunno, would have to take a closer look

seancorfield18:08:46

I'll try wrapping #{""} in (s/spec ,,,) and see if that fixes it... but we have a lot of set-as-predicate specs and this has all worked with earlier Spec 2 builds...

seancorfield18:08:23

Nope. Problem lies deeper. Digging...

seancorfield18:08:33

Seems to be related to this

(defmacro param-spec
  [coerce str-or-spec & [spec]]
  (let [[to-str spec] (if spec [str-or-spec spec] [str str-or-spec])]
    `(s/with-gen (s/and (s/conformer ~coerce) ~spec)
       (fn [] (g/fmap ~to-str (s/gen ~spec))))))
So it's around dynamically built specs.

Alex Miller (Clojure team)19:08:53

@seancorfield you shouldn't have to wrap that so I'd say it's a bug if that fixes it :)

Alex Miller (Clojure team)19:08:29

it's probably not that it's dynamically built but rather something about what's being built (my first suspicion would be with conformer)

seancorfield19:08:03

user=> (require '[clojure.spec-alpha2 :as s])
nil
user=> (s/def ::foo (s/keys))
:user/foo
user=> (s/valid? ::foo {"bar" 42})
Execution error (IllegalArgumentException) at clojure.spec-alpha2.protocols/eval13332$fn$G (protocols.clj:11).
No implementation of method: :conform* of protocol: #'clojure.spec-alpha2.protocols/Spec found for class: java.lang.String
user=> 
Only fails if the map being checked has string keys, rather than keyword keys.

Alex Miller (Clojure team)19:08:49

I changed how some of that keys stuff worked, obviously did not test it very well (but not really emphasizing keys as that's going to be replaced by schema/select)

seancorfield19:08:45

I assume it's trying to check whether unspecified keys conform and not guarding that with a check for whether the key name could actually be a spec?

seancorfield19:08:34

Switching a large code base from s/keys to s/schema/`s/select` will be a massive piece of work so I hope that s/keys will continue to work while we make those changes 🙂

Alex Miller (Clojure team)19:08:23

yeah, I'm trying to keep it working, I'll fix it up

norton22:08:28

All tests are running fine now with 6af1f3.