hello here I am again 😱 so I tracked down the problem to a nil env/*compiler* in replumb, so basically to here: https://github.com/clojure/clojurescript/blob/756fa9bb196a97e0ae40fd644da5e492e0336c1c/src/main/clojure/cljs/analyzer.cljc#L1800

it was checking that part and I am maybe missing the reason why there is a let there given that cenv is never used

same behavior in inferred-use-macros and missing-use-macros and missing-uses

so probably @dnolen it is something that requires your suggestion on what to do, given that I might miss some important detail here..

in case we can purge that, I can take care of that

then I need to investigate why in my case env/*compiler* is nil on my side

@richiardiandrea: it just sounds like the compiler environment didn’t get bound because of some async load

ok I am checking that too

ah ah I had tests again the fact that :rename was not working in replumb, now it is! 😄

I found (maybe) a small regression on an error message: shall I open an issue? explanation:

before this: (ns my.namespace (:require [clojure.string :refer :all]))

was returning ...:refer must be followed by a sequence of symbols in :require / :require-macros;

now it returns Could not eval (ns my.namespace (:require [clojure.string :refer :all])) - :all is not ISeqable at line 1

@richiardiandrea: sure

1.9.211 is out

https://groups.google.com/d/msg/clojurescript/KIX2ll89Ohk/3DJWEGk6DAAJ

@dnolen: thinking of using :elide-asserts for this https://github.com/clojure/clojure/blob/d920ada9fab7e9b8342d28d8295a600a814c1d8a/src/clj/clojure/spec.clj#L1699

or shouldn’t it depend on that?

kinda tricky to port runtime enabling/disabling of asserts from Clojure

@anmonteiro: runtime enable/disabling of asserts outside of development is a non-goal

i.e. doesn’t need to work in advanced

it should work under dev though

@dnolen: I was thinking of using elide-asserts for compile time and a dynamic var *runtime-asserts* for runtime

open to better suggestions

@anmonteiro: if that more or less mimics Clojure yeah go for it

@dnolen: also tweaking docstrings for the differences between Clojure and CLJS (e.g. system properties vs compiler option)

let me know if I should keep the original (Clojure) docstrings

Attached initial patch for review: http://dev.clojure.org/jira/browse/CLJS-1747

@mfikes: would also appreciate you looking over any bootstrap issues for this one. Tests are passing so I’m confident there’ll be none

@anmonteiro @dnolen while you guys are talking about assert

http://dev.clojure.org/jira/browse/CLJS-1494

if we introduce it as a goog-define

we can remove :elide-asserts since the closure compiler can do it

+ we get runtime asserts

@thheller: yes something to think about, but going to be pretty focused on cljs.spec for the next couple of releases

@dnolen: a little more nitpicking, I think some gens are missing from cljs.spec.impl.gen: bytes and double* seem to be missing, and the gen-for-name function is commented out

what should be done for these?

bytes didn’t make any sense to me nor double

if you can make a case for them that would be good

there is double, but not double*

what is double* sorry

a generator that provides more control than double

allows to specify that you don’t want NaNs, etc

ok make a separate issue for that then

https://clojure.github.io/test.check/clojure.test.check.generators.html#var-double*

what about gen-for-name?

what does that do?

it’s there but commented out

"Dynamically loads test.check generator named s."

right that doesn’t make any sense in ClojureScript

dynamically load … how?

yeah

it will probably already be there

@dnolen: am I doing something wrong here?

Could not find artifact org.clojure:clojurescript:jar:1.9.216 in central ()
Could not find artifact org.clojure:clojurescript:jar:1.9.216 in clojars ()

@richiardiandrea: not waiting long enough 🙂

ah ah well my bad 😄