This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-07-31
Channels
- # admin-announcements (23)
- # announcements (3)
- # beginners (59)
- # boot (122)
- # clojure (117)
- # clojure-berlin (3)
- # clojure-dev (3)
- # clojure-italy (3)
- # clojure-japan (10)
- # clojure-russia (69)
- # clojurebridge (12)
- # clojurescript (183)
- # clojutre (14)
- # code-reviews (4)
- # core-async (79)
- # core-logic (18)
- # core-matrix (1)
- # cursive (7)
- # datascript (1)
- # datomic (18)
- # editors (3)
- # events (18)
- # hoplon (20)
- # ldnclj (24)
- # luminus (1)
- # off-topic (1)
- # other-lisps (1)
- # re-frame (12)
- # reagent (104)
also I was just running into a problem where I wanted to add reload/repl to one build but not the other — that’s not currently possible is it?
master and next for similarly in that: boot-cljs creates a namespace it will use as cljs :main and which will require and run init-fns
Probably the problem with boot-reload and next is that boot-reload changes all .cljs.edn files?
Probably still a good idea to combine all those tasks as they rely on boot-cljs being used anyways
Not sure if combining everything is the best solution but I don't know what would be better
I'm writing a boot task (in a different namespace) but I can't get it to be visible by executing "boot xxx" in the project or subprojects that depend on it.
@aengelberg: did you require it in your build.boot and add the metadata to the ns form?
@aengelberg: the ^{:boot/export-tasks true}
is for when you pull in the jar with the task in it via the boot -d ...
I assumed that any namespace with export-tasks
that is on the classpath would have their tasks automatically work.
@aengelberg: only what you explicitly require will be available if you have a build.boot
file — if you don’t have a build.boot
file what you said should be the case I think
@juhoteperi: maybe it’s an alternative to just combine the repos into one as this allows easier/better coordination? things can still be separate artifacts etc.
@martinklepsch: Might be, latest master should work. I plan on adding something like boot-cljs.cljs-api-compat
which would use API calls if they are available and then fallback to copied implementation for older cljs versions.
Compiling app.js...
java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to clojure.lang.IAtom
clojure.core/swap! core.clj: 2231
cljs.closure/build closure.clj: 1606
cljs.build.api/build api.clj: 219
adzerk.boot-cljs.impl/compile-cljs impl.clj: 46
...
clojure.core/apply core.clj: 630
boot.pod/eval-fn-call pod.clj: 183
boot.pod/call-in* pod.clj: 190
...
boot.pod/call-in* pod.clj: 193
adzerk.boot-cljs/compile boot_cljs.clj: 49
adzerk.boot-cljs/eval418/fn/fn/fn boot_cljs.clj: 115
adzerk.boot-cljs/eval390/fn/fn/fn boot_cljs.clj: 61
boot.task.built-in/fn/fn/fn/fn built_in.clj: 145
adzerk.boot-reload/eval591/fn/fn/fn boot_reload.clj: 96
adzerk.boot-reload/eval591/fn/fn/fn boot_reload.clj: 89
adzerk.boot-cljs-repl/eval520/fn/fn/fn boot_cljs_repl.clj: 175
boot.task.built-in/fn/fn/fn/fn built_in.clj: 277
boot.task.built-in/fn/fn/fn/fn built_in.clj: 274
boot.task.built-in/fn/fn/fn/fn/fn/fn built_in.clj: 226
boot.task.built-in/fn/fn/fn/fn/fn built_in.clj: 226
boot.task.built-in/fn/fn/fn/fn built_in.clj: 223
pandeiro.boot-http/eval646/fn/fn/fn boot_http.clj: 71
boot.core/run-tasks core.clj: 688
boot.core/boot/fn core.clj: 698
clojure.core/binding-conveyor-fn/fn core.clj: 1916
...
Elapsed time: 15.121 sec
I’m currently playing around with Electron (atom-shell) and I think it’s a good example for something that requires a more complex cljs setup. There are two builds required one for the main
process and one for the renderer
(= whats shown in the webview). Both require different optimization levels in development. Also when changing sources only relevant to the renderer
the build for main
should not be triggered.
Have you noticed if the boot-cljs is slower now that it uses different output dirs for different outputs?
Though shared output dir probably wouldn't work if there are different optimizations
yeah i don't think there are any guarantees about sharing output dirs for different builds at all
deraen: what i was thinking was to have parameterized rules, like the abstract "heading" rule, where you have the leading char (`#`), repeated multiple times for the :level
attribute, for example
so i'd want to be able to add an instance of that rule from my cljs application, like to add a heading type rule that looks like %%% some other kind of heading
Maybe AST should be using Records and then provide one formatter which converts that to hoplon and another to hiccup
@juhoteperi: regarding next
— should all builds run every cycle or should it detect when no relevant files have changed?
@martinklepsch: All builds. But if files interesting to build aren't changed the build should be very fast.
@juhoteperi: the build that should not be run is :whitespace
and makes for about 7 of 8s compilation time
@martinklepsch: Mhh could be that other than none build will always do the optimization step, I'm not sure if we can do anything about that.
Do I understand right that all the dependency tracking etc is now done by the cljs compiler directly and the compiler decides when to rebuild?
because you can't make it fast, so preventing it from compiling unnecessarily is only part of a solution
The thing is that it’s almost a one-off. I don’t see how changes could be picked up by electron.
micha: I need to compile them once though + restarting boot when I change it is also non-ideal