This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
is there a boot task equivalent of lein check
?
I guess I’m imagining that to write one I just need to call analyze on the fileset
(set-env! :source-paths #{"src"}
:dependencies '[[jonase/eastwood "0.2.1"]])
(require '[boot.pod :as pod])
(require '[eastwood.lint])
(def pod-env
(assoc pod/env :dependencies '[[jonase/eastwood "0.2.1"]]))
(defn eastwood-files [pod files]
(doseq [f files
:let [in-file (tmp-file f)]]
(info "Loading %s\n" (pr-str in-file))
(info "%s\n" (eastwood.lint/lint {:source-paths [(tmp-dir f)]}))
#_(pod/with-call-in pod
(slurp ~in-file))))
(deftask eastwood
"Lint checks your code"
[]
(let [pod (pod/make-pod pod-env)]
(with-pre-wrap fileset
(eastwood-files pod (by-ext [".clj"] (input-files fileset)))
fileset)))
Hmmm this is almost doing what I want it to already… boot is awesome so far, really love the solid design - feels comprehensive, concise and like it is trying to help me.@timothypratley: glad to hear
@timothypratley: there is a new function in boot master that uses clojure.tools.namespace.find to get a list of all namespaces in the fileset
which might be perfect for what you want to do (i.e. compatible with .cljc files, not confused by data_readers.clj files, etc)
oooOOOoo great! thank you.
I’m consistently seeing OOM errors when using boot, even after bumping the heap size to 4g. This is on what I would have expected to not be a memory intensive project. Has anyone else seen this?
I think heap? Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread “main"
sending change event
Syncing project dirs to temp dirs...
Acquired java.util.concurrent.Semaphore@be83fed[Permits = 0]...
Released java.util.concurrent.Semaphore@be83fed[Permits = 1]...
Syncing project dirs to temp dirs...
Acquired java.util.concurrent.Semaphore@be83fed[Permits = 0]...
Released java.util.concurrent.Semaphore@be83fed[Permits = 1]...
Syncing project dirs to temp dirs...
Acquired java.util.concurrent.Semaphore@be83fed[Permits = 0]...
Released java.util.concurrent.Semaphore@be83fed[Permits = 1]...
Syncing project dirs to temp dirs...
Acquired java.util.concurrent.Semaphore@be83fed[Permits = 0]...
Released java.util.concurrent.Semaphore@be83fed[Permits = 1]...
Syncing project dirs to temp dirs...
Acquired java.util.concurrent.Semaphore@be83fed[Permits = 0]...
Released java.util.concurrent.Semaphore@be83fed[Permits = 1]...
Syncing project dirs to temp dirs...
Acquired java.util.concurrent.Semaphore@be83fed[Permits = 0]...
Released java.util.concurrent.Semaphore@be83fed[Permits = 1]...
Acquired java.util.concurrent.Semaphore@be83fed[Permits = 0]...
Released java.util.concurrent.Semaphore@be83fed[Permits = 1]…
running with BOOT_JAVA_COMMAND=/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java BOOT_JVM_OPTIONS="-Xmx4g -Xms4g”
uname -msrv
Darwin 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64
❯ boot -V
#
#Fri Jun 26 11:23:36 EDT 2015
BOOT_CLOJURE_VERSION=1.6.0
BOOT_VERSION=2.1.2
❯ java -version
java version "1.7.0_76"
Java(TM) SE Runtime Environment (build 1.7.0_76-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)
Trying to understand more deeply what "Artifacts can never be stale.” means… it seems like boot is a pipeline for fileset, which you can watch with watch
but the behavior of watch
is to reprocess the entire fileset, so does this mean that artifacts can never be stale because they are always built (in their own little gitish tmp directories), or is there any concept of only building the things that changed? I think the answer to building deltas is I’d need to make a custom watch task that filters the fileset down to only the changed files, and at that point I would not need a clean, but I might need to stop and restart if my build process was not strictly able to work from deltas.
ie: the ‘never stale’ property comes from always building fresh