This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # arachne (2)
- # architecture (23)
- # bangalore-clj (5)
- # beginners (35)
- # boot (79)
- # cider (6)
- # cljs-dev (34)
- # cljsrn (9)
- # clojure (164)
- # clojure-argentina (2)
- # clojure-austin (4)
- # clojure-italy (7)
- # clojure-russia (40)
- # clojure-serbia (1)
- # clojure-spec (76)
- # clojure-uk (36)
- # clojurescript (47)
- # cursive (14)
- # datascript (2)
- # datomic (8)
- # dirac (19)
- # emacs (29)
- # heroku (7)
- # hoplon (35)
- # jobs-rus (1)
- # juxt (2)
- # leiningen (1)
- # lumo (23)
- # mount (4)
- # off-topic (22)
- # om (16)
- # onyx (19)
- # parinfer (10)
- # pedestal (47)
- # proton (5)
- # re-frame (88)
- # rum (1)
- # spacemacs (33)
- # sql (29)
- # uncomplicate (1)
- # unrepl (131)
- # untangled (5)
- # yada (12)
Why can I not say (spec/and (spec/keys :req-un [::id]) (spec/keys :req-un [::old-id]))?
There are some examples about a third of the way thru the Guide https://clojure.org/guides/spec
(there's only three mentions of
merge and it's easy to miss squished in between a couple of big code blocks)
You can run the result thru
spec.test/summarize (I think) and you can write a
deftest around that to assert that the summary shows success.
However, one thing to consider is that generative tests are not "fast" like most unit tests should be -- so you might want to think about having a separate task to run generative tests, so that your unit tests stay nice and fast.
Ok. So I have to write a deftest myself. Thats fine given how long it takes to run them.
question about tooling: since spec is intextricably linked to 1.9-alphas no tooling can exist for repl's until they are separated. To include spec otherwise would necessarily require hijacking the specified clojure version to 1.9, which would possibly violate people's expectations. Does this sound true and do I have any misconceptions?
I'm working on spec tooling in CIDER and I don't know how i could begin without hijacking the clojure version of the project that CIDER is interacting with
I'm not sure I follow your base assumption. Can tooling check for the existence of spec?
i was just wondering about
wouldnt' this throw an error on any clojure < 1.9?
(ns nrepl-spec (require [clojure.spec :as s])
1. Unhandled java.io.FileNotFoundException Could not locate clojure/spec__init.class or clojure/spec.clj on classpath.
when they decouple spec from 1.9 i can just load spec in any clojre 1.7 > which is what cider supports
i guess that will have to be the case anyways, as I'm sure spec versions will be mismatched
i'm assuming when it's released, CIDER will have clojure.spec 1.8 and someone might be using 1.4? or will it be like clojure.string or set where it's built in
didn't know if it's something that will be specified in the project file with a version or if it will be more baked into the language like set and string, etc
there isn't a guarantee that clojure.spec will be released outside of 1.9 -- it's been mentioned before, but until you see a commit SHA, can't make assumptions
i sat next to stuart at dinner at the conj and he said that's what was holding up the release of 1.9. I was going off of that but i understand it's not official
This does bring up a interesting point in the discussion of middleware and nrepl. As long as tools insist on installing new deps into the repl there's going to be problems like this.
but I do wish all clojure tooling could move away from having middleware in the JVM repl
it just causes a lot of problems, for no real need. The dependencies used by middleware muck with the resolution order of your repl. Stuff like this spec discussion are due mostly to not being able to use spec in tooling because it might be used in a version of clojure that doesn't support it
all I needed was netcat + a tcp port...and now I have a RPC server inside my program
I must admit, I too find it frustrating to need different dependencies in a project based on what a particular editor or other tooling needs. CIDER is great but with the “regular” stack of DEV middleware it takes ages to start an nREPL server. I’ve recently switched to Atom/ProtoREPL and that requires different libraries in play. For non-DEV work, we use the Socker Server but that’s “too light” for useful tooling (unless tooling was rewritten to assume a more neutral Clojure environment and just expected to execute “regular” Clojure over-the-wire).
might be off-topic for spec but not in general - being parsimonious about dependencies is very important.
gem install hairball applies to our community too
If you Bing
gem install hairball it brings up this as the top result: https://rubygems.org/gems/hairball/versions/0.1.0 — which in turn links to this: http://www.confreaks.com/videos/860-railsconf2012-keynote-simplicity-matters 😂
That's awesome. Although I'm disappointed that it's not a gem that downloads the most recent of every other gem...