Fork me on GitHub
qqq00:12:40 states:

BOOT_JVM_OPTIONS="-Djava.library.path=/usr/local/cuda/lib64 -XX:-OmitStackTraceInFastThrow"
I get error: `Stack trace of root exception is empty; this is likely due to a JVM optimization that can be disabled with -XX:-OmitStackTraceInFastThrow. ` but I already ahve taht in BOOT_JVM_OPTIONS


qqq: Clojure 1.9.0 final is out now 🙂 Maybe that is already enough to give you a more helpful error?


Maybe someone could help me with my very weird exception I get?


there is something I don't understand ...


I start a repl server with boot repl -s wait in my shell


when I do boot repl -c -e '(println "hello")' in another shell, it prints hello


but when I create a task

(deftask connect
  (repl :client true
        :eval "(println \"hello\")"))


and start it with boot connect, I doesn't print hello


I try to finish the build.boot for my web app, but it's so complex


Does anyone have a good 10 minute overview of boot? I have a coworker that’s done some magical stuff with it but I don’t really understand what’s going on.


@g.albacarys you could gist it and ask specific questions


I mostly just want a high level overview of what’s going on, like the moron’s guide to boot 😄


Well the wiki is probably a good start:


There are pages on the various concepts like Fileset, Pods, Tasks etc


@fmind try this

(deftask connect
  (repl :client true
        :eval '(println "hello")))


admittedly the lack of an error kind of sucks


@martinklepsch it works 🙂 thanks


I’d like to add a warning when :eval is passed a string in Clojure code, any suggestions on this message?

When passing :eval to the repl task in your build.boot, use a quoted form instead of a string


Hi all: I'm working on a boot based web-app. The environment is set up in a way that allows me to develop and deploy it directly, but I would also like to be able to use it as a basis for derived apps that would extend the core tech. It seems there would be two approaches to this: 1) fork the repo, and use standard distributed git workflows to merge features between the core and derived apps 2) package the core app as a library to be consumed by other projects The first would seem to make it pretty trivial to merge features back and forth between the different forks, but would eliminate the distinction between upstream and downstream. The second would maintain a very clear distinction about where features are coming from to make a coherent system, but makes integrated development a little more cumbersome. I'm wondering if folks have had experience with deriving one app from another, and what approach they used to do integrated development (either the first or second approach above, or some third approach).


Apologies, when I started my question, it was more boot specific, but then it became more general. I suppose I should post it to the clojure channel, but feedback is welcome nevertheless.


@zalky If you package it as a library there are ways to make it available to your derived projects


@zalky In Boot and Leiningen there is this concept of checkout dependencies — if you haven’t heard of them I suggest you read this:


in Boot you can then use the :checkouts environment key as described here:


There are some differences to how this works in Leiningen and Boot but the result is basically the same


@martinklepsch: I had not encountered checkout dependencies, that looks super helpful, I will read up. Thanks!