This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-18
Channels
- # aleph (59)
- # beginners (21)
- # bigdata (1)
- # boot (110)
- # cider (7)
- # clara (1)
- # cljs-dev (160)
- # cljsjs (3)
- # clojars (10)
- # clojure (122)
- # clojure-czech (2)
- # clojure-dusseldorf (5)
- # clojure-france (1)
- # clojure-italy (4)
- # clojure-korea (5)
- # clojure-russia (13)
- # clojure-spec (15)
- # clojure-uk (78)
- # clojurebridge (1)
- # clojurescript (196)
- # core-async (6)
- # core-logic (27)
- # cursive (11)
- # data-science (2)
- # datomic (45)
- # dirac (9)
- # emacs (2)
- # funcool (8)
- # hoplon (16)
- # immutant (13)
- # jobs (1)
- # klipse (11)
- # lein-figwheel (1)
- # leiningen (1)
- # off-topic (3)
- # om (40)
- # onyx (31)
- # pedestal (25)
- # re-frame (55)
- # ring (1)
- # ring-swagger (1)
- # rum (4)
- # specter (1)
- # sql (2)
- # untangled (30)
- # vim (12)
- # yada (12)
It does give warnings but these ones are much more helpful
I created a PR (https://github.com/boot-clj/boot/pull/507) some time ago to bring managed dependencies to boot. I would welcome feedback (here or in the PR) on whether this is a reasonable approach and on the implementation itself.
what is the best way to manage multiple projects in boot? ie something similar to this https://github.com/jcrossley3/lein-modules
could I create a build.boot
script that uses clojure shell to go into each subdirectory and run boot install
in each subdirectory or something similar?
@tmtwd I think you are looking for boot-in-boot?
that is an example of using boot to build multiple boot modules
np, if you have questions I鈥檓 here today 馃槢
@tmtwd do your sub modules have an interdependency?
ok then make sure you look at the semaphore stuff in there
not exactly, it鈥檚 for making sure the deps are handled in the correct order between builds
so in that example project bravo depends on alpha
and the compiled alpha build is dumped into resources for bravo, concurrent builds are not on the road map for boot as it stands
i dont think so, since a task returns a middleware
Boot shows me an incomplete stack trace for exceptions
is there a way to make it show the full stack trace?
@anmonteiro can you post the stack trace to pastebin or something?
clojure.lang.ExceptionInfo: java.lang.Boolean cannot be cast to java.lang.String {:from :boot-cljs}
at adzerk.boot_cljs.util$deserialize_exception.invokeStatic(util.clj:85)
at adzerk.boot_cljs.util$deserialize_exception.invoke(util.clj:76)
at adzerk.boot_cljs$compile.invokeStatic(boot_cljs.clj:75)
at adzerk.boot_cljs$compile.invoke(boot_cljs.clj:59)
at adzerk.boot_cljs$compile_1$fn__277.invoke(boot_cljs.clj:126)
at clojure.core$binding_conveyor_fn$fn__6766.invoke(core.clj:2020)
at clojure.lang.AFn.call(AFn.java:18)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
small enough that it fits here
I want to see the full stacktrace
I know that鈥檚 not all 馃檪
@anmonteiro Do you have minimal example case? Working fine for me
what do you mean?
@juhoteperi this is a bug in ClojureScript master, trying to track it down
@tmtwd See https://github.com/boot-clj/boot/wiki/Tasks#boot-task-model you may be able to write a task that does something concurrently but I imagine the uses would be limited due to how tasks are currently constructed
Hmmmm. There is no way around this exception handling boot-cljs is doing.
But it should contain the stack trace...
when there is a jar in ./resources
like in https://github.com/micha/multi-module-build/blob/master/modules/bravo/src/bravo/core.clj, is it possible to require it like a normal dependency?
@tmtwd sure, but then you may be better off with just running two terminals with boot both dumping to a different target dir
@juhoteperi I ended up creating a build.clj
script and calling
java -cp `boot show -c` clojure.main build.clj
sorry, I think my question was not quite right. Once, the alpha
jar is dumped into bravo/resources, how do I require it in a bravo
namespace?
@tmtwd https://github.com/micha/multi-module-build/blob/master/modules/bravo/src/bravo/core.clj
@tmtwd : @micha can probably answer that question a bit better, the jar in resources is not extracted it鈥檚 just available on the classpath, @richiardiandrea is also the resident boot-in-boot wizard
yeah im not a java expert 馃槢
@anmonteiro you can get full stack traces with boot -vv ...
@micha didn鈥檛 work though, I tried it
the result was I got the same stack trace without the fancy colors 馃槢
@micha no it wasn鈥檛 the whole thing
when I ran it with
java -cp `boot show -c` clojure.main build.clj
I got the whole thing indeedthis is the code path: https://github.com/boot-clj/boot/blob/ac835cea8c18e926bb843e01579b86e3f30458d2/boot/pod/src/boot/util.clj#L261
Boot-cljs modifies the exception
there鈥檚 our answer
@juhoteperi so it doesn鈥檛 seem too useful that Boot-cljs modifies the exception
in the case I pasted above it just didn鈥檛 give any useful information at all
Not sure why that happens
But the special handling is required for boot-reload
oh alright
Maybe this is caused by the exception being from Clojurescript code, instead of something thrown e.g. by the reader
right, this wasn鈥檛 a reader exception
Reader exception about missing parenthesis or such gives proper stack trace
it was being thrown from cljs.closure
Do you know if there is any other way to test this except for running broken Cljs version?
@juhoteperi probably if you pass wrong configuration
it鈥檒l throw an assertion error
let me try
@juhoteperi the thing is, in this case the message is useful because it鈥檚 an AssertionError. but the stack trace seems useless as to where the assertion failed in the code:
java.lang.AssertionError: Assert failed: :nodejs target not compatible with :whitespace optimizations
(not (and (= target :nodejs) (= optimizations :whitespace)))
cljs.closure/check-node-target/invokeStatic closure.clj: 1854
cljs.closure/check-node-target closure.clj: 1853
cljs.closure/build/invokeStatic closure.clj: 1951
cljs.closure/build closure.clj: 1933
cljs.build.api/build/invokeStatic api.clj: 199
cljs.build.api/build api.clj: 187
adzerk.boot-cljs.impl/compile-cljs/invokeStatic impl.clj: 89
adzerk.boot-cljs.impl/compile-cljs impl.clj: 66
...
clojure.core/apply/invokeStatic core.clj: 657
clojure.core/apply core.clj: 652
boot.pod/eval-fn-call pod.clj: 328
boot.pod/call-in* pod.clj: 379
...
boot.pod/call-in* pod.clj: 382
adzerk.boot-cljs/compile/invokeStatic boot_cljs.clj: 71
adzerk.boot-cljs/compile boot_cljs.clj: 59
adzerk.boot-cljs/compile-1/fn boot_cljs.clj: 126
clojure.core/binding-conveyor-fn/fn core.clj: 2020
oh I鈥檓 wrong, in this case it does show where it failed in the code
some praise for boot: https://twitter.com/ptaoussanis/status/788418033983295489
Side effects include feelings of empowerment and regret for time spent on prior build tools
Just deployed new less4clj, sass4clj, boot-reload and boot-cljs!
Is this issue supposed to be fixed in boot 2.6.0? https://github.com/clojure-emacs/cider/issues/1462
it seems like boot encourages a bunch of futures running in boot.user
. Is there a library for making managing those futures more pleasant?
@arohner what are you running in those futures? I rarely have futures in build.boot
. Sometimes tasks run stuff in futures but not sure if you're referring to that when speaking about futures in boot.user
@arohner are you doing that because watch
and repl
otherwise interfere?
Or do you really run single boot invocations whenever you change a file?
cljs node repl or cljs browser repl?
So my workflow is usually something like boot watch reload cljs-repl cljs
from the console. Then I connect via nrepl/cider/whatever and run (start-repl)
which connects to the browser window running switches into a cljs repl
@arohner have you tried that approach (using https://github.com/adzerk-oss/boot-cljs-repl)?
ah, ok. boot repl
gives you a console repl, the nrepl connection is still going to be there either way
@arohner so I usually just run stuff from the terminal so the need for futures does not really arise I guess
when running watch cljs-repl
, is there a way to get the compile errors into the cider window, rather than the terminal?
at some point I needed a working terminal REPL and a watch process which probably is similar to what you're trying to achieve
Made something like this for this use case
;; ========================================================================
;; We could just run `boot dev` at the CLI but when using the `watch` task
;; you cannot also have an interactive `repl`. So we do this `reloaded.repl`
;; like workflow for starting and stopping to boot build pipeline
(def build-container-var nil)
(defn start-build! []
(alter-var-root #'build-container-var (fn [_] (future (boot (dev :build-ids ["public/web"]))))))
(defn stop-build! []
(alter-var-root #'build-container-var (fn [p] (future-cancel p))))
;; ========================================================================
dunno about the errors in cider, not a cider user myself