This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-05
Channels
- # beginners (23)
- # boot (84)
- # braid-chat (2)
- # bristol-clojurians (1)
- # cider (53)
- # cljs-dev (34)
- # cljsrn (13)
- # clojure (138)
- # clojure-dusseldorf (5)
- # clojure-italy (1)
- # clojure-russia (164)
- # clojure-uk (41)
- # clojurescript (80)
- # clr (2)
- # core-async (6)
- # core-logic (25)
- # core-matrix (14)
- # cursive (10)
- # data-science (4)
- # datomic (4)
- # emacs (3)
- # funcool (6)
- # hoplon (127)
- # jobs-discuss (4)
- # keechma (36)
- # ldnclj (5)
- # lein-figwheel (5)
- # off-topic (5)
- # om (155)
- # onyx (72)
- # overtone (16)
- # parinfer (39)
- # planck (3)
- # protorepl (1)
- # re-frame (11)
- # reagent (5)
- # untangled (22)
@seancorfield: Hi Sean, did you ever publish your boot task to generate a DAG of a project's namespaces?
I did not. It’s still an ugly blob of hacky code sitting in a (comment …)
at the bottom of one of my namespaces.
@seancorfield: Ha. Yes, that happens too. Thanks anyway.
it would be cool if clojure's *loaded-libs*
was a map instead of a set
that way it could store a map of namespace -> vector of namespaces require'd from that namespace
then we'd have an awesome, robust dep graph
@kenny: You add a cljs edn file at the target location
Does anyone know here how you can make cider behave with boot-test? It seems to break because of the humane-test-output. I would really like to run my tests from emacs because boot-test is pretty damn slow in watch mode
@mitchelkuijpers: what do you need boot-test for if you want to run from repl?
@martinklepsch: I don’t but it attaches the humane-test-output formatter which makes cider not parse the test-output
@mitchelkuijpers: have you tried only adding it as a dependency when you actually want to use it?
@martinklepsch: that’s a great idea, thnx
Still something seems to break cider.. Will investigate further
@alandipert: totally agree. I know of a library that does that, but I wish it were built-in.
@juhoteperi: RE https://github.com/adzerk-oss/boot-cljs/pull/119 @micha might be able to better answer this.
My use case is having isolated cljs/clj dependencies.
There may now be a better way to implement with-env
, by essentially doing: (binding [boot.pod/env {:dependencies []}] (cljs))
but I haven't tested this, nor looked into it. But it would be a better system.
I figured here would be better for a discussion, than trying to go back + forth in GH issues.
Hi, I have a dependency on cljsjs/material, for material design lite. This is a simple require from my core ns and it works fine.
However, when my app gets reloaded via boot-reload, the init fn as specified by on-jsload
gets triggered and I lose the material design goodness.
@pastafari: I have no understanding of cljsjs/material, but is it possible you need to call your own init-fn to load material again?
@dominicm: thanks. I am trying to include something that will “load material” in my init-fn. Trying to figure out what that means
@pastafari: http://getmdl.io/started/index.html "Use MDL on Dynamic Websites" I'm not sure but because you're rebuilding the DOM, you may need to upgradeElements.
@dominicm: yep, i was experimenting with that. I’m working with re-frame and reagent based components, all of which use mdl. So I’d probably need to do an upgradeAllComponents
@dominicm: so the fn i need to call is this (.upgradeDom (.-componentHandler js/window))
@dominicm added that at the end of my init-fn and problem solved. Thanks for your help
@pastafari: I think it was mostly you, but I'm glad you solved it 😛
(defn upgrade-el* [d]
(.upgradeElement js/componentHandler d))
(defn upgrade-element [body]
(with-meta
body
{:component-did-mount (fn [this] (upgrade-el* (reagent/dom-node this)))}))
I then us this as follows:
(defn tooltip-body [for text]
[:ul.mdl-tooltip {:for for}
text])
(def tooltip (upgrade-element tooltip-body))
@mitchelkuijpers: thanks. That makes sense.
@micha: Thanks for the info about 'boot -vb repl'. What does boot do before evaluating the the 'boot.user' ? I know there are several files that get evaluated by boot, I am trying to understand their order and the evaluating mechanism. In part this is to fill in some conceptual gaps, but specifically to understand the best way to configure boot to work with Atom/proto-repl as an IDE: 'user.clj' (first? By the http://clojure.org/reference/repl_and_main ) 'profile.boot' (?) 'build.boot' (last? Via inclusion in the 'boot.user' namespace)
if you have a profile.boot you will see it in the generated boot.user namespace wqith boot -vb ...
had a fun thing with user
the other day: https://github.com/technomancy/leiningen/issues/2122 😏
you can disable profile.boot with the -P
option to boot, and you can disable build.boot with the -B
option
The principle boot start-up sequence seems to be... 0) run the boot.sh 0.1) which starts Boot.main https://github.com/boot-clj/boot-bin/blob/master/src/Boot.java 1) https://github.com/boot-clj/boot/blob/master/boot/base/src/main/java/boot/App.java 1.1) some default values for the properties are set 1.2) 'boot.properties' are read, possibly overwriting default properties 2) boot helper actions are evaluated {update, version} 3) Clojure is started 3.1) the clojure.main is not invoked http://clojure.org/reference/repl_and_main therefore, 3.1.1) 'user.clj' is not loaded, 3.1.2) nor any of the other attendent behavior (init, eval, etc.} 3.2) boot.main/-main is invoked (instead of clojure.main/-main) 3.2.1) we call runBoot which makes a Clojure call and we say good-bye to Java 3.2.2) -main in https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/main.clj 4) boot takes control 4.1) the 'boot.user' namespace is constructed 4.1.1) the 'profile.boot' is included in 'boot.user' 4.1.2) the 'build.boot' is included in 'boot.user' 4.2) the boot.core/init! is run https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/core.clj 4.3) tasks are run
you can see at the bottom of that file, in the main method it uses reflection to call the boot.App main method
the idea there is to have a very minimal shim that you download, and that shim can download the rest of boot
@micha: Is there a nice pictograph of what you just described? I was able to puzzle most of it out but it took a while.
@micha: I would be willing to make a diagram. Does the flow that I outlined <above> capture the main points? Do you have a preferred drawing format/style/tool? Does such a beast exist for Leiningen?
@phreed: re: chart, anything you want to contribute would be welcome, but maybe svg is the easiest for everyone to edit and store in git
i believe there is a way to show images in the repo in the README
the reason it's so convoluted is that boot is essentially an application container, not really a build tool
so most of what boot does is just constructing the container in which your clojure program runs
if you go right into clojure.main you can't make pods, because there is no container to manage them
and it gets more convoluted when you need to make it user-friendly to update boot in place
in boot there is boot.util/dep-as-map
but is there a map-as-dep
as well? because I would like to pass it back to resolve-dependency-jars
which accepts an env
I can implement it myself, just asking 😉
shall we add it?
(defn map-as-dep
"Returns the given dependency vector with :project and :version put at
index 0 and 1 respectively and
keys/modifiers (eg. :scope, :exclusions, etc) next."
[{:keys [project version] :as m}]
(let [kvs (remove #(some #{:project :version} %) m)]
(vec (remove nil? (into [project version] (flatten kvs))))))
@alandipert: I have a diagram, for boot start-up. Here is a link https://docs.google.com/drawings/d/1U00KLiX0bV7POhPwyFH-THhCTbzhmIHrgFDQLDim1xs/edit?usp=sharing
ok I am PR-ing
@phreed: not sure how in-depth you want to get with it, but boot.App is in boot.jar
which is a binary on github releases that boot.sh downloads
and boot.main/-main
is in the boot/core
dep in maven, which boot.App loads via aether when boot starts
@micha: There are some things that are pretty obvious once I started using boot. One of them was that the boot.jar updates. This diagram is to convey the key elements in the start-up sequence that are not obvious just watching boot do its thing. Is there anything that is incorrect in the drawing? I made this editable by anybody. I you like it feel free to export/download the SVG.
the user.clj stuff normally is related to repl work, which you can totally take advantage of by doing boot repl --init-ns user
@phreed: you've probably seen this already but just in case you haven't might be interesting: https://github.com/boot-clj/boot/wiki/Configuring-Boot
right, running 'boot -vb repl --init-ns user' makes what happens perfectly clear. This might be the answer to the original problem.