This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-29
Channels
- # admin-announcements (4)
- # arachne (19)
- # aws-lambda (3)
- # beginners (10)
- # boot (166)
- # capetown (32)
- # carry (160)
- # cider (5)
- # cljs-dev (5)
- # cljs-edn (19)
- # cljsrn (1)
- # clojure (100)
- # clojure-belgium (2)
- # clojure-dev (8)
- # clojure-greece (13)
- # clojure-new-zealand (12)
- # clojure-poland (1)
- # clojure-russia (93)
- # clojure-sanfrancisco (2)
- # clojure-spec (133)
- # clojure-uk (52)
- # clojurescript (129)
- # cursive (32)
- # datomic (13)
- # defnpodcast (5)
- # devcards (6)
- # dirac (4)
- # emacs (12)
- # euroclojure (5)
- # events (2)
- # hoplon (19)
- # immutant (45)
- # keechma (17)
- # lein-figwheel (27)
- # off-topic (9)
- # om (30)
- # onyx (17)
- # other-languages (3)
- # planck (2)
- # proton (11)
- # re-frame (7)
- # reagent (4)
- # ring (8)
- # sim-testing (2)
- # spacemacs (4)
- # testing (2)
- # untangled (162)
- # utah-clojurians (1)
- # yada (80)
got it, thanks
i'll try booting
Just updated to the master of Emacs Live and the Boot support has gotten much, much better: it now runs boot … repl -s wait
with the correct dependencies and middleware for CIDER and refactor-nrepl automatically! No more hacky Boot file stuff to add all of that!
Unfortunately there’s a tiny bug in the CIDER conf.el file that prevents cljr-refactor from loading (I submitted a PR).
i've managed to peek into the dependencies of a pod for the 1st time!
boot -d tailrecursion/boot-static:0.0.1-SNAPSHOT serve -p 8000 show -P boot-static -d
in retrospect it's understandable but it took a while until i really understood this is what i have to do... i wish i had this being explained to me earlier on. but where would i expect to see this documented?
of course micha and the existing documentation did a great job explaining the different bits and pieces of all this but it was still non-obvious to combine all this
Ya, sometimes Boot is almost too flexible and it’s hard to know where to go to read up on a problem you’re trying to solve! 🙂
i haven't found explanations about the following for example:
1. the -d some/dependency:1.1.1
option is doing an implicit (require '[dep.ns :refer :all])
2. to have boot show -l
access pods of other tasks i should actually call the task even if im not interested in it's side-effect
I've seen it said that one can pull in a dependency with boot during a repl session without having to restart the session, how does that work?
@onetom: Not sure what you mean by 1. there?
Re: 2. Yes, since show -l
shows "active pods" you would need to run a task to get its pods up and running (and active).
can someone explain something that i read on the boot-clj site? this part:
> artifacts can never be stale. there is no clean task
not sure i understand how / why that happens in boot, but not in leiningen?
@kgzm: you can call boot.core/set-env!
inside a repl
@biscuitpants: leinigen writes to target potentially leaving files from previous builds
In some cases these files are also used for incremental compilation etc.
In boot the state is fully represented through the fileset and so this problem can easily be avoided by detecting which files are missing from the fileset and deleting them
(There are probably more details to this but I hope this gives an idea)
ah i see, thank you @martinklepsch that makes a lot of sense
if I were to run a task such as npm install
inside a dosh
, where a bunch of files are added — how do I get those files added into the fileset?
rerunning core/input-files fileset
just provides the set without the newly created files… do I need to somehow npm install into the result of the tmp-dir!
, in which case they will be detected by boot? can I manually add them somehow with standard fileio? such as:
;; move files into fileset
(doseq [f files]
(let [in-file (boot/tmp-file f)
target (io/file tmp (boot/tmp-path f))]
(io/make-parents target)
(io/copy in-file target)))
btw @micha I found a way to do npm inside boot (I think) by simply including a package.json as a resource, and running a dosh with bindings *sh-dir*
set to wherever the package.json is declared.
(deftask foo
[]
(let [tmp (tmp-dir!)]
(with-pre-wrap [fs]
(dosh "doit" "--output-dir" (.getPath tmp))
(-> fs (add-resource tmp) commit!))))
at least on the first run through all the files show up, all the installed stuff can be touched via normal npm operations
it’s after a file changes things bork because they cannot find anything inside node_modules — i.e. it’s not in the fileset (I think)
i see, i was kind of hacking the system, changing sh-dir to get the tmp path to the file:
(defn npm-path []
(.getPath (.getParentFile (io/file (io/resource "lwhorton/boot_stylus/package.json")))))
and then running with:
(binding [u/*sh-dir* (npm-path)]
(do
(u/dosh "npm" "install”)
i see.. i should be able to manually put the package.json into the fileset at tmp
, then do the above to install everything else (using package.json) into tmp
(deftask foo
[]
(let [tmp (tmp-dir!)]
(spit (io/file tmp "package.json") package-json)
(with-pre-wrap [fs]
(binding [*sh-dir* (.getPath tmp)]
(dosh "npm" "install"))
(-> fs (add-resource tmp) commit!))))
now the task is a ‘self contained’ npm environment where the only external dependency is node.. tasks that need modules install them on the fly, and cache them so re-run is quick
i’m using cache-dir to remember the css-modules hash, but just a clojure’d atom installed (atom false)
* to remember if i need to install or not
i’m making some standalone boot scripts as in: https://github.com/boot-clj/boot/wiki/Scripts. is there a way to get at the path of the script? i want to be able to execute stuff from the same dir as the script, even if the script is executed from another directory
awesome did not know that
did something happen to boot’s uberjar performance? i just cloned and ran https://github.com/micha/boot-uberjar-perf and this is what i got:
15:27 $ time lein uberjar
Compiling foo.bar
Created /Users/esp/Code/contrib/boot-uberjar-perf/target/bar-0.1.0-SNAPSHOT.jar
Created /Users/esp/Code/contrib/boot-uberjar-perf/target/bar-0.1.0-SNAPSHOT-standalone.jar
real 0m7.515s
user 0m7.670s
sys 0m1.841s
✔ ~/Code/contrib/boot-uberjar-perf [master|✔]
15:32 $ time boot uberjar
Adding uberjar entries...
Compiling 1/1 foo.bar...
Writing pom.xml and pom.properties...
Writing project.jar...
Sifting output files...
Writing target dir(s)...
real 0m47.499s
user 0m10.615s
sys 0m5.352s
@esp1: Which Boot version this is? I think there was improvements in some version
it’s referencing BOOT_VERSION=2.5.0-SNAPSHOT in the boot.properties file for that project. i’ll see if it makes any difference to change that to 2.6.0
Also, does your target dir contain only the uberjar or all the files?
Okay, then the difference wont be caused by writing the other files to disk
Perhaps I remember incorrectly and it was not fixed yet
well, according to this it was: https://github.com/boot-clj/boot/issues/94
also the readme for https://github.com/micha/boot-uberjar-perf shows similar timings for lein and boot
@esp1: this is what i get, changing boot.properties to point to the latest versions of boot and clojure:
ok that took 59 secs, but i had another process running so let me wait until that finishes and i’ll try again. i may try rebooting my machine in a bit to see if that helps
16:08 $ time boot -P uberjar
Adding uberjar entries...
Compiling 1/1 foo.bar...
Writing pom.xml and pom.properties...
Writing project.jar...
Sifting output files...
Writing target dir(s)...
real 0m50.957s
user 0m10.430s
sys 0m5.244s
btw. micha, I finally ordered t460s to replace x220, I had enough of the 1366x768 display 😄
Yeah x220 keyboard is super but as I doubt there will ever be new laptops with same kind of keyboards I decided I have to adapt to new keyboard sometime
if it’s fast for you i guess we can chalk it up to an osx filesystem thing, altho lein runs much faster (8 secs just now)
i did change the boot.properties to use clojure 1.8 and boot 2.6, dunno if that makes any difference
ups we am thrashing the channel 🙂
@richiardiandrea: so is it just threads that need to be killed?
at the moment I am using the function in that PR
core async stuff, and db related shutdowns
but i am assuming that the functions that are called, like the datomic shutdown one, are just stopping threads
yes it is killing threads basically and ExecutorServices
so there is this: https://docs.oracle.com/javase/7/docs/api/java/lang/management/ThreadMXBean.html
get all the threads and kill them
thanks, it looks easier than tracking stuff one by one...
in my case I am executing tests so every watch
tick I can kill them all I guess
I have to read a couple of times more this guy: https://github.com/projectodd/shimdandy#preventing-memory-leaks
so it looks like a shutdown-agents
would suffice...it would be great to understand why it is not
because we are calling .close
on the shim already
but the bigger concern is the contextClassLoader for those threads will hold a reference to the shim's classloader, which will prevent any classes loaded in the shim from being unloaded.
so the threads created in the shim hold references to the shim
if you start a non-daemon thread, then the pod can't be GC until that thread is stopped
(I was talking about this problem in #C085AR8RE this morning)
i think the root of the problem is that threads are treated specially by the garbage collector
they can't be collected until they have stopped, even if nothing holds references to them
yeah, true
I am working on the reaper 😉
If I have a build.boot
file in one folder and for "reasons" I want to have (effectively) the identical build.boot
file in another folder, is there a way to have a sort of "shim" Boot file in one place that just sort of "includes" the other one?
Maybe some sort of load script code perhaps?
@seancorfield: sure, you can use clojure.core/load-file
in one of them
Cool. Glad it’s that simple.
No I cannot come up with a solid solution..