Good morning! Quick question. I have the following: (defn hiworld [] nil) (deftask alltests [] (bat-test :on-start hiworld)) Which produces the following error: option :on-start must be of type sym In that context, hiworld is a symbol, but I still see an error. I’m using mount.core, and my tests are producing DerefableState errors, which suggest that the :start isn’t being called on those states. My goal is to use a function in :on-start to do a mount/start. But first step is getting the aforementioned hiworld function to work. Any insight will be appreciated! Thanks
@ecolui in that context hiworld is a var, not a symbol. to make it a symbol add a quote to the front: 'hiworld
you may also need to fully qualify it, e.g. boot.user/hiworld
if it is in the build.boot
file
Thanks @martinklepsch. I get a message that indicates that boot/user.clj is not in the classpath, but I can google around and figure that one out. Take it easy.
@ecolui fwiw I think it's usually expected that the symbol refers to a namespace/var in your source-paths
so maybe try defining the function there
cool beans - my ultimate goal is to create a function that calls mount/start. That last piece of information you gave me will save me some time, so thank you very much!
you're most welcome 🙂
Man after wrecking my brains for like 10 hours I finally figured out what I needed to do, thanks to you! I appreciate it man
Hi. I’m sure I’m doing something odd. My boot.properties sets BOOT_VERSION=2.8.1 and BOOT_CLOJURE=1.9.0 my build.boot is very simple as well.
(set-env!
:source-paths #{"src/cljs"}
:resource-paths #{"html"}
:dependencies '[[adzerk/boot-cljs "1.7.228-2"]])
(require '[adzerk.boot-cljs :refer [cljs]])
~
~
when I do boot cljs
I get an error around clojure.lang.ExceptionInfo: Call to clojure.core/ns did not conform to spec:
I’ve googled it and it talks about core.async but I’m at a loss. I’m using JAVA 10 on a mac.That error says one of your dependencies -- or your own source code -- has a syntax error in the ns
form, that the compiler had not used to check.
@jduhamel I'd take a close look in your source files first, at the ns
declaration at the top of each file.
If the exception message includes more detail, it might be able to point you at the specific problem...?
the spec message should tell you which namespace it is
there are a bunch of libs that had bugs, and the majority of them have had fixed versions out for a long time
clojure.lang.ExceptionInfo: Call to clojure.core/ns did not conform to spec:
In: [1] val: ((require [clojure.string :as string] [cljs.source-map.base64 :as base64])) fails spec: :clojure.core.specs.alpha/ns-form at: [:args] predicate: (cat :docstring (? string?) :attr-map (? map?) :clauses :clojure.core.specs.alpha/ns-clauses), Extra input
data: {#object[clojure.lang.Keyword 0x665df3c6 ":clojure.spec.alpha/problems"] [{#object[clojure.lang.Keyword 0x68b6f0d6 ":path"] [#object[clojure.lang.Keyword 0xd4a5e87 ":args"]], #object[clojure.lang.Keyword 0x4044fb95 ":reason"] "Extra input", #object[clojure.lang.Keyword 0xaa549e5 ":pred"] (#object[clojure.lang.Symbol 0x36f48b4 "clojure.spec.alpha/cat"] #object[clojure.lang.Keyword 0x5c00384f ":docstring"] (#object[clojure.lang.Symbol 0x3b7ff809 "clojure.spec.alpha/?"] #object[clojure.lang.Symbol 0x1bb564e2 "clojure.core/string?"]) #object[clojure.lang.Keyword 0x62e6b5c8 ":attr-map"] (#object[clojure.lang.Symbol 0x3f792b9b "clojure.spec.alpha/?"] #object[clojure.lang.Symbol 0x7b8233cd "clojure.core/map?"]) #object[clojure.lang.Keyword 0x4b20ca2b ":clauses"] #object[clojure.lang.Keyword 0x1cbf6e72 ":clojure.core.specs.alpha/ns-clauses"]), #object[clojure.lang.Keyword 0x34494da0 ":val"] ((#object[clojure.lang.Symbol 0x6aecbb8d "require"] [#object[clojure.lang.Symbol 0x1af146 "clojure.string"] #object[clojure.lang.Keyword 0x765cf2d4 ":as"] #object[clojure.lang.Symbol 0x4da602fc "string"]] [#object[clojure.lang.Symbol 0x2a8d39c4 "cljs.source-map.base64"] #object[clojure.lang.Keyword 0x765cf2d4 ":as"] #object[clojure.lang.Symbol 0x25b2cfcb "base64"]])), #object[clojure.lang.Keyword 0x72758afa ":via"] [#object[clojure.lang.Keyword 0xfb9c7aa ":clojure.core.specs.alpha/ns-form"]], #object[clojure.lang.Keyword 0x4c398c80 ":in"] [1]}], #object[clojure.lang.Keyword 0x7fc6de5b ":clojure.spec.alpha/spec"] #object[clojure.spec.alpha$regex_spec_impl$reify__2436 0x74a0e95 "clojure.spec.alpha$regex_spec_impl$reify__2436@74a0e95"], #object[clojure.lang.Keyword 0x21baa903 ":clojure.spec.alpha/value"] (#object[clojure.lang.Symbol 0x607fbe09 "cljs.source-map.base64-vlq"] (#object[clojure.lang.Symbol 0x6aecbb8d "require"] [#object[clojure.lang.Symbol 0x1af146 "clojure.string"] #object[clojure.lang.Keyword 0x765cf2d4 ":as"] #object[clojure.lang.Symbol 0x4da602fc "string"]] [#object[clojure.lang.Symbol 0x2a8d39c4 "cljs.source-map.base64"] #object[clojure.lang.Keyword 0x765cf2d4 ":as"] #object[clojure.lang.Symbol 0x25b2cfcb "base64"]])), #object[clojure.lang.Keyword 0x60a2630a ":clojure.spec.alpha/args"] (#object[clojure.lang.Symbol 0x607fbe09 "cljs.source-map.base64-vlq"] (#object[clojure.lang.Symbol 0x6aecbb8d "require"] [#object[clojure.lang.Symbol 0x1af146 "clojure.string"] #object[clojure.lang.Keyword 0x765cf2d4 ":as"] #object[clojure.lang.Symbol 0x4da602fc "string"]] [#object[clojure.lang.Symbol 0x2a8d39c4 "cljs.source-map.base64"] #object[clojure.lang.Keyword 0x765cf2d4 ":as"] #object[clojure.lang.Symbol 0x25b2cfcb "base64"]]))}
This is a brand new install of boot (I’ve never used it and a friend was raving about it) I’ve been a lein person.
that’s a couple layers of printing /reporting mess there for sure
but I think it’s cljs.source-map.base64 - this was an issue in ClojureScript
https://dev.clojure.org/display/design/Errors+found+with+core+specs has a list of stuff like this in public libs
ah ok, I’m guessing that’s brought in by boot-cljs.
ClojureScript itself had this problem up to 1.9.93
I’ll try a more up to date version of boot-cljs or would it be better to explicitly depend on clojurescript with a version?
I’m not sure I’m qualified to answer that but either seems like a good thing to try :)
same error with a more up to date version of adzerk/boot-cljs so I guess next step is to be explict in my clojurescript
that error is in a pretty old version at this point (years old)
@jduhamel boot-cljs should recommend you to add explicity cljs dependency
Changing my dependencies to :dependencies ’[[org.clojure/clojurescript “1.10.339”] [adzerk/boot-cljs “2.1.4"]]) made the problem go away. Thanks
my bad for following the moderncljs tutorial (which I knew was a couple of years old) and trying it with Java 10. I’ll send in an issue on that as well.
I like the idea of getting a deeper understanding of the tooling rather than having magic happen. I just wish some of the errors were a little more tractable.
In: [1] val: ((require [clojure.string :as string] [cljs.source-map.base64 :as base64])) fails spec:
-- looks like it had require
instead of :require
in that namespace (and has since been fixed).It's a pity the spec failure goes to "Extra input" as the default here, rather than "Expected keyword"... I suspect that would be harder to arrange...
Here's the commit that fixed it https://github.com/clojure/clojurescript/commit/48b83d900dc46e912fcefc2365f806f5c8c15dfe#diff-c791280183b53d7bc6a32841cfa92859
(based on seeing cljs.source-map.base64-vlq
in the spec output -- and that has the require of cljs.source-map.base64
in it)
@jduhamel Does that help with the "deeper understanding ... rather than ... magic"?
(the spec failure messages definitely take some getting used to!)
It does, I’m just going to have to plow through some of the error messages and get used to it.
The magic was more refering to the fact that I’m not always clear on what lein is doing but I am far clearer on what boot is doing. However when boot goes awry it’s less clear
@seancorfield I actually spent a big chunk of time a couple weeks ago looking at this specific genre of failure and Rich and I have talked about it
you really want to say that instead of having “extra” stuff at the end, that you expected one of the prior component spec(s)
FWIW, I tried it with Clojure 1.10.0-alpha7 (but otherwise the same older deps that @jduhamel had) and you do at least get this message:
clojure.lang.Compiler$CompilerException: Syntax error macroexpanding clojure.core/ns at (cljs/source_map/base64_vlq.clj:1:1).
there is a ticket in this ballpark too https://dev.clojure.org/jira/browse/CLJ-2013
@jduhamel Totally agree on that lein
vs boot
observation!
so, still noodling on this one from the error perspective
much nicer message. So it leads to a follow-on question. if [adzerk/boot-cljs “2.1.4”] is the more correct version. why wouldn’t it specify a more up to date clojurescript.
that is a good question and I’m curious what your dep tree is
How would I find that out?
it doesn’t even look like boot-cljs has any deps to me
which doubly confuses me
maybe that’s just boot confusing clojars and maven though
https://github.com/boot-clj/boot-cljs/blob/master/build.boot seems to bring in clojurescript 1.7.228 which is very old
oh, it’s test-scoped only so shouldn’t act as a dep
beyond my boot knowledge
Really I was just doing the tutorial 1 from moderncljs. then when I had the error I updated the adzerk to boot-cljs to “2.1.4”.
Same. but that’s why I try the tutorials. Trying to increase my knowledge.
running tutorials is a great way to tour all modes of error :)
seems to be. Thought I was relatively safe with only 1 dependency
I honestly don’t understand where your cljs dep comes from with boot
This is one of those cases where you can't easily get at the actual dependencies involved because of the way the cljs
blows up before subsequent tasks run. You can get the basic dependencies from boot deps -d
but that doesn't expand the "test" dependencies, so the natural next step would be boot cljs show -d
but cljs
uses pre-wrap
so "everything" happens before any subsequent tasks can run...
Well it’s already taught me quite a bit about being more explicit with dependencies when needed.
@alexmiller The cljs
task essentially brings in those "test" dependencies -- for the development path through the code.
(`:scope` always seems to mislead 🙂 )
Boot-cljs will add default Cljs dependency (only to the pod/classloader used by boot-cljs) if one doesn't exist in project, but it should also print a warning recommending adding direct dependency: https://github.com/boot-clj/boot-cljs/blob/master/src/adzerk/boot_cljs.clj#L26
Because most Boot tasks only add the dependencies to the tasks pod (separate classloader and clojure runtime etc) show --deps
won't show the default dependency ever
if only there was a tool that would just build the classpath you asked for
Hah, looks like many Boot developers have switched to clj or lein already.
I was sorta bouncing between clj and boot.
We do so much with Boot that I can't see us "abandoning" it, but I would like to move all our basic dev/test stuff to deps.edn
and clj
-- if only because we're sort of already half way there: our deps have been in external EDN files with Boot for years and we have override deps via a version.properties
file that "pins" versions of deps across all our projects.