Fork me on GitHub
#cljs-dev
<
2017-07-27
>
dnolen12:07:14

@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?

mfikes13:07:56

@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)

mfikes14:07:10

@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.

mfikes14:07:53

As an aside, I wonder if there is a bug in load-file not being able to reload a file containing constants.

mfikes14:07:59

I’ll put together a patch that revises self-host to work like JVM (essentially replicating the Planck workaround)

mfikes16:07:22

@mhuebert https://dev.clojure.org/jira/browse/CLJS-1854 now has a patch for :reload with ^:const in self-host

mhuebert16:07:15

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.)

mhuebert16:07:58

(this was running a build script, compiling on the JVM, not in the browser/self-host environment)

dnolen17:07:04

@mhuebert need more information - are you using master?

mhuebert17:07:03

@dnolen also i couldn’t reproduce on my computer

dnolen17:07:58

Ah k yeah known and we believe fixed in master

dnolen18:07:15

cljs.spec.alpha/fdef was resolving eagerly, surprised no one has been bothered by this before - fixed in master now

dnolen19:07:45

it’s intentional that you can define fdef specs w/o those vars even existing

mfikes19:07:47

Hah! I have always been putting my fdefs after the associated fn. Good catch! 🙂

mfikes19:07:06

@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

mfikes19:07:59

All cool, looks like we are already on [org.clojure/test.check "0.10.0-alpha2" :scope "test"] so this is easier to resolve

dnolen19:07:38

@mfikes do we need to do anything at all?

mfikes19:07:03

Yes—at least to get the tests to pass again. I’m attaching a patch that fixes them.

mfikes19:07:48

At its core is that script/test-self-parity wasn’t set up to be able to load test.check

mfikes23:07:29

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}.

mfikes23:07:44

I'll file a JIRA, you get other non-readable printing for #js {"foo bar" 2} even on 1.9.671