Fork me on GitHub

@seancorfield: thanks for the response! That makes sense. The main benefit for my use case was speeding up boot times during deployment, though this was not a mission critical necessity. What are the reasons you would recommend against AOT compilation (assuming this is a deployed app, not a library)?


If it's a full, self-contained app that you're building to deploy to production as an uberjar it's OK.


@seancorfield: thanks, that's certainly some food for thought! I think I'll need to do a bit more reading.


FWIW @zalky We do not use AOT even in production at World Singles. We use pure source uberjar deployments and start all of our processes with java ... -jar /path/to/the.jar -m our.entry.ns ...


Whilst AOT improves startup time, it makes no difference to performance once the app is running -- and since these are all server processes, we don't much care about startup time (esp. when the New Relic Agent is our biggest bottleneck as it instruments the thousands of classes that are typically part of a large Clojure program!).


Someone mentioned to me that yada goes from 45s to 4s when using aot, which was a bit of a jaw dropper.


Would isolating the frontend (cljs) from the backend (clj) be a good use case for pods? I'm thinking this might be a cool way to sort of contain each environment in its own "world"...thoughts?


did someone have this one on ubuntu: `java.lang.NoClassDefFoundError: clojure/lang/IFn java.lang.ClassNotFoundException: clojure.lang.IFn` I just installed it via github instructions an it throws this error on everything I run


@faxa can you check what boot -V says?


most likely you are running a pretty old version of Boot for some reason


@cjsauer I've done it before. It required some tweaks and hacks to existing tasks, but it did work. We stopped because it didn't turn out to be that useful, we never hit a conflict in practice, so the isolation of these two things was never beneficial, only confusing.


@dominicm indeed...I've been attempting to spike it out and it's certainly leading to nothing but headaches and confusing build code šŸ˜“


I have a feeling that I'm overlooking something obvious here, but I'm hoping that talking the problem out here will help. I'm having an issue with moving files in a fileset - in initially works, but then the fileset appears to reset or something after all tasks are run. I've worked it down to this reproducible test case:

(require '[boot.core :as boot])

(deftask foo->bar []
  (comp (fn [next-task]
          (fn [fileset]
            (let [next-fs (next-task fileset)]
              (println "post-mv")
              (boot.task-helpers/print-fileset next-fs)
              (Thread/sleep 20000)
        (fn [next-task]
          (fn [fileset]
            (let [next-fs (boot/commit! (boot/mv fileset "public/foo.txt" "public/bar.txt"))
                  foo (boot/tmp-get fileset "public/foo.txt")
                  bar (boot/tmp-get next-fs "public/bar.txt")]
              (println "mv")
              (println (.getPath (boot/tmp-file foo)))
              (println (.getPath (boot/tmp-file bar)))
              (Thread/sleep 20000)
              (next-task next-fs))))))


I rewrote it without the with-*-wrap macros just to make sure I wasn't missing something


the output and behavior I'm seeing is:

(20 second pause)
ā”œā”€ā”€ public
ā”‚   ā”œā”€ā”€ bar.txt
(20 second pause)


during the first 20 second pause, bar.txt exists, and foo.txt does not, as I would expect. During the second 20 second pause, bar.txt has gone away, and foo.txt is back, even though the printed-out fileset says that bar.txt is still there


As far as I can tell, the only thing that boot is doing in between the pauses (besides my printlns) is running sync-user-dirs! here:


I don't suppose anybody knows what is going on, and how I can move a file in a way that sticks?


I also get the same result when using (sift :move) - I can post code for that if it would help, but I don't want to preemptively flood the channel more than I already have.


@bhagany never faced that myself, weird..