Clojurians Log v2

after a discussion with @thheller (https://clojurians.slack.com/archives/C03S1L9DN/p1604658107070900) about some self-host macro issues I’ve run into, I found something that I think I can reproduce in cljs itself - https://github.com/clojure/clojurescript/compare/master...mhuebert:cljc-macros-require-test - does that look like it should work?

I was running ./script/test-self-host on an older version of clojurescript, after rebasing master I’m seeing fixed via script/bootstrap

SEVERE: /Users/mattmini/Documents/projects/clojurescript/builds/out-self/cljs/core.js:27: ERROR - Closure dependency methods(goog.provide, goog.require, etc) must be called at file scope.
cljs.core._STAR_target_STAR_ = goog.define("cljs.core._STAR_target_STAR_","default");
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

might need to run script/bootstrap again in case that is out of date

not actually sure thats still relevant though

but the error above comes from mixing incompatible closure-compiler/closure-library versions

@thheller thanks, that was the reason why I couldn’t run the tests after updating

weird thing about that failing test: it is in a group of 4 related tests. if I move it to the last position in the group (after (ns foo.bar)\n(first [1 2 3])), it passes

what voodoo. if I just copy it so it’s in both places (with a latch of 5), then both tests pass

But without the copy at the end, fails

maybe some hidden race condition somewhere?

@braden.shepherdson that's why we don't update GCL or Closure Compiler very often

there's always breaking changes

and both compiler and library must be coordinated - it's really annoying

also generally there's often not super meaningful changes over the span of years

as far as ClojureScript is concerned

that said, it's on my plate to look at in the 3-4 weeks, and certainly before the end of the year

hm. I'm likely to discover other breaking changes, then, if I'm using master GCL and jscompiler.

patches welcome of course, but auditing everything that could go wrong is actually way more trouble than you may understand

i.e. downstream tooling might break

so even if we fix some stuff it might all be delayed

until it's communicated and agreed what is required

I'll fiddle with it locally, and at least file a bug with the details. this AnonymousFunctionNamingPolicy case specifically is an option being dropped, so it's easy enough to just stop setting it. I guess it's possible that there's downstream tooling that depends on setting it to something non-default, though I think this is a pretty obscure option.

yes, please capture that one and anything else you encounter

I will also give it a try - Figwheel will also need a spin, I need to test Krell, yadda yadda

so the urgency is quite low

FWIW I took a look yesterday the offending code can just be removed. I doubt anyone ever used the related setting since source maps were introduced.

sure, I'm just pointing out that testing the new compiler/library takes some time now - it might be easy - might not - if things are working in shadow w/o other changes that's a good sign o' course

can't do much in shadow since everything breaks when cljs.closure is loaded

but shadow is on v20200830 without issues. I believe the september update just broke things because of the removal.

otherwise will probably work just fine