Fork me on GitHub
#boot
<
2016-04-05
>
danielsz00:04:44

@seancorfield: Hi Sean, did you ever publish your boot task to generate a DAG of a project's namespaces?

seancorfield00:04:36

I did not. It’s still an ugly blob of hacky code sitting in a (comment …) at the bottom of one of my namespaces.

kenny01:04:56

How do you change the name of an output cljs file? It is not clear in the docs

danielsz02:04:19

@seancorfield: Ha. Yes, that happens too. Thanks anyway.

alandipert05:04:30

it would be cool if clojure's *loaded-libs* was a map instead of a set

alandipert05:04:53

that way it could store a map of namespace -> vector of namespaces require'd from that namespace

alandipert05:04:12

then we'd have an awesome, robust dep graph

martinklepsch07:04:58

@kenny: You add a cljs edn file at the target location

mitchelkuijpers10:04:01

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

martinklepsch10:04:28

@mitchelkuijpers: what do you need boot-test for if you want to run from repl?

mitchelkuijpers10:04:07

@martinklepsch: I don’t but it attaches the humane-test-output formatter which makes cider not parse the test-output

martinklepsch10:04:53

@mitchelkuijpers: have you tried only adding it as a dependency when you actually want to use it?

mitchelkuijpers10:04:26

@martinklepsch: that’s a great idea, thnx

mitchelkuijpers10:04:29

Still something seems to break cider.. Will investigate further

danielsz10:04:50

@alandipert: totally agree. I know of a library that does that, but I wish it were built-in.

dominicm11:04:27

@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.

dominicm11:04:04

I figured here would be better for a discussion, than trying to go back + forth in GH issues.

pastafari11:04:44

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.

pastafari11:04:58

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.

pastafari11:04:44

How can I get the reload task to reload the material dependency as well?

dominicm13:04:03

@pastafari: I have no understanding of cljsjs/material, but is it possible you need to call your own init-fn to load material again?

pastafari13:04:09

@dominicm: thanks. I am trying to include something that will “load material” in my init-fn. Trying to figure out what that means simple_smile

dominicm13:04:37

@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.

pastafari13:04:54

@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

pastafari13:04:33

@dominicm: so the fn i need to call is this (.upgradeDom (.-componentHandler js/window))

pastafari13:04:37

@dominicm added that at the end of my init-fn and problem solved. Thanks for your help simple_smile

dominicm13:04:38

@pastafari: I think it was mostly you, but I'm glad you solved it 😛

mitchelkuijpers15:04:11

@pastafari:

(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)))}))

mitchelkuijpers15:04:37

I then us this as follows:

(defn tooltip-body [for text]
  [:ul.mdl-tooltip {:for for}
   text])

(def tooltip (upgrade-element tooltip-body))

pastafari15:04:03

@mitchelkuijpers: thanks. That makes sense.

phreed15:04:17

@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)

micha15:04:57

@phreed: boot doesn't know about user namespace at all

micha15:04:05

that is something that's built into clojure

micha15:04:12

so we don't mess with it in any way

micha15:04:53

if you have a profile.boot you will see it in the generated boot.user namespace wqith boot -vb ...

micha15:04:27

you can disable profile.boot with the -P option to boot, and you can disable build.boot with the -B option

phreed15:04:13

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

micha16:04:42

it's in the boot.main namespace

micha16:04:51

oh sorry, you're right

micha16:04:57

i was thinking of profile.boot

micha16:04:39

that's the executable that you run, the boot.sh

micha16:04:52

that loads boot.App from the jar file it downloads

micha16:04:00

but it also looks at the properties files

micha16:04:42

the Boot class is the actual entry point of the application

micha16:04:08

you can see at the bottom of that file, in the main method it uses reflection to call the boot.App main method

micha16:04:40

the idea there is to have a very minimal shim that you download, and that shim can download the rest of boot

micha16:04:58

this way we can make it so simple that it will work with any version of boot

micha16:04:11

and we won't have to update it to add features or fix bugs

micha16:04:28

those will all be done in the jar that contains boot.App, not the boot.sh jar

micha16:04:41

so the user doesn't need to download a new boot.sh ever

phreed16:04:42

@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.

micha16:04:00

the README edscribes it, but no diagram

micha16:04:06

we need more diagrams simple_smile

phreed17:04:14

@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?

alandipert17:04:05

@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

alandipert17:04:31

i believe there is a way to show images in the repo in the README

micha17:04:27

@phreed: that looks legit to me

micha17:04:50

the reason it's so convoluted is that boot is essentially an application container, not really a build tool

micha17:04:07

so most of what boot does is just constructing the container in which your clojure program runs

micha17:04:24

and the java stuff is the container that provides the pods facilities

micha17:04:51

if you go right into clojure.main you can't make pods, because there is no container to manage them

micha17:04:26

and it gets more convoluted when you need to make it user-friendly to update boot in place

micha17:04:55

or run different versions of boot on the same machine via the same binary

richiardiandrea18:04:33

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

richiardiandrea18:04:47

I can implement it myself, just asking 😉

richiardiandrea19:04:11

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))))))

micha19:04:37

@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

micha19:04:13

and boot.main/-main is in the boot/core dep in maven, which boot.App loads via aether when boot starts

phreed19:04:27

@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.

micha19:04:29

the user.clj stuff normally is related to repl work, which you can totally take advantage of by doing boot repl --init-ns user

micha19:04:13

looks great to me

micha19:04:42

@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

phreed19:04:10

right, running 'boot -vb repl --init-ns user' makes what happens perfectly clear. This might be the answer to the original problem.

micha19:04:56

it's not the default because in most cases i think people want to be in a repl in the boot.user context, where they can run tasks etc

micha19:04:21

and you can do like

micha19:04:35

(task-options!
  repl {:init-ns 'user})

micha19:04:42

in build.boot to make it the default

micha19:04:50

or in profile.boot even