This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (7)
- # beginners (30)
- # boot (181)
- # cbus (1)
- # cider (55)
- # cljs-dev (8)
- # clojure (104)
- # clojure-dev (3)
- # clojure-japan (1)
- # clojure-russia (70)
- # clojurescript (139)
- # core-logic (4)
- # cursive (23)
- # datomic (25)
- # devcards (10)
- # events (11)
- # funcool (1)
- # hoplon (39)
- # jobs (10)
- # ldnclj (19)
- # lein-figwheel (21)
- # off-topic (4)
- # om (174)
- # onyx (46)
- # re-frame (25)
- # reagent (3)
- # yada (7)
No didn't go far debugging it at all. I'm pretty sure my code is passing it in, though. Hunch is that the key needs to be nested in something else (`:compiler-options` maybe?).
@alqvist: only files in
:resource-paths end up in target or other packages like jars.
You can learn more about the roles files can have in the fileset here: https://github.com/boot-clj/boot/wiki/Filesets#fileset-components
@alqvist: Bootlaces will not fix that issue but rather would have been a cause under some circumstances.
@alqvist: just to clarify are your own clj files included or the clj files of your dependencies and you want to remove those?
@alqvist: that’s what an uberjar is supposed to do Do you want to include compiled java classes instead? Maybe try using
(aot :all true) after the
(uber) task. I’m not sure if this will work though
I suppose you could try aot :all where it was before, I think that will compile all namespaces you depend on. Not sure if
(uber) is still required then actually. Would be interesting to try
@martinklepsch: `(aot :all) still fails on compile nr 66 or something. One of the asyncs
I think you have to set your BOOT_VERSION file in your ~/.boot/boot.properties file. Then run the script, https://github.com/boot-clj/boot-bin/releases/download/2.4.2/boot.sh
@pandeiro: the binary has been moved there because effectively with 2.4.0 there has been a new binary that should rarely require updates
we may release a bugfix to boot.sh from time to time, but new versions will always work with it
https://github.com/boot-clj/boot/issues/275 — should this be moved to boot-bin?
So I am studying pods and how they work. Why is the first thing App/newPod does is seal the app classloader? What advantage does a sealed classloader have?
@chrisn: I think the point of sealing is that no other things can be added to the classloader after the pod is created
@chrisn: yes, what @martinklepsch said: boot uses
dynapath to mark classloaders as immutable which is really only an opt-in thing, but it is there to prevent programs from leaking clojure into classloaders that will pollute all the other pods
if a program doesn't modify the classloader via dynapath then the seal-classloader thing won't have any effect
The thing is that a new URLClassLoader is created that is that pod's specific classloader. How would a program pollute another pod?
a program that walks the classloader chain and uses reflection to add things to a classloader higher up in the chain
all the other pods, the worker pod, the aether pod, and any pods that are created by tasks or by the user will be created with all the dependencies they will need specified at construct time
the worker pod is a pod containing all the various dependencies that boot needs for its built-in tasks
but since boot ships with like 15 tasks that are all maintained together it simplifies things to let them all share the worker pod
so boot.jar will extract the aether uberjar from its own resources and write it out to a cache dir
This entire class isolation things is pretty darn interesting. Leiningen does a similar process which we have seen several pretty irritating issues with and we are using onyx which has peers and having dynamic pods for those would be very useful.
Right. And it uses a somewhat bugprone system of having each plugin mangle the project and eval-in-project
tasks don't load their own dependencies into a classloader that has any other task's dependencies
How does the pod pool work? It seems that reusing a pod would be tough unless you unloaded its classes.
so like suppose you want to run your tests in a fresh pod each time you build your project
so there are always N pods waiting int he queue with clojure already loaded and ready to go
when you do
(pool :refresh) you get a fresh new pod, and the previous head of the queue is disposed of
and it comes with various library functions that are helpful for making your build program
You could imagine a sort of boot daemon that would just always keep some pods running.
Really mitigating the startup time would go a long way towards using clojure as a scripting language.
And what you did was create a new core, create a new worker pod, and run the show task?
it's pretty important to isolate that in a pod because there are some really hairy deps there
not great transitive dependencies because they pull in all kinds of ancient apache http client nonsense
the functions in the pod that will be called to do the work take file paths as arguments
and they write the results of their work to some directory whose path is provided in the arguments
and when the work in the pod is finished the task will add the contents of the directory where the stuff in the pod wrote its results to to the fileset
OK, but is the task itself running in its own pod? And it has a child hoplon pod, correct?
it's important for all the tasks to run in the same thread, because the fileset is an abstraction that's coupled to the JVM classpath
the relationship of pods to the fileset is sort of like transients to persistent collections
(consider the crazy mutation of the classpath done by google closure compiler or whatever)
when all the crazy mutation is finished the task extracts the results and atomically adds them to the fileset and the main classpath