Clojurians
#cljs-dev
<
2016-08-22
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

anmonteiro16:08:08

I wonder how faster advanced compilation would become with this optimization in Closure Compiler https://github.com/google/closure-compiler/wiki/Releases#july-13-2016-v20160713

anmonteiro16:08:40

“much faster compilation, especially for projects with large files” sounds like the CLJS case

anmonteiro16:08:49

I wonder how much is “much faster” :slightly_smiling_face:

dnolen16:08:02

@anmonteiro would be happy to see us bump Closure Compiler, there’s some ES6 related stuff that changed that I haven’t had time to look into

anmonteiro16:08:33

@dnolen last time I looked it would involve changing some constructor methods to Java Objects in cljs.closure

anmonteiro16:08:52

Happy to put a patch together for that. should I open a JIRA?

dnolen16:08:04

@anmonteiro yep go for it

anmonteiro23:08:42

@dnolen I’m wondering if I can remove these conditionals in the Closure Compiler patch https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L79

anmonteiro23:08:12

it seems they’re no longer needed if we bundle the new versions of the GCC

anmonteiro23:08:54

FWIW, I’ve built a local version without them and tried it on https://github.com/mneise/circle-color

anmonteiro23:08:59

everything works as expected

dnolen23:08:40

@anmonteiro I’d rather leave those alone for now

anmonteiro23:08:50

@danielcompton that hasn’t been released yet on Maven

anmonteiro23:08:27

shouldn’t be long though

anmonteiro23:08:18

however, to upgrade the Closure Compiler to that release we’ll need to touch that code

anmonteiro23:08:40

so maybe I should stick with 20160713 for now?

dnolen23:08:20

yes stick with 20160713

anmonteiro23:08:22

well, actually 20160713 also has some changes to constructors that’ll make me have to touch that code

dnolen23:08:30

users can control what they get anyway

anmonteiro23:08:53

@dnolen yeah there’s just no way I can bump Closure without touching that code

anmonteiro23:08:31

reason is e.g. ES6ModuleLoader’s constructor in 20160713 is the same as what we infer as “old"

anmonteiro23:08:25

so I’ll wait for your instructions before proceeding any further

anmonteiro23:08:59

they had constructor A then refactored to B, so we had A = old and B = new. However, now they reverted back to A

dnolen23:08:17

@anmonteiro hrm this seems solveable via reflection no?

anmonteiro23:08:22

so we infer that constructor A is old and don’t provide functionality for some modules

dnolen23:08:29

Java reflection