This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-02
Channels
- # aws-lambda (5)
- # bangalore-clj (1)
- # beginners (96)
- # boot (66)
- # cider (39)
- # cljsjs (2)
- # cljsrn (5)
- # clojure (265)
- # clojure-android (1)
- # clojure-france (1)
- # clojure-greece (32)
- # clojure-italy (4)
- # clojure-russia (2)
- # clojure-sg (1)
- # clojure-spec (27)
- # clojure-uk (25)
- # clojurescript (88)
- # cursive (4)
- # datomic (31)
- # emacs (96)
- # hoplon (10)
- # immutant (14)
- # jobs (2)
- # luminus (1)
- # lumo (66)
- # off-topic (128)
- # om (8)
- # om-next (2)
- # onyx (9)
- # parinfer (5)
- # re-frame (37)
- # reagent (16)
- # rum (9)
- # schema (3)
- # specter (34)
- # unrepl (8)
- # yada (21)
Hi all! Is anyone else getting errors like Call to clojure.core/ns did not conform to spec
? I'm working on a clj/s project and I want to use spec with reframe. I've tried the latest version of clojure (`1.9.0-alpha16`) and I get the aforementioned error. However, when I move the dependency to 1.9.0-alpha10
the error does not occur. Any idea for the change? BTW This is my first attempt at using a clojure alpha version, and I have many dependencies that may be incompatible (I feel that this is unlikely in this case, though correct me if I'm wrong). If needed I can provide more information.
The namespaces for spec just changed in alpha16 and cljs and other deps are not compatible with it
You might want to fall back to alpha15
What's the actual error you're getting?
Many libs had bad ns deps - most of those have been fixed and newer versions exist
I put a gist up: https://gist.github.com/JJ-Atkinson/a1d19e48d9440c2ca9f0bed219c8201f. How can I tell where the error is originating from? I see that it likely is from (onelog/core.clj:1:1)
, but I don't know where that is, (probably in timbre though, I'll see if I can bump that version up).
Onelog is part of ring apparently part of ring-middleware-logger
. I'm currently using the latest of both. So, is the issue not with clojure itself, but with onelog
? If that's the case, I'll see about a pull request/issue to them.
So, after crawling through the error message more thoroughly, it appears that onelog
is using the syntax (ns ... (:import (com.something SomeClass)))
. Spec changed something about ns with -alpha11
, and it was already reported to them https://github.com/pjlegato/onelog/issues/3. Thanks for the help!
Apologies as this has probably been asked a dozen times, but does clojurescript current support generators?
@drewverlee not that I know of, but generators tend to encourage a impure code. Most of what you would need generators for can be done with more functionally pure constructs like map
, filter
and for
.
@alexmiller So if I want to use alpha16 and have cljs in my project I should wait for a compatibility patch or something similar?
@tbaldridge I think @drewverlee is referring to the test.check kind of generators, given that he's asking in here 🙂 @drewverlee test.check supports cljs at least, not sure if clojure.spec's wrapping of it works with cljs, though.
@danielcompton this was the source https://gist.github.com/thheller/738698dfff45280f4e004df1c46af4ba#file-problem-clj
With the announcement of spec moving to its own lib, I see that spec.alpha is under org.clojure, but nothing like org.clojure/clojurescript.spec.alpha? Has it not moved yet?
I have a wrap-error macro that takes a map of context data and a body.
(defmacro wrap-error [args & body]
(let [e (gensym 'e)]
`(try ~@body
(catch Exception ~e
(log-error! ~e ~args)
nil)
(catch Error ~e
(log-error! ~e ~args)
nil))))
I want to make sure that the macro user doesn’t forget to pass in the context map, because if so, the first line of the body wouldn’t get executed. but I’m not sure it’s possible to do that at compile timesorry let me try a better explanation. I want people to use this macro like this:
(wrap-error {:some :data :a 1 :b 2} ...body...)
where the first argument is some metadata to associate with the error, if there is one. the macro has been used mistakenly like this: (wrap-error ...body...)
without the first arg, resulting in incorrect behavior because the first element of body is interpreted as the metadata and not executed. was wondering if there was a way to use spec to prevent this at read-time. less about validating the metadata itself so much as the presence of it.