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)
@juhoteperi: does boot-cljs/next still use the shim?
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?
I wasn’t using next
but yeah I guess that’s the cause
It should probably take :id argument which could select specific .cljs.edn
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 would prefer keeping tasks separate as much as possible
I basically agree but they seem to be pretty close to each other anyways
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?
(ns ^{:boot/export-tasks true} cljsee.task
And I am requiring it in build.boot.
Oh, looks like I have to :refer
the task in build.boot as well.
Now it is working.
is it listed in boot -h
— maybe under a different symbol as you would expect?
@aengelberg: if you dont refer you need to do x/task
just as in clojure
@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.
Is that not the case?
@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
I see.
Thanks Martin and Micha
happy to help
@juhoteperi: does boot-cljs/next depend on something that’s not in 1.7.10 yet?
@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.
@martinklepsch: Hmph, 1.7.10 should contain required changes.
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
@juhoteperi: that’s what I get with next and 1.7.10
@martinklepsch: I see the same error
Strored-env is created using wrong call 😄
It's creating analysis env instead of compiler env
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.
Should be fixed now.
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
that is only in next right?
I haven’t ran next yet
but will try now
yeah i don't think there are any guarantees about sharing output dirs for different builds at all
You're doing good work, @juhoteperi!
I corrected our coordination failure 😄
@micha: Nice. I was thinking that might be useful.
Though isn't markdown-clj already one?
Right
@micha good luck! 😄 (I have "instaparse" as one of my highlight words)
I also like it a lot (I wrote kind of natural language parser using it :D)
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
@micha: how does that work with cljs + instaparse is instaparse cljc?
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
Like endophile
@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.
Cljs should itself do the mod time checking.
Though there could be something which causes cljs to do compilation each time.
@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.
… other than getting mod-time checking into the cljs compiler?
Perhaps. But that's something which should probably be done by cljs.
hm. For that electron stuff this is really impractical.
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?
It was the easiest I could get electron to work with
but you’re right I haven’t gone down that rabbit hole completely yet
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.
I need to restart Electron everytime it compiles
but changes to the main process are rare so it’s ok I think
micha: I need to compile them once though + restarting boot when I change it is also non-ideal
that would work but it’s not pretty enough 😛