This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-18
Channels
- # bangalore-clj (1)
- # beginners (36)
- # boot (119)
- # braid-chat (16)
- # cider (14)
- # cljs-dev (34)
- # cljsrn (7)
- # clojars (9)
- # clojure (91)
- # clojure-austin (1)
- # clojure-bangladesh (1)
- # clojure-dusseldorf (5)
- # clojure-israel (1)
- # clojure-russia (3)
- # clojure-spec (6)
- # clojure-uk (7)
- # clojurescript (11)
- # community-development (1)
- # core-async (5)
- # cursive (6)
- # datomic (11)
- # dirac (12)
- # funcool (24)
- # leiningen (5)
- # luminus (5)
- # off-topic (2)
- # om (69)
- # om-next (16)
- # overtone (4)
- # perun (19)
- # re-frame (23)
- # reagent (38)
- # specter (7)
- # uncomplicate (9)
- # yada (4)
@arohner If I understand correctly, I think you can just use binding
before calling the repl
task...
But if you run boot repl
from the command line, how would you fix that? I ended up adding a middleware to boot.repl/default-middleware, but that broke when I ran non-repl tasks, i.e test
. So then I just fixed the code to not assume print-level was always bound
@arohner boot repl -e '(set! *print-level* 3)'
is another way, to make it stick you could add (task-options! repl {:eval '(set! *print-level* 3)})
to your build.boot
I'd like to use a config file to hold database name, etc., and use environ.boot
and environ.core
to make these variables available elsewhere. Is that possible? I haven't been able to find an example.
Like, in build.boot
most people have under their dev
task something like (environ :env {:http-port "3000"})
. In any Clojure file we can pull that out with (env :http-port)
.
Hi @anmonteiro! I tried that, but the Readme says you shouldn't set the .boot-env
file manually. Also Environ didn't seem to pick it up automagically like I thought it would.
Hmm, yes looks like that's what I'll have to do. With a .lein-env
file we can set profiles. https://yobriefca.se/blog/2014/04/29/managing-environment-variables-in-clojure/
I'm a little surprised there's not a similarly direct way of setting these variables for Boot.
anyone know of a task that uses cache dirs in a nice way to cache computation of complex things/files over multiple builds etc? /cc @jellea
I found this solution: Read in the config file as a map.
(def config
(let [f (io/file "config.edn")]
(if (.exists f)
(-> f slurp read-string)
{})))
e.g., config.edn
holds only {:database-url " "}
.
And use like (environ :env config)
.And then of course I put config.edn
in my .gitignore
. This seems hacky, but fine for "12-Factor App" purposes?
is there a way to get BOOT_VERSION and BOOT_CLOJURE_VERSION from my build.boot file? Preferably the fully resolved version, so I don’t need to care about env vars vs. property files?
AIUI, BOOT_CLOJURE_VERSION can come from several places, including env vars or system properties and profile, etc. I could read out of one of those places, but I’m hoping that boot exposes the version it decided to use to the user
basically, I want to assert that BOOT_CLOJURE_VERSION = the clojure version in my build.boot dependencies
Maybe like here? https://github.com/boot-clj/boot/blob/85b0e6786845771a59b9e318b8b60414db0421db/boot/pod/src/boot/pod.clj#L859
I see boot.App/getClojureName and getBootVersion. slightly surprised there’s no getClojureVersion
Strange error when adding a defmulti
:
clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable to resolve symbol: *print-length* in this context, compiling:(/var/folders/rj/8lnf662s3mlgzv5mcq2r2fnc0000gn/T/boot.user1925252583398125504.clj:1:90)
java.lang.RuntimeException: Unable to resolve symbol: *print-length* in this context
this is the code:
(defmulti print-event :type [e])
(defmethod print-event :default [e]
(prn e))
@micha thanks for the -v
tip. but we have lots of source files here. with the verbose mode boot outputs more than hundred of log lines like Commit: adding …
and Filesystem: linking …
which make it cumbersome to investigate boot issues. always have to scroll a couple of times. is there another log level that does not output these but everything else?
hmmm, we have our own custom task like (deftask dev …
and i am calling it like dev -v dev -o none
sure, the problem was that i thought the -v option will be passed down to all calling tasks/functions
its :init-fns
is still being called twice here when only one file has changed
◉ :cp handlers.cljs
Compiling ClojureScript...
• js/app.js
Compile sources, elapsed time: 2040.064529 msecs
Compile sources, elapsed time: 57.103928 msecs
Writing target dir(s)...
Elapsed time: 3.318 sec
if they contain top level forms that produce side effects then those side effects will happen
when i add a console.trace
in that being-called-twice init function i see:
app.cljs:12 init called !!!!!!!!!!!!!!!app$init @ app.cljs:12(anonymous function) @ main20649.cljs:3
core.cljs:3685 Handling re-frame event: [:init]
app.cljs:12 init called !!!!!!!!!!!!!!!app$init @ app.cljs:12(anonymous function) @ init11350.cljs:2G__13935__delegate @ reload.cljs:53G__13935 @ reload.cljs:53goog.async.Deferred.fire_ @ deferred.js:649goog.async.Deferred.updateResult_ @ deferred.js:298goog.async.Deferred.continue_ @ deferred.js:282goog.async.Deferred.fire_ @ deferred.js:649goog.async.Deferred.updateResult_ @ deferred.js:298goog.async.Deferred.continue_ @ deferred.js:282goog.async.Deferred.fire_ @ deferred.js:649goog.async.Deferred.updateResult_ @ deferred.js:298goog.async.Deferred.continue_ @ deferred.js:282goog.async.Deferred.fire_ @ deferred.js:649goog.async.Deferred.updateResult_ @ deferred.js:298goog.async.Deferred.continue_ @ deferred.js:282goog.async.Deferred.fire_ @ deferred.js:649goog.async.Deferred.updateResult_ @ deferred.js:298goog.async.Deferred.callback @ deferred.js:326script.onload.script.onreadystatechange @ jsloader.js:190
core.cljs:3685 Handling re-frame event: [:init]
(defn ^:export init []
(.trace js/console "init called !!!!!!!!!!!!!!!")
(routes/define!)
(dispatch-sync [:init]))
but how do you know that there are side-effects? nothing else in our code does call this init fn directly
like for example consider an init function that calls (js/setInterval #(.log js/console "foo") 1000)
so the debugging process was: 1. use watch :verbose true
to see if the watch task was detecting changes for files that didn't really change, then 2. look in the js console at the boot reload debugging output, to see if the browser was getting multiple reload events, or if files were being reloaded that didn't really change, then 3. look at the init fn to see if that is somehow needs to clean up some state
but meanwhile, if that helps, its two files calling the init fn, the mainxxxx.cljs
within boot/cljs, and the second one calling init fn is the initxxxx.cljs
from adzerk/boot-reload
(defn ^:export init []
(.trace js/console "init called !!!!!!!!!!!!!!!"))
;(routes/define!))
;(dispatch-sync [:init]))