This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (10)
- # announcements (2)
- # architecture (16)
- # beginners (51)
- # bitcoin (3)
- # calva (1)
- # cider (6)
- # cljdoc (8)
- # cljs-dev (14)
- # cljsrn (4)
- # clojure (59)
- # clojure-italy (26)
- # clojure-losangeles (1)
- # clojure-nl (13)
- # clojure-spec (54)
- # clojure-uk (81)
- # clojurebridge (4)
- # clojurescript (20)
- # core-async (16)
- # cursive (39)
- # datomic (27)
- # emacs (12)
- # events (1)
- # figwheel-main (20)
- # fulcro (35)
- # funcool (1)
- # graphql (9)
- # hyperfiddle (10)
- # jobs (1)
- # jobs-discuss (7)
- # keechma (10)
- # lumo (22)
- # nrepl (18)
- # off-topic (28)
- # onyx (3)
- # pedestal (4)
- # re-frame (8)
- # reagent (8)
- # ring (4)
- # rum (3)
- # shadow-cljs (29)
- # testing (5)
I’m trying to run
(stest/instrument) in a clojurescript repl, but I can’t even get that far:
:dependencies [[org.clojure/clojure "1.9.0"] [org.clojure/clojurescript "1.10.339"] [org.clojure/spec.alpha "0.2.176"]
Am I missing a step somewhere?
I just added the explicit dependency on spec.alpha 0.2.176 this morning, but it makes no difference, I get the same error either way.
You ought to be able to load the namespace though, right?
I’m spinning up a brand new REPL, and the first thing I type is the require, and it won’t load the namespace.
Hmm, something odd in
lein deps :tree too:
“specs” plural? What’s that?
[org.clojure/clojure "1.9.0"] [org.clojure/core.specs.alpha "0.1.24"]
Ah, that would make sense.
So is anybody else having this problem? Can’t
cljs.spec.test.alpha ns in a freshly-started REPL?
It does seem suspicious that it’s looking for it specifically inside the clojurescript jar when I have a perfectly good clojure jar on the same classpath.
Probably that can be fixed by adding
test.check https://github.com/clojure/test.check to your dependencies.
I didn’t get to it on my lunch break, but I just now added the dependency to test.check, and it works great! Thanks a ton! 😄
Ok, thanks, I'll try that on my lunch break; got to start day job now.
Hi! I just tried to update to Clojure 1.9 and get weird errors when building my code:
:cause Call to clojure.core/refer-clojure did not conform to spec:
Sadly this error message is so convoluted that I cannot even figure out which file is causing this. Any idea what to look for?
Unfortunately the error will say it is coming from the requiring ns instead of the file it is in
The ns form isn’t been evaluated yet (because it has an error) so the current ns ( as shown in the message) is still the requiring one
@mpenet, @favila: So the namespace that requires the broken namespace is the one mentioned in the
LOAD FAILURE for <ns> line?
Any idea what this spec problem report might be hinting at? https://gist.github.com/urzds/880cd51851a248230861b178c7d6b986
Also, in the backtrace it mentions a different file from the namespace it mentions in the
LOAD FAILURE for ... line.
So my guess would be that the file it mentions in the backtrace actually contains something funny. But I have no idea what I am looking for...
Yeah, the syntax is
(:refer-clojure :exclude [...]) -- that
:as core part is what is blowing up.
@urzds if you post a Gist of your dependencies and/or the full stacktrace, we can probably narrow it down for you.
Also @urzds check out this page and see if any of your dependencies are listed there https://dev.clojure.org/display/design/Errors+found+with+core+specs
Different question (I am trying to stay on 1.8 and first make sure all my deps are still working): Is it possible to hot patch a function into
clojure.core? Lacinia Pedestal is broken on Clojure 1.8, because it uses a function from 1.9: https://github.com/walmartlabs/lacinia-pedestal/issues/80
@urzds Is there a pressing reason to stay on 1.8?
(I think, yes, you can define your own
clojure.core/pos-int? but you'd need to do it somehow before that Lacinia namespace was even loaded so...)
@seancorfield No pressing need. But before I try to upgrade to Clojure 1.9, I want to make sure everything still works after upgrading all my deps to versions that should in theory be capable of supporting 1.9.
I suspect you'll be caught between a rock and a hard place there with anything that already uses
clojure.spec since such code may assume a number of things present in 1.9 -- although I thought
clojure-future-spec was supposed to patch those up as well?
Ah, I see... it expects you to
(:require [clojure.future :refer :all]) into the spec-using namespace but doesn't add anything to
clojure.core directly. So it only helps you use
clojure.spec in your own code -- that's not going to help with any other code that already assumes 1.9+.
Yeah, I think you'll have to fork
lacinia-pedestal for now, patched with
clojure.future, and then revert to the official version when you're ready to move to 1.9.
But, frankly, I would consider that a waste of effort and just go ahead with the 1.9 upgrade and do any necessary work there instead.
Yes, but they even claim to support Clojure 1.8, so it's actually a bugfix. I'll just send them a PR.
But on 1.8, doesn't it just not use
clojure.spec? That's how most of the libraries seem to handle 1.8 compatibility when they have specs?
So it already assumes
clojure-future-spec is being used? That's kinda odd...
Yes, that's what they suggest to use: https://lacinia.readthedocs.io/en/latest/clojure.html
Ah... and then clearly don't test against that setup 🙂
Overall tho', I still suspect you'd have a lot less pain trying Clojure 1.9 directly instead of all this working-around-spec on 1.8 🙂
Probably a good idea to create an issue (or send them a PR) to add a
:1.8 alias to
project.clj with Clojure 1.8 and
clojure-future-spec so it's easy to test with in the future (and they could auto-test against both 1.8 and 1.9 on CircleCI).
@seancorfield Thanks for all your help! I don't really know what you refer to with the last line, though.
Probably it was good that I tinkered with the different dependencies for so long. Maybe cheshire or commons-codec or commons-io or org.clojure/tools.reader were causing it, because now I :exclude them from deps that request older versions and my code suddenly compiles...
I have a map of var-quoted functions that I'm using as a lacinia resolver map. After add fspecs for all of them and turning on instrumentation, I'm getting this error:
com.fasterxml.jackson.core.JsonGenerationException: Cannot JSON encode object of class: class clojure.spec.alpha$regex_spec_impl$reify__2436: [email protected]