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)
@nberger: finally got to testing :parallel-build option
, so far it looks good in my projects, thanks for working on this
@nberger: btw. the warnings are still present in my CI builds[1], but not present on my dev machine where I have your patch applied https://travis-ci.org/binaryage/dirac#L723
@nberger, @dnolen: bad news, I ran into the issue again even with the patch applied, I also modified the warning string just to make sure I’m running my patched version
I think I have reproducible steps for my rather complex project, if I disable :parallel-build and try to reproduce it again, it could confirm at least that the problem is somewhat related to parallel-build feature
@darwin is it possible for me to play with your project? Is it dirac? I could use the ad-hoc instrumentation I used to debug the issue, and see if it looks like the same issue
@nberger: yes, it is dirac, you should be able to reproduce it if you are under Mac OS, but it will involve some setup steps (for example you need a chrome canary)
hummmm, I'm not on Mac OS. I'll try to share that instrumentation with some explanation later for you to try
ok, so now I confirmed, that the problem is present even without :parallel-build enabled, so this one will be some other problem
I can trigger it by modifying a library in leiningen’s checkouts dependencies, which triggers figwheels hot-reloading in several of my projects, which then spits a bunch of warnings, there is probably a race in my setup or figwheel cannot handle it properly
interesting on this case is, that that hot-reloading is triggered on multiple running watching figwheel instances in parallel
getting closer what triggers it, figwheel is ruled out, running multiple builds in parallel too
so the problem seems to be triggered when I compile my cljsbuild build first with "cljsbuild” “once” (30s) and then I start it with "cljsbuild" “auto”, the auto mode definitely reuses caches from once run, because compilation is incremental
if I do lein clean
and run just "cljsbuild" “auto” directly, it takes 30s for first-time compile and then works as expected without warnings
I’m going to narrow it further, maybe I don’t need to trigger it via a checkouts lib, but some normal code changes will be enough
I’m aware this seems to be outside of the scope of #C07UQ678E, so I’m moving elsewhere. Conclusions: this is probably not cljs fault, but problem in lein-cljsbuild possible candidate is https://github.com/emezeske/lein-cljsbuild/commit/5485e25bfa6c44cdf0e9d7cb106584915cec0616 I can confirm all warnings are macro-related. And I can confirm that my projects contain clj files with the same namespaces as cljs files (for good reasons).
just a follow up, I was able to prepare a minimalistic repro case for lein-cljsbuild project: https://github.com/emezeske/lein-cljsbuild/issues/443