Hello guys, is there an obvious reason why in bootstrapped clojurescript :simple :

cljs.user=> (ns a.ns)
nil
a.ns=> (def a 3)
ERROR - Cannot set property 'a' of undefined <- here undefined is a.ns

I understand namespaces are not reified but:

as.ns=> (ns ap.ns)
nil
ap.ns=> (def a 3)
#'ap.ns/a
ap.ns=> (ns c.ns)
nil
c.ns=> (def a 3)
ERROR - Cannot set property 'a' of undefined <- here undefined is c.ns

smells like a bug

but I wanted your opinion first

@richiardiandrea: does in-ns work?

@jaredly will check tomorrow. Have you had similar issues?

yeah.. can’t remember what fixed it though

@richiardiandrea: whether that does or doesn’t work is really dependent on REPL code

and bootstrapped doesn’t provide any of that

thanks @dnolen smelled like a bug but very likely on my side 😄 @jaredly if you happen to remember let me know ok? thank you both!

@richiardiandrea: umm so testing in http://jaredforsyth.com/reepl/ a.ns or [single-char].ns doesn’t work, but (ns some.ns) or (ns one.two) works 😄 might point you in the right direction

yes same here, and it happens with :simple only so I might be losing js symbol somewhere

it is weird because in the console I see the object a.dt but my JavaScript-fu is weak and it looks like this object is not visible inside the expression above

ok so in the scope of execution of the big Javascript function above there is no symbol a.ns defined, but if I execute in the console it works! Digging...

so now the question is, what is the difference between console and js/eval?

@richiardiandrea: check for window.a.ns in the scope of that function

it’s possible that there’s a local variable a that’s shadowing the global window.a

checking...

yes I think is like you say and b (b.nh) in that closure is:

[:lang :clj]
1[:name "(def a 3)"]
2[:path "(def a 3)"]
3[:source 
"(function (){↵b.nh.a … test:null)])));})()↵"
]
4[:cache nil]

cljs-devtools output

yup, gclosure makes most vbls single letter

wonder how hard it would be to get namespace references prefixed with window (or global in node, self in webworker)

@jaredly: so basically it is referring to local vars instead of window and because of the optimizations the name clashes?

yup

gotcha

I will open an issue

a fix could be to pass an option to the compile step that prefixes everything w/ window.

maybe there is a reason not to do it and David will tell us 😉

well it doesn’t make sense to do it in generally b/c closure has global knowledge

but in bootstrapped, you’re running stuff after closure’s done it’s magic and w/o it’s knowledge

right

that's why he was saying that it is basically my implementation

but the generated code here under not my control

it is generated in cljs.js/eval

in any case :simple in both node and browser is hard to achieve (atm does not work for node for instance)

by the way @jaredly is js/global renamed in nodejs when :simple?

@richiardiandrea: I do not understand what’s under discussion here really

so far I haven’t heard anything that seems like a bug

@dnolen: compiled cljs assumes that namespaces are in the global scope, but if you’re in a function compiled by google closure, where single-letter variable names are locally shadowed, you won’t be able to access anything on single-letter namespaces, e.g. a.ns.

I am not sure @dnolen, that's why I haven't open any issue yet, don't want to say it is a bug until I understood, probably it has to be that way

but yes the problem is the above ^

a bootstrapped repl needs to be able to prefix all javascript references w/ window. in order to guard against this shadowing. this would be a change to core

@jaredly: ok that isn’t a bug

@richiardiandrea: this is your answer ^

shadowing is shadowing, absolutely uninterested in doing anything about it

it’s only an issue that would come up in the context of bootstrapped cljs

@jaredly: that isn’t true

the compiler has stuff for shadowing

it affects all ClojureScript

look at at JIRA for several tickets around this problem

right but the issue is two different compilations that aren’t aware of each other

and they should not be

I agree

also if this boils down to single character namespaces … we just don’t care

well yes I agree, it is such an unlikely scenario

it’s not that it’s unlikely

it’s that it’s not important at all

bootstrapped + single letter ns -> just came up in my tests

would you be open to a patch that adds an option js-ns-prefix or something to compile-string?

sure but if it doesn’t matter for normal usages of bootstrapped, this isn’t something worth spending time on

@jaredly: no

probably the only thing I would consider is a warning about single letter namespaces

I agree with @dnolen too here, I already spent some "precious" time to debug it

nobody should be doing that

it would also allow (something that I’ve wanted) for bootstrapped cljs to eval in a separate namespace-context from the bootstrapping code. e.g. deffing a vbl in the repl that doesn’t step on the code of the repl itself

perfection does not exists I guess, on the bright side TIL

@jaredly: that is interesting, dunno if doable, again my JS-fu is weak

w/ a js-ns-prefix it would totally work

no I was thinking of a solution in replumb but I don't see it working

@jaredly: not interested in such a thing at this time

far as I can tell the corrupted analysis cache bug should be fixed - https://github.com/clojure/clojurescript/commit/68524a89eea8a8ae6cb69d1329acb3e3025c0fb6

if somebody wants to test master that would be great

oh I read about it, I will check

@richiardiandrea: you know it’s working if your project can still build even if you truncate an analysis cache file

ok thanks because there was no test case in the issue

@richiardiandrea: a test case would be welcome for this of course

ha. so I’ve still been using cljs master from working on that patch, and today I had a super weird ui bug. just could not figure it out. then I look at the map holding the relevant data - duplicate keys! (not= (count (keys m)) (count (set (keys m)))). one key had the correct value, the other an old one. happening about every 10 minutes and haven’t been able to figure out exactly when/how it starts.

@dnolen: so I see all my cache.edn then I just delete some part of them and launch the build again?

@richiardiandrea: yes

another fix that probably needs confirmation https://github.com/clojure/clojurescript/commit/c59e957f6230c07e7a228070dd8eb393d5b8ce40

might affect bootstrapped usage

also if you’re using :parallel-build of course

@dnolen: sorry for the noob question but cljs.build.api/build does not allow multiple source dirs at the moment?

@richiardiandrea: it does use inputs

checking the source..

clever @mfikes, I am using your tricks 😄 CLJSC_CP=... otherwise it is a pain 😉

Ok for now I will take a break, I have: Exception in thread "main" java.lang.IllegalAccessError: tried to access class com.google.javascript.jscomp.ES6ModuleLoader from class cljs.closure__init

Will try maybe later