This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-27
Channels
- # aleph (3)
- # beginners (89)
- # boot (198)
- # cbus (4)
- # cider (11)
- # clara (2)
- # cljs-dev (27)
- # cljsrn (4)
- # clojure (141)
- # clojure-austin (4)
- # clojure-italy (11)
- # clojure-nl (1)
- # clojure-poland (2)
- # clojure-russia (35)
- # clojure-spec (33)
- # clojure-uk (55)
- # clojurescript (111)
- # core-logic (15)
- # cursive (2)
- # datascript (47)
- # datomic (132)
- # emacs (4)
- # jobs (1)
- # lein-figwheel (13)
- # leiningen (15)
- # lumo (20)
- # off-topic (110)
- # om (8)
- # onyx (20)
- # parinfer (2)
- # protorepl (1)
- # re-frame (36)
- # reagent (5)
- # remote-jobs (1)
- # ring (2)
- # ring-swagger (5)
- # specter (6)
- # uncomplicate (3)
- # unrepl (77)
@mfikes question about CLJS-1854, now that I have some time to actually think about it - I don’t understand why whatever we’re doing in ClojureScript JVM doesn’t cover you?
@dnolen The reason it works in ClojureScript JVM is rooted in this line being executed https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/compiler.cljc#L1506
In fact, you can repro what occurs in self-host, by simply trying to do load-file
in the REPL on a file containing constants which has already been loaded because that causes (:mode opts)
to be :interactive
(see the previous line)
@dnolen The above line flushes the namespace prior to the file being analyzed here https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/compiler.cljc#L1340 I suppose Planck’s previous workaround essentially imitated this behavior. I’ll add comments to the ticket.
As an aside, I wonder if there is a bug in load-file
not being able to reload a file containing constants.
I’ll put together a patch that revises self-host to work like JVM (essentially replicating the Planck workaround)
@mhuebert https://dev.clojure.org/jira/browse/CLJS-1854 now has a patch for :reload
with ^:const
in self-host
FYI one of the people working on Maria ran into CLJS-2153 this week. After clearing the out
directory for the build, the error went away, and subsequent repeated compiles are not reproducing the issue. We had :parallel-build
on in all cases (was going to try disabling it as a next step, but deleting the cached files worked.)
(this was running a build script, compiling on the JVM, not in the browser/self-host environment)
cljs.spec.alpha/fdef
was resolving eagerly, surprised no one has been bothered by this before - fixed in master now
@dnolen The latest commit needs test.check
for self-host. We could revive my old test.check
addition that we reverted (since the underlying issue has since been resolved), or we could perhaps move the relevant test out of the scope of what self-host runs under script/test-self-parity
All cool, looks like we are already on [org.clojure/test.check "0.10.0-alpha2" :scope "test"]
so this is easier to resolve
At its core is that script/test-self-parity
wasn’t set up to be able to load test.check
Without the patch, you get this https://travis-ci.org/mfikes/clojurescript/builds/258270618#L2109
I wonder if this should be treated as a bug: On master you can eval #js {"foo/bar" 1}
and get back a JS literal #js {:foo/bar 1}
that you can't round-trip because the reader will insist that you cannot use qualified keys. To fix that while abiding with the reader constraint, further work would need to be done on top of CLJS-2190 to print as #js {"foo/bar" 1}
.