Fork me on GitHub
#boot
<
2016-09-18
>
richiardiandrea00:09:19

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

richiardiandrea00:09:37

it should be visible to pods

richiardiandrea00:09:03

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

arohner01:09:43

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

alandipert02:09:56

@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

coyotespike15:09:31

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.

coyotespike15:09:16

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

coyotespike15:09:30

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

anmonteiro15:09:57

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

coyotespike15:09:14

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.

anmonteiro15:09:14

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

coyotespike15:09:51

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/

coyotespike15:09:13

I'm a little surprised there's not a similarly direct way of setting these variables for Boot.

martinklepsch15:09:49

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

jellea15:09:55

@martinklepsch thanks for asking! 🙂

coyotespike16:09:54

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

coyotespike16:09:03

And then of course I put config.edn in my .gitignore. This seems hacky, but fine for "12-Factor App" purposes?

arohner18:09:25

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?

martinklepsch18:09:26

What do you mean by fully resolved?

arohner18:09:21

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

arohner18:09:36

basically, I want to assert that BOOT_CLOJURE_VERSION = the clojure version in my build.boot dependencies

martinklepsch18:09:10

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

arohner18:09:44

oh yeah, clojure-version works

arohner18:09:05

I see boot.App/getClojureName and getBootVersion. slightly surprised there’s no getClojureVersion

pesterhazy18:09:57

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

pesterhazy18:09:11

on 1.9.0-alpha12 if it matters

arohner18:09:43

are you in a namespace without clojure.core referred?

pesterhazy18:09:50

no, clojure.core is included normally

pesterhazy18:09:24

this is the code:

(defmulti print-event :type [e])

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

pesterhazy18:09:33

If I remove these two lines it works

anmonteiro18:09:10

@pesterhazy doesn’t look like valid defmulti syntax

pesterhazy18:09:42

the [e] part is unnecessary

pesterhazy18:09:04

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

pesterhazy19:09:22

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

pesterhazy19:09:33

perhaps CIDER's middleware interfering

pesterhazy19:09:48

yeah it's CIDER's middleware

martinklepsch19:09:41

inf-clojure 👌

michael.heuberger22:09:29

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

micha22:09:24

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

micha22:09:31

and not boot -v watch ...

michael.heuberger22:09:09

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

micha22:09:41

i was referring to the watch task specifically before

micha22:09:54

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

michael.heuberger22:09:08

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

micha22:09:11

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

michael.heuberger22:09:15

our deftask calls this run task

micha22:09:32

right so you can add :verbose true option to watch

micha22:09:00

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

michael.heuberger22:09:11

aye, doing right now ...

micha22:09:29

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

micha22:09:42

or at the command line via boot watch -h

michael.heuberger22:09:10

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

michael.heuberger22:09:13

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

michael.heuberger22:09:46

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

micha22:09:12

the watch task prints only one file changed?

micha22:09:23

with verbose output

michael.heuberger22:09:45

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

michael.heuberger22:09:57

yet, init-fns of boot-reload called twice

micha22:09:17

and you're using :none optimizations, right?

michael.heuberger22:09:39

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

micha22:09:54

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

micha22:09:05

in the js console

michael.heuberger22:09:41

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

michael.heuberger22:09:02

some js and map files here

micha22:09:17

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

micha22:09:25

so those files will be evaluated

micha22:09:48

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

micha22:09:23

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

michael.heuberger22:09:50

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

micha22:09:05

every js file has a corresponding cljs file

michael.heuberger22:09:29

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]

micha22:09:33

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

michael.heuberger22:09:54

and the second one

michael.heuberger22:09:03

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]

michael.heuberger22:09:22

second one called 20 ms after the first init call

micha22:09:14

sounds like something in re frame

micha22:09:25

has its own handler

michael.heuberger22:09:49

this here is our init funtion

michael.heuberger22:09:50

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

micha22:09:24

so i see side effecting functions

micha22:09:41

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

michael.heuberger22:09:58

good question - should it be idempotent?

micha22:09:13

well not exactly idempotent

micha22:09:16

but almost

michael.heuberger22:09:50

but how do you know that there are side-effects? nothing else in our code does call this init fn directly

micha22:09:56

like for example consider an init function that calls (js/setInterval #(.log js/console "foo") 1000)

micha22:09:13

when you reload that init fn will run again

micha22:09:26

but nothing is cleaning up that setInterval handler

micha22:09:39

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

michael.heuberger22:09:44

ah, could be the case

michael.heuberger22:09:54

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

micha22:09:04

it depends on what it's doing

micha22:09:20

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

micha22:09:22

in the code

micha22:09:32

perhaps try commenting things out in your init fn

micha22:09:52

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

michael.heuberger22:09:07

ok, will do, thanks for your help

micha22:09:26

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

michael.heuberger22:09:27

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

micha22:09:20

that sounds like a likely issue

michael.heuberger22:09:54

i have commented out all code lines, still called twice

micha22:09:55

how are those tasks configured?

michael.heuberger22:09:58

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

michael.heuberger22:09:07

still called twice, no app code processed here