Fork me on GitHub
#boot
<
2016-07-13
>
x1n4u11:07:42

*probably

alandipert13:07:58

@x1n4u: the problem is map is lazy, try with:

(defn greet-persons [persons]
  (doall (map #(println "Hello, " %) persons)))

alandipert13:07:49

for things like this i tend to use doseq which is for explicit side effect, like:

(defn greet-persons [persons]
  (doseq [p persons]
    (println "Hello, " p)))

hrathod14:07:37

is there a way to control the colors used in boot repl?

alandipert14:07:25

you can turn them off via boot -C repl

alandipert14:07:31

other than that, none i'm aware of

alandipert14:07:58

boot -C also turns off colorized stack traces

hrathod14:07:31

right, it seems all or nothing. I was hoping to find a way to keep colors but have it work with my terminal background color

hrathod14:07:44

thanks for the confirmation, @alandipert

alandipert14:07:12

your terminal emulator might support remapping the codes to different colors

hrathod14:07:48

true, I could create a different 'boot repl' profile for iterm

micha15:07:46

@hrathod: it's using your terminal's color palette

micha15:07:26

it just uses the ANSI codes, which doesn't support actual specification of color values

hrathod16:07:18

@micha: Thanks for the clarification.

gerstree18:07:10

When I do (boot (sift :include #{#"logback.xml"}) (show :fileset true)) the output show a fileset with exactly one file as I expect.

gerstree18:07:38

How can I implement a task that returns a fileset with only the files it created?

gerstree18:07:07

I have this so far:

(deftask cf-template
  "Generate a cloudformation template"
  [t template VALUE kw "The template to generate (one of [infrastructure | environment])"]
  (let [tmp-dir (tmp-dir!)
        outfile (io/file tmp-dir "environment.json")
        _ (info (str "look for " outfile))
        cf-template (json-generate (eval (:definition (template cf-templates))) {:pretty true})]
    (fn middleware
      [next-handler]
      (fn handler
        [fileset]
        (spit outfile cf-template)
        (let [new-fileset (add-resource fileset outfile)]
          (commit! new-fileset)
          (next-handler (fileset-added fileset new-fileset)))))))

gerstree18:07:35

The result however is a fileset with only an empty directory

seancorfield18:07:44

Quick Q: what is the minimum version of Clojure that Boot supports in a project?

seancorfield18:07:04

It seems to be Clojure 1.6.0. When I try BOOT_CLOJURE_VERSION=1.5.1 boot repl, I don’t get anything … it just silently goes back to the command prompt.

alandipert18:07:32

although i don't know exactly why, just that it's what we started with

seancorfield18:07:23

I guess I was just surprised at the "silent treatment" I got from it. An error would be better 🙂

alandipert18:07:17

i agree, that's super weird

seancorfield18:07:10

It does have a non-zero exit status (254) but prints no message...

seancorfield18:07:07

(hmm, that’s -2 as an exit status right?)

seancorfield18:07:02

So it’s likely exiting here (line 402) with that status and not printing any exception https://github.com/boot-clj/boot/blob/master/boot/base/src/main/java/boot/App.java#L388-L402

seancorfield18:07:49

So basically Boot is swallowing the exception 😐

seancorfield18:07:14

If I want to build a new version of Boot to test a modification to Boot.App, how would I go about that?

seancorfield19:07:45

Figured it out… So here’s the actual exception. Not sure what could be done to make the messaging better or whether it could be made to work with pre-1.6.0 Clojure:

Boot failed to start:
java.lang.NoSuchMethodError: clojure.lang.Reflector.invokeNoArgInstanceMember(Ljava/lang/Object;Ljava/lang/String;Z)Ljava/lang/Object;
	at boot.pod$eval_in_STAR_.invoke(pod.clj:440)
	at boot.main$_main.invoke(main.clj:148)
	at clojure.lang.Var.invoke(Var.java:427)
	at org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke(ClojureRuntimeShimImpl.java:159)
	at org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke(ClojureRuntimeShimImpl.java:150)
	at boot.App.runBoot(App.java:399)
	at boot.App.main(App.java:491)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at Boot.main(Boot.java:258)

alandipert19:07:11

i like the idea of the exception being visible, less excited about trying to print a certain msg

alandipert19:07:21

the exception itself when googled yields relevant results

seancorfield19:07:09

I agree that Googling that exception yields relevant results (although not perhaps immediately obvious results) that should allow a user to deduce that this is a Clojure version compatibility issue.

seancorfield19:07:27

Do the Boot docs clearly state 1.6.0 is the minimum supported version?

seancorfield19:07:51

I can’t find anything about minimum Clojure version. I’ll edit a couple of the wiki pages.

x1n4u21:07:40

@alandipert: thanks, and soory for the latency 😁

mattly21:07:42

speaking of specifying the clojure version, is the per-project boot.properties file supposed to take precedence over ~/.boot/boot.properties ?

mattly21:07:15

my project has set the clojure version to 1.8.0 in both build.boot’s deps and the boot.properties, but it’s still running under 1.7

seancorfield22:07:01

@mattly: I just tested that — local boot.properties file in a project — and it successfully overrode my default Clojure version. What’s in your boot.properties file?