Clojurians
#cljs-dev
<
2017-11-22
>

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

pesterhazy13:11:24

I'm trying to compile cljs's out/ directory manually using GCC but can't figure out the magic incantation. I'm using the all-in-one jar:

java -cp cljs-1.9.946.jar com.google.javascript.jscomp.CommandLineRunner --compilation_level ADVANCED --js goog/'**.jar' --js out/'**.js' --manage_closure_dependencies --closure_entry_point bug.core --js_output_file advanced.js

pesterhazy13:11:48

This gives me errors:

out/cljs/core.js:34828: WARNING - Redeclared variable: self__
var self__ = this;
    ^^^^^^^^^^^^^

out/cljs/core.js:366: ERROR - variable process is undeclared
if((typeof process !== 'undefined') && (!((process.hrtime == null)))){
           ^^^^^^^

out/cljs/core.js:35941: ERROR - variable global is undeclared
return cljs.core.find_ns_obj_STAR_(global,segs);
                                   ^^^^^^

pesterhazy13:11:23

Adding --third_party gives me

out/goog/base.js:526: ERROR - Malformed goog.forwardDeclaration
goog.forwardDeclare('Document');
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

dnolen13:11:35

warnings you can ignore

dnolen13:11:13

for process you might need an extern, global might just be a bug?

dnolen13:11:46

Maybe we need to use goog.global instead

pesterhazy14:11:23

I'm trying to repro nikitonsky's issue by the way https://twitter.com/nikitonsky/status/933315653892820993

pesterhazy14:11:30

@dnolen does the CLJS compiler supply the --third_party flag? Any idea about the goog.forardDeclare issue?

dnolen14:11:45

--third_party thing sounds like something you could reproduce on your own though

dnolen14:11:03

and ask on the Closure mailing list if you can’t sort it out - they are responsive

tonsky14:11:37

I got stuck on ERROR - variable global is undeclared myself :(

pesterhazy14:11:00

fixed the global issue by going to that line and doing s/global/goog.global/

pesterhazy14:11:24

the process issue can be fixed by adding --closure_entry_point process.env

dnolen14:11:32

@pesterhazy feel free to file a ticket for goog.global thing

pesterhazy14:11:47

@dnolen will do

pesterhazy14:11:01

@tonsky when invoking adv compilation manually from the CLI, the compiled output works well

B("bug.core.aaa", function () {
    console.log("aaa start");
    document.querySelector("body").className = "+++aaa+++";

    return console.log("aaa end")
});
B("bug.core.bbb", function () {
    console.log("bbb\u00a0start");
    document.querySelector("body").className = "+++bbb+++";

    return console.log("bbb end")
});
B("bug.core.ccc", function () {
    console.log("ccc start");
    document.querySelector("body").className = "+++ccc+++";

    return console.log("ccc end")
});

pesterhazy14:11:24

must be something about the way cljs calls gcc

dnolen14:11:22

I’m very skeptical about such a conclusion still

dnolen14:11:53

need to be absolutely positive you’re comparing the same versions of GCC

dnolen14:11:06

and probably need to try a couple of other kinds of examples

pesterhazy14:11:08

I'm sure of that

pesterhazy14:11:21

but there could be other enviromental differences

dnolen14:11:22

you’re not using Lein or Boot or something else?

dnolen14:11:32

test like this should be manual JVM start only

tonsky14:11:36

I’ve tried with two GCC versions (one that comes with latest CLJS and october one)

pesterhazy14:11:43

yeah manual java call

tonsky14:11:32

the JS output that CLJS produces seems fine. But those lines do disappear after advanced compilation

tonsky14:11:04

so it must be GCC and magical set of options

tonsky14:11:41

except if CLJS runs its own pass over generated JS, which I doubt

dnolen14:11:00

another thing to wonder here is whether we somehow have a bad extern for document.querySelector

dnolen14:11:23

those lines would be eliminated only if Closure thought mutating the result of that fn was harmless

pesterhazy14:11:47

let me check if it works with a different function call

dnolen14:11:11

better yet just put a fn there that returns #js {}

dnolen14:11:16

and try that

tonsky14:11:54

I tried that, same result

tonsky14:11:05

but then for #js {} it is correct to remove mutations

rauh14:11:05

@tonsky I commented on the ticket. It's a known issue

tonsky14:11:29

because that obj would never be used anywhere

pesterhazy14:11:43

@rauh, could you link to the ticket?

dnolen14:11:51

oh sorry, I meant something like goog.global

dnolen14:11:53

@pesterhazy ah hm, that js/global is for bootstrapped

tonsky14:11:02

yep that’s it. Adding --jscomp_off=checkTypes enables elimination mode

tonsky14:11:52

the GCC issue doesn’t seem to be very active :(

pesterhazy14:11:30

tried it now, js/document.querySelector gets eliminated, js/document.querySelectorXXX doesn't

pesterhazy14:11:09

is there a reason for this difference?

pesterhazy14:11:18

As far as I know, goog/global works fine in node.js

tonsky14:11:19

Damn :closure-warnings {:check-types :warning} produces lots of noise :(

pesterhazy14:11:12

very strange that enabling warnings causes different code to be omitted

rauh14:11:42

Yeah this evals to true for me on nodejs: (identical? js/global goog.global)

dnolen14:11:05

@rauh ok good, then perhaps we just need a patch, bootstrap tests should catch any issues

dnolen14:11:36

@pesterhazy I think type checking feeds the compilation phases so Closure can do more

mfikes15:11:26

Yes, script/test-self-parity (which has *target* "nodejs") passes with the patch, making that call 108,914 times.