This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-09
Channels
- # aws (3)
- # bangalore-clj (3)
- # beginners (40)
- # boot (53)
- # cider (1)
- # cljs-dev (124)
- # cljsrn (22)
- # clojure (105)
- # clojure-italy (1)
- # clojure-nl (3)
- # clojure-russia (35)
- # clojure-spec (9)
- # clojure-uk (30)
- # clojurebridge (25)
- # clojurescript (107)
- # datomic (18)
- # dirac (21)
- # events (6)
- # hoplon (29)
- # leiningen (5)
- # off-topic (40)
- # om (17)
- # onyx (25)
- # parinfer (2)
- # pedestal (4)
- # perun (2)
- # planck (1)
- # protorepl (6)
- # re-frame (18)
- # reagent (15)
- # ring-swagger (4)
- # specter (2)
- # test-check (7)
- # testing (3)
- # untangled (45)
- # vim (2)
continued discussion from #clojurescript:
have an interesting issue with :advanced
mode build:
https://gist.github.com/darwin/34b2eaf97f1823b1180eb14ad64af9fd
initial-config
is not used so it should be elided, 01 does not elide it, 02 does
note the comment there
so nesting is not causing the issue, simply the fact that a function is called multiple times
I think closure compiler decides to not inline it and that causes subsequent elision pass to fail to see that this whole thing can be elided
this is part of cljs-devtools, I want it to leave no trace in advanced builds, if not installed
as for 1) it would be nice to collect more information that the protocol test is the source of the problem
we donât have this pattern anymore of invoke + assign at the top level - it took very careful tiptoeing to support both dead code elimination and cross module code motion
interesting, but that does not help me here, defaults/prefs
is dynamic in my case, so I cannot merge those values at compile-time, I still need something like var x = merge(m1, m2, m3);
I think I can work-around it, just by writing more flexible version of simple-merge
and call it only once
Iâm afraid I donât follow, are you suggesting that simple-merge
should be moved to another namespace?
btw look at #04: https://gist.github.com/darwin/34b2eaf97f1823b1180eb14ad64af9fd#file-04_works_but_does_not_elide_the_not_found_keyword-cljs
this is the final version: https://github.com/binaryage/cljs-devtools/commit/2b542a9f4a73f33236da97fdfb1784216e602be1
btw. my theory is that when reduce
or any other core function optionally calls some protocol methods, the closure compiler cannot be sure that there are no side-effects, so it cannot elide it, that is why I couldnât use merge
in the first place
more puzzling is why 04 does not elide namespaced keyword, 06 is identical but with unqualified keyword and there elision works
it should be trivial to write plain old javascript that replicates protocol pattern that demonstrates your theory holds
ah, hit another problem, completely unrelated to the previous one
is it possible to detect if my namespace was included via :preloads
?
the problem, normally people should install cljs-devtools by :preloads [devtools.preload]
and using :main âroot.ns
, that is fine, but when they donât and use no :preloads
and no :main
, then my devtools.preload
gets executed at arbitrary point, because that ns is on classpath and without :main
all namespaces are included in the build
one option would be to move devtools.preload
to some other folder not included by default, but then I would have to tell people to add this to their :source-paths
when using :preloads
to clarify: "but when they donât and use no :preloads
and no :main
, then my devtools.preload
gets executed at arbitrary pointâ, the proper behaviour I want is that devtools is not auto-installed at all, and must be installed by calling devtools.core/install!
explicitly by the user (this was the original behaviour prior adding support for :preloads
)
let me try to rephrase it:
in problematic case, compiler options have no :main
and no :preloads
facts:
1. namespace devtools.preload
is on classpath (it is always there because cljs-devtools was in dependencies)
2. currently looks like this https://github.com/binaryage/cljs-devtools/blob/master/src/lib/devtools/preload.cljs
the problem:
install! is called, because :main
wasnât specified
if I were to specify :main
, the devtools.preload
namespace would not be reached, because nobody should require it, it sole purpose was to serve :preloads
feature
if something is getting pulled in just because itâs on the classpath something else is wrong
but I thought this works the same with dev builds as well, missing :main
means, treat all visible namespaces as âmainâ and include them
they wonât get your preloads from inputs
/ :source-paths
theyâll get it from the classpath
so if I move preload.cljs out of this[1] folder, which is input
, and manage to put it on classpath, then I will fix my issue:
[1] https://github.com/binaryage/cljs-devtools/tree/master/src/lib/devtools
thanks, will try it, today I learned about the distinction between classpath and input, good to know
it is clear to me what I want to do, but unclear how to do that, how clojurescript compiler knows what is to be added into inputs
when depending on a library? or this is responsibility of the build tool at hand? in case of leiningen, is cljsbuild plugin responsible for assembling inputs
list by walking the dependency tree?
we know everything in the build because we start with this one file and follow all of itâs requires
we use both of these files as entry points to figure out whatâs in the build again by following requires (which are resolved on the classpath)
clear, thanks, so now, letâs add a library situation, clojurescript is not concerned about âmavenâ dependencies, right? it is the task of a build tool to prepare all inputs
what is unclear to me right now is how folders from my libraryâs jar file end up in inputs
when :main
is specified, it is the file matching the namespace, if :main
is not specified, what happens?
maybe understanding this question would help me: what is the difference between leiningenâs root :source-paths
and cljsbuildâs cljsbuild profile :source-paths
ok, without :main
I believe I understand it, given inputs
, walk all require deps and build list of all files for compilation, in topological sort
so, with this model in my head, my original situation with cljs-devtools library having all cljs files in one folder (including preload.cljs) should not be an issue, because library means just adding stuff on classpath, not into inputs
if this is true, I must investigate why devtools.preload namespace gets added to the build, there must be something wrong with my project
found it[1], sorry for all the noise, I was 99% sure, I searched the whole project [1] https://github.com/binaryage/dirac/blob/master/src/implant/dirac/implant/deps.cljs