@arohner If I understand correctly, I think you can just use binding before calling the repl task...

it should be visible to pods

or at least is what I was doing in boot.parallel

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).

How could I put the :http-port in a config file instead?

@coyotespike https://github.com/weavejester/environ#environ

I think you can have a .boot-env file in your classpath

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.

@coyotespike ah that’s right. hrm, so the other suggestion is Java properties

https://github.com/weavejester/environ/issues/42

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

@martinklepsch thanks for asking! 🙂

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)
      {})))

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?

What do you mean by fully resolved?

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

I see.

Maybe like here? https://github.com/boot-clj/boot/blob/85b0e6786845771a59b9e318b8b60414db0421db/boot/pod/src/boot/pod.clj#L859

On mobile right now so can't check....

oh yeah, clojure-version works

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

on 1.9.0-alpha12 if it matters

are you in a namespace without clojure.core referred?

no, clojure.core is included normally

this is the code:

(defmulti print-event :type [e])

(defmethod print-event :default [e]
  (prn e))

If I remove these two lines it works

@pesterhazy doesn’t look like valid defmulti syntax

the [e] part is unnecessary

that's it

however, the error message did not ... match the error

yeah, weird

I've seen these kinds of errors before (also relating to intern)

perhaps CIDER's middleware interfering

yeah it's CIDER's middleware

inf-clojure 👌

@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?

@michael.heuberger you're doing like boot watch -v ... right?

and not boot -v watch ...

hmmm, we have our own custom task like (deftask dev … and i am calling it like dev -v dev -o none

i was referring to the watch task specifically before

that task itself has a -v,--verbose option

(deftask run []
  (comp
    (watch)
    (cljs-devtools)
    (reload)
    (build)))

it will print a message showing the files it thinks have changed

our deftask calls this run task

right so you can add :verbose true option to watch

(deftask run []
  (comp
    (watch :verbose true)
    ...

aye, doing right now ...

you can see this in the repl with (doc watch) by the way

or at the command line via boot watch -h

sure, the problem was that i thought the -v option will be passed down to all calling tasks/functions

ah

ok, the verbose option doesn’t help me with my reload issue

its :init-fns is still being called twice here when only one file has changed

the watch task prints only one file changed?

yes, only one

with verbose output

yes

◉ :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

yet, init-fns of boot-reload called twice

and you're using :none optimizations, right?

yes

interestingly, this does not happen when optimizations are set to simple

in the browser you should be able to see a list of changed files that will be reloaded

in the js console

yep, i see them when i expand the “Reload” line

some js and map files here

the js files are the ones you're interested in for this issue

so those files will be evaluated

if they contain top level forms that produce side effects then those side effects will happen

but it doesn't appear to be a boot issue, it seems to be something in the code

hmmm this will be very tricky to investigate since they are scrambled

every js file has a corresponding cljs file

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]

in chrome you can see them in the devtools via source maps

and the second one

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]

second one called 20 ms after the first init call

sounds like something in re frame

has its own handler

?

this here is our init funtion

(defn ^:export init []
  (.trace js/console "init called !!!!!!!!!!!!!!!")
  (routes/define!)
  (dispatch-sync [:init]))

so i see side effecting functions

do those need to be cleaned up? is that init fn idempotent?

good question - should it be idempotent?

well not exactly idempotent

but almost

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)

when you reload that init fn will run again

but nothing is cleaning up that setInterval handler

so you'll get more and more "foo"s printing

ah, could be the case

how would you recommend to make it idempotent? with a flag?

it depends on what it's doing

but that's the kind of thing i'd be on the lookout for

in the code

perhaps try commenting things out in your init fn

bisect the problem until you narrow down the cause of the double eval

ok, will do, thanks for your help

sure np!

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

correct

will do that now

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

that sounds like a likely issue

yes

i have commented out all code lines, still called twice

how are those tasks configured?

(defn ^:export init []
  (.trace js/console "init called !!!!!!!!!!!!!!!"))
  ;(routes/define!))
  ;(dispatch-sync [:init]))

still called twice, no app code processed here