Fork me on GitHub
#boot
<
2015-06-26
>
timothypratley03:06:01

is there a boot task equivalent of lein check?

timothypratley04:06:12

I guess I’m imagining that to write one I just need to call analyze on the fileset

timothypratley06:06:16

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

alandipert12:06:25

@timothypratley: glad to hear metal

micha13:06:33

@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

micha13:06:01

which might be perfect for what you want to do (i.e. compatible with .cljc files, not confused by data_readers.clj files, etc)

micha13:06:42

the function is in boot.core namespace, you can probably just copy it into your task

micha13:06:07

it uses ctnf in a worker pod to avoid the tools.namespace dependency

timothypratley13:06:44

oooOOOoo great! thank you.

micha13:06:22

glad to hear you're enjoying boot!

alejandro15:06:07

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?

micha15:06:42

hi alejandro

micha15:06:54

are the OOM heap or permgen?

alejandro15:06:17

I think heap? Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread “main"

micha15:06:05

can you paste the stack trace please?

alejandro15:06:33

I don’t have one being printed...

micha15:06:46

perhaps do like boot -vv ...

micha15:06:54

that will bump verbosity to the max

micha15:06:57

also can you please paste the output from java -version and boot -V

alejandro15:06:27

still no stacktrace, but `

alejandro15:06:36

sending change event
Syncing project dirs to temp dirs...
Acquired [email protected][Permits = 0]...
Released [email protected][Permits = 1]...
Syncing project dirs to temp dirs...
Acquired [email protected][Permits = 0]...
Released [email protected][Permits = 1]...
Syncing project dirs to temp dirs...
Acquired [email protected][Permits = 0]...
Released [email protected][Permits = 1]...
Syncing project dirs to temp dirs...
Acquired [email protected][Permits = 0]...
Released [email protected][Permits = 1]...
Syncing project dirs to temp dirs...
Acquired [email protected][Permits = 0]...
Released [email protected][Permits = 1]...
Syncing project dirs to temp dirs...
Acquired [email protected][Permits = 0]...
Released [email protected][Permits = 1]...
Acquired [email protected][Permits = 0]...
Released [email protected][Permits = 1]…

micha15:06:20

i haven't seen this kind of problem before

micha15:06:37

which operating system?

alejandro15:06:04

running with BOOT_JAVA_COMMAND=/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java BOOT_JVM_OPTIONS="-Xmx4g -Xms4g”

alejandro15:06:24

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

alejandro15:06:43

❯ boot -V
#
#Fri Jun 26 11:23:36 EDT 2015
BOOT_CLOJURE_VERSION=1.6.0
BOOT_VERSION=2.1.2

micha15:06:11

you built from master, i take it?

alejandro15:06:20

don’t think so

micha15:06:22

the BOOT_JAVA_COMMAND env var isn't in the release yet

alejandro15:06:33

ah, so maybe that’s not doing anything

alejandro15:06:49

I just did a boot -u yesterday from one of the early RC’s I believe

micha15:06:54

you can check that by looking at boot.sh in vim or less

micha15:06:23

if you see exec ${BOOT_JAVA_COMMAND:-java} ... then you're good to go

alejandro15:06:43

I see

#!/usr/bin/env bash
java $BOOT_JVM_OPTIONS -jar $0 "[email protected]"
exit

micha15:06:57

yeah so that won't be using the env var

alejandro15:06:12

in that case

alejandro15:06:17

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

micha15:06:35

yeah that should be okay, i use 1.7 mostly

micha15:06:53

can you do this:

micha15:06:02

boot -BP repl

micha15:06:07

and get a repl that works?

micha15:06:28

the -BP tells boot to ignore build.boot and profile.boot

micha15:06:46

so now go to your project directory

micha15:06:49

and do something like

micha15:06:10

boot -r src jar

micha15:06:17

where src is a directory with some files in it

micha15:06:31

you should get a jar file in target

micha15:06:38

do yo uget OOM?

micha15:06:55

oops i mean

micha15:06:02

boot -BPr src jar

alejandro15:06:11

nope, looks like it worked without the BP

alejandro15:06:19

got project.jar

micha15:06:26

so it must be something in your build.boot program

micha15:06:38

you can bisect the problem now by commenting things out

alejandro15:06:43

okay, I’ll try to dig through that

alejandro15:06:45

thanks for your help!

micha15:06:54

np! let me know how it goes simple_smile

micha15:06:20

oh, are you using the ramdisk trick by any chance?

micha15:06:36

alejandro: ^^

timothypratley22:06:34

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.

timothypratley22:06:31

ie: the ‘never stale’ property comes from always building fresh