Closure compiler CompilationLevel

[Josh Tynjala <jo...@gmail.com>]

The Closure compiler has three compilation levels.

CompilationLevel.WHITESPACE_ONLY
CompilationLevel.SIMPLE_OPTIMIZATIONS
CompilationLevel.ADVANCED_OPTIMIZATIONS

Right now, JSClosureCompilerWrapper specifies the ADVANCED_OPTIMIZATIONS
compilation level. This level changes the code the most, but it can also be
the most, well, destructive.

Unfortunately, the files in js-release have never worked for one of my
projects because my projects need to call out to external libraries. The
Closure compiler supports passing in externs files to preserve the right
API names for external libraries, of course. I don't actually know if
FlexJS exposes the ability to pass in externs at this point in the
compilation process (I know externc uses externs files, obviously).
However, I'd rather not need to do that regardless. It's a pretty demanding
requirement, in my opinion. I think it adds a barrier to entry, and if
supported, it should be opt-in.

I tried creating a build that used SIMPLE_OPTIMIZATIONS instead. It worked
a little bit better. It was able to call out to external libraries, but
some things weren't clearly broken in the browser. Unfortunately, the
browser console did not show any runtime errors, so it's hard to say what
broke without some serious debugging. It seems that Closure compiler's
optimizations are still somewhat destructive at the SIMPLE_OPTIMIZATIONS
level.

When I created a build that used WHITESPACE_ONLY, everything worked as
expected. I personally think that WHITESPACE_ONLY should be the default in
JSClosureCompilerWrapper. This compilation level still minifies the code,
which is what we care about the most for a release build. Most JS
developers don't do more than basic minimization, as I've come to
understand it. The more advanced stuff that the Closure compiler does is
more out of the ordinary. Probably due to the potential for breaking
things. I remember when I worked at Yahoo, the recommended best practice
was to avoid renaming things during minification.

Can we change JSClosureCompilerWrapper to use WHITESPACE_ONLY instead?

- Josh

Re: Closure compiler CompilationLevel

[Andy Dufilie <an...@gmail.com>]

On Thu, Dec 31, 2015 at 12:17 PM, Josh Tynjala <jo...@gmail.com>
wrote:

> You might try using asjsc instead of mxmlc if you want to compile with
> JS.swc.
>
> - Josh
>

I had tried that before through Flash Builder but it was giving me an error
("Unsupported major.minor version 51.0").  I looked at it again and found
out that I had to manually change FlashBuilder.ini to point to a newer JDK.
It's working for me now. In case anyone else has this problem, here's what
I added to FlashBuilder.ini:
-vm
C:\Program Files\Java\jdk1.8.0_60\bin\javaw.exe

Now that I can compile with js.swc, I am getting a lot of errors because
the type information for many JS functions is incorrect. For example, it
says Array's sort() is a void function. Where is the source code for js.swc
so that I can contribute fixes?

Re: Closure compiler CompilationLevel

[Josh Tynjala <jo...@gmail.com>]

You might try using asjsc instead of mxmlc if you want to compile with
JS.swc.

- Josh
On Dec 30, 2015 10:32 PM, "Andy Dufilie" <an...@gmail.com> wrote:

> On Wed, Dec 30, 2015 at 1:05 PM, Alex Harui <ah...@adobe.com> wrote:
>
> > Try: -js-compiler-option="--compilation_level WHITESPACE_ONLY"
>
>
> That worked after fixing the special characters. Is there a place that
> options like this are documented?
>
> Now that I'm compiling via flexjs/js/bin/mxmlc using the WHITESPACE_ONLY
> option, I get an error in bin/js-release/index.html when it tries to load a
> deps.js that doesn't exist.  Based on what I've seen online, the only way
> to avoid this error is to define a var before the base.js code runs, such
> as adding the following script tag in the generated index.html:
>     <script>var CLOSURE_NO_DEPS = true;</script>
> The other option that seems like it should work is to provide an additional
> js file to the closure compiler containing this var, but when I try the
> following, it doesn't include my code:
>     -js-compiler-option="--js C:/path/to/myfile.js"
> Shouldn't that work? Is there another way to include JS sources?
>
> A few more questions:
>
> - When I run flexjs/js/bin/compc I get a bin-release folder with the JS
> output files.  I then try to run closure manually on these files, and I get
> circular dependency errors for my code that do not appear when using
> flexjs/js/bin/mxmlc. Is there an additional step that happens behind the
> scenes, removing circular dependencies?
>
> - Is there a way that I can see exactly what parameters flexjs/js/bin/mxmlc
> is passing to the closure compiler?
>
> - Is there a documented way to use js.swc instead of playerglobal.swc?
>

Re: Closure compiler CompilationLevel

[Alex Harui <ah...@adobe.com>]

On 12/30/15, 10:31 PM, "Andy Dufilie" <an...@gmail.com> wrote:

>On Wed, Dec 30, 2015 at 1:05 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> Try: -js-compiler-option="--compilation_level WHITESPACE_ONLY"
>
>
>That worked after fixing the special characters. Is there a place that
>options like this are documented?

Hmm.  I guess not.  Using --help doesn’t work and FalconJX-specific
options don't show up in the Falcon help.  I suppose we should make that
work at some point.

>
>Now that I'm compiling via flexjs/js/bin/mxmlc using the WHITESPACE_ONLY
>option, I get an error in bin/js-release/index.html when it tries to load
>a
>deps.js that doesn't exist.  Based on what I've seen online, the only way
>to avoid this error is to define a var before the base.js code runs, such
>as adding the following script tag in the generated index.html:
>    <script>var CLOSURE_NO_DEPS = true;</script>
>The other option that seems like it should work is to provide an
>additional
>js file to the closure compiler containing this var, but when I try the
>following, it doesn't include my code:
>    -js-compiler-option="--js C:/path/to/myfile.js"
>Shouldn't that work? Is there another way to include JS sources?

Under the hood, FalconJX calls the Java APIs for Google Closure Compiler.
We don't pass it a command line.  So some options like the set of files
are computed and can't currently be dictated via -js-compiler-options.
Patches are welcome to make that work.

>
>A few more questions:
>
>- When I run flexjs/js/bin/compc I get a bin-release folder with the JS
>output files.  I then try to run closure manually on these files, and I
>get
>circular dependency errors for my code that do not appear when using
>flexjs/js/bin/mxmlc. Is there an additional step that happens behind the
>scenes, removing circular dependencies?

Yes.  GoogDepsWriter does that.  Unless you are porting existing libraries
and it is important to retain the APIs, you might want to consider
designing libraries to not have circular dependencies.  I don't want to
make that a hard rule so we try to handle circularities, and there is an
open JIRA to try a more sophisticated scheme of handling circularities.

>
>- Is there a way that I can see exactly what parameters
>flexjs/js/bin/mxmlc
>is passing to the closure compiler?

The JSClosureCompilerWrapper.java file and MXMLFlexJSPublisher.java set up
the call to the Google Closure Compiler.  As I mentioned above, we are
using the Java APIs so there isn't a command-line.

>
>- Is there a documented way to use js.swc instead of playerglobal.swc?

I don't think we have much documentation.  In examples/native you can see
how it is used.  Maybe that will help.

Thanks for all the bugs, patches and questions!  They really are
appreciated.

-Alex

Re: Closure compiler CompilationLevel

[Andy Dufilie <an...@gmail.com>]

On Wed, Dec 30, 2015 at 1:05 PM, Alex Harui <ah...@adobe.com> wrote:

> Try: -js-compiler-option="--compilation_level WHITESPACE_ONLY"


That worked after fixing the special characters. Is there a place that
options like this are documented?

Now that I'm compiling via flexjs/js/bin/mxmlc using the WHITESPACE_ONLY
option, I get an error in bin/js-release/index.html when it tries to load a
deps.js that doesn't exist.  Based on what I've seen online, the only way
to avoid this error is to define a var before the base.js code runs, such
as adding the following script tag in the generated index.html:
    <script>var CLOSURE_NO_DEPS = true;</script>
The other option that seems like it should work is to provide an additional
js file to the closure compiler containing this var, but when I try the
following, it doesn't include my code:
    -js-compiler-option="--js C:/path/to/myfile.js"
Shouldn't that work? Is there another way to include JS sources?

A few more questions:

- When I run flexjs/js/bin/compc I get a bin-release folder with the JS
output files.  I then try to run closure manually on these files, and I get
circular dependency errors for my code that do not appear when using
flexjs/js/bin/mxmlc. Is there an additional step that happens behind the
scenes, removing circular dependencies?

- Is there a way that I can see exactly what parameters flexjs/js/bin/mxmlc
is passing to the closure compiler?

- Is there a documented way to use js.swc instead of playerglobal.swc?

Re: Closure compiler CompilationLevel

[Alex Harui <ah...@adobe.com>]

Try: -js-compiler-option=“—compilation_level WHITESPACE_ONLY”



On 12/30/15, 9:28 AM, "adufilie" <an...@gmail.com> wrote:

>The forum formatting in my previous message caused part of the text to be
>omitted on the mailing list. The full message is below. If the forum
>interface happens to omit the quoted text then I apologize in advance.
>
>
>adufilie wrote
>> Is there a way to do this yet? I'm having the same problem - I want to
>>be
>> able to specify the compilation level as WHITESPACE_ONLY.  I saw
>>reference
>> to "js-closure-compilation-level"
>> in the code
>> 
>><https://github.com/apache/flex-falcon/search?utf8=%E2%9C%93&q=js-closure
>>-compilation-level>
>> , so I tried adding -js-closure-compilation-level=WHITESPACE_ONLY to my
>> mxmlc build command.  This is the result:
>
>using FlashBuilder Project Files
>FlashBuilder settings:
>    -locale
>    en_US
>    -source-path+=C:\Weave\WeaveJS/src
>    -output=C:\Weave\WeaveJS/bin-release/WeaveJS.swf
>    -js-output-type=FLEXJS
>    -sdk-js-lib=C:\flexjs\js\bin\..\..\frameworks\js\FlexJS\src
>    -js-closure-compilation-level=WHITESPACE_ONLY
>    -fb
>    C:\Weave\WeaveJS/src/WeaveJS.as
>command line
>unknown configuration variable 'js-closure-compilation-level'.
>
>
>
>
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/Closure-compiler-Comp
>ilationLevel-tp49289p50866.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Closure compiler CompilationLevel

[adufilie <an...@gmail.com>]

The forum formatting in my previous message caused part of the text to be
omitted on the mailing list. The full message is below. If the forum
interface happens to omit the quoted text then I apologize in advance.


adufilie wrote
> Is there a way to do this yet? I'm having the same problem - I want to be
> able to specify the compilation level as WHITESPACE_ONLY.  I saw reference
> to "js-closure-compilation-level" 
> in the code
> <https://github.com/apache/flex-falcon/search?utf8=%E2%9C%93&q=js-closure-compilation-level>  
> , so I tried adding -js-closure-compilation-level=WHITESPACE_ONLY to my
> mxmlc build command.  This is the result:

using FlashBuilder Project Files
FlashBuilder settings:
    -locale
    en_US
    -source-path+=C:\Weave\WeaveJS/src
    -output=C:\Weave\WeaveJS/bin-release/WeaveJS.swf
    -js-output-type=FLEXJS
    -sdk-js-lib=C:\flexjs\js\bin\..\..\frameworks\js\FlexJS\src
    -js-closure-compilation-level=WHITESPACE_ONLY
    -fb
    C:\Weave\WeaveJS/src/WeaveJS.as
command line
unknown configuration variable 'js-closure-compilation-level'.




--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Closure-compiler-CompilationLevel-tp49289p50866.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Closure compiler CompilationLevel

[adufilie <an...@gmail.com>]

Is there a way to do this yet? I'm having the same problem - I want to be
able to specify the compilation level as WHITESPACE_ONLY.  I saw reference
to "js-closure-compilation-level"  in the code
<https://github.com/apache/flex-falcon/search?utf8=%E2%9C%93&q=js-closure-compilation-level> 
, so I tried adding -js-closure-compilation-level=WHITESPACE_ONLY to my
mxmlc build command.  This is the result:





--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Closure-compiler-CompilationLevel-tp49289p50865.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Closure compiler CompilationLevel

[Josh Tynjala <jo...@gmail.com>]

I think a prefix is acceptable.

- Josh

On Tue, Sep 22, 2015 at 8:34 AM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 9/22/15, 7:25 AM, "Josh Tynjala" <jo...@gmail.com> wrote:
>
> >No, this particular option of the Closure compiler is currently
> >hard-coded.
> >
> >As for making it a compile-time option, we should keep in mind that not
> >all
> >emitters will necessarily use Closure compiler in the future. This may
> >affect how the option should be named, or how it gets parsed and validated
> >in the compiler code.
>
> Yep, but IMO, rather than choosing a compilation level, we should make it
> possible to control “every” GCC option.  Not sure how, so feel free to
> turn this into a discussion on that topic.
>
> We could prefix all GCC options with -gcc.
> We could make you specify GCC options in a gcc-compile.config.xml file.
> Others?
>
> Thanks,
> -Alex
>
>

Re: Closure compiler CompilationLevel

[Alex Harui <ah...@adobe.com>]

On 9/22/15, 7:25 AM, "Josh Tynjala" <jo...@gmail.com> wrote:

>No, this particular option of the Closure compiler is currently
>hard-coded.
>
>As for making it a compile-time option, we should keep in mind that not
>all
>emitters will necessarily use Closure compiler in the future. This may
>affect how the option should be named, or how it gets parsed and validated
>in the compiler code.

Yep, but IMO, rather than choosing a compilation level, we should make it
possible to control “every” GCC option.  Not sure how, so feel free to
turn this into a discussion on that topic.

We could prefix all GCC options with -gcc.
We could make you specify GCC options in a gcc-compile.config.xml file.
Others?

Thanks,
-Alex

Re: Closure compiler CompilationLevel

[Josh Tynjala <jo...@gmail.com>]

No, this particular option of the Closure compiler is currently hard-coded.

As for making it a compile-time option, we should keep in mind that not all
emitters will necessarily use Closure compiler in the future. This may
affect how the option should be named, or how it gets parsed and validated
in the compiler code.

- Josh
On Sep 22, 2015 1:59 AM, "Harbs" <ha...@gmail.com> wrote:

> Makes sense to me. Of course I have not deep-dived into this stuff yet.
>
> It seems to me that these levels should be a compile-time option which
> could be easily changed. Is that the case now?
>
> Harbs
>
> On Sep 22, 2015, at 9:37 AM, Josh Tynjala <jo...@gmail.com> wrote:
>
> > The Closure compiler has three compilation levels.
> >
> > CompilationLevel.WHITESPACE_ONLY
> > CompilationLevel.SIMPLE_OPTIMIZATIONS
> > CompilationLevel.ADVANCED_OPTIMIZATIONS
> >
> > Right now, JSClosureCompilerWrapper specifies the ADVANCED_OPTIMIZATIONS
> > compilation level. This level changes the code the most, but it can also
> be
> > the most, well, destructive.
> >
> > Unfortunately, the files in js-release have never worked for one of my
> > projects because my projects need to call out to external libraries. The
> > Closure compiler supports passing in externs files to preserve the right
> > API names for external libraries, of course. I don't actually know if
> > FlexJS exposes the ability to pass in externs at this point in the
> > compilation process (I know externc uses externs files, obviously).
> > However, I'd rather not need to do that regardless. It's a pretty
> demanding
> > requirement, in my opinion. I think it adds a barrier to entry, and if
> > supported, it should be opt-in.
> >
> > I tried creating a build that used SIMPLE_OPTIMIZATIONS instead. It
> worked
> > a little bit better. It was able to call out to external libraries, but
> > some things weren't clearly broken in the browser. Unfortunately, the
> > browser console did not show any runtime errors, so it's hard to say what
> > broke without some serious debugging. It seems that Closure compiler's
> > optimizations are still somewhat destructive at the SIMPLE_OPTIMIZATIONS
> > level.
> >
> > When I created a build that used WHITESPACE_ONLY, everything worked as
> > expected. I personally think that WHITESPACE_ONLY should be the default
> in
> > JSClosureCompilerWrapper. This compilation level still minifies the code,
> > which is what we care about the most for a release build. Most JS
> > developers don't do more than basic minimization, as I've come to
> > understand it. The more advanced stuff that the Closure compiler does is
> > more out of the ordinary. Probably due to the potential for breaking
> > things. I remember when I worked at Yahoo, the recommended best practice
> > was to avoid renaming things during minification.
> >
> > Can we change JSClosureCompilerWrapper to use WHITESPACE_ONLY instead?
> >
> > - Josh
>
>

Re: Closure compiler CompilationLevel

[Harbs <ha...@gmail.com>]

Makes sense to me. Of course I have not deep-dived into this stuff yet.

It seems to me that these levels should be a compile-time option which could be easily changed. Is that the case now?

Harbs

On Sep 22, 2015, at 9:37 AM, Josh Tynjala <jo...@gmail.com> wrote:

> The Closure compiler has three compilation levels.
> 
> CompilationLevel.WHITESPACE_ONLY
> CompilationLevel.SIMPLE_OPTIMIZATIONS
> CompilationLevel.ADVANCED_OPTIMIZATIONS
> 
> Right now, JSClosureCompilerWrapper specifies the ADVANCED_OPTIMIZATIONS
> compilation level. This level changes the code the most, but it can also be
> the most, well, destructive.
> 
> Unfortunately, the files in js-release have never worked for one of my
> projects because my projects need to call out to external libraries. The
> Closure compiler supports passing in externs files to preserve the right
> API names for external libraries, of course. I don't actually know if
> FlexJS exposes the ability to pass in externs at this point in the
> compilation process (I know externc uses externs files, obviously).
> However, I'd rather not need to do that regardless. It's a pretty demanding
> requirement, in my opinion. I think it adds a barrier to entry, and if
> supported, it should be opt-in.
> 
> I tried creating a build that used SIMPLE_OPTIMIZATIONS instead. It worked
> a little bit better. It was able to call out to external libraries, but
> some things weren't clearly broken in the browser. Unfortunately, the
> browser console did not show any runtime errors, so it's hard to say what
> broke without some serious debugging. It seems that Closure compiler's
> optimizations are still somewhat destructive at the SIMPLE_OPTIMIZATIONS
> level.
> 
> When I created a build that used WHITESPACE_ONLY, everything worked as
> expected. I personally think that WHITESPACE_ONLY should be the default in
> JSClosureCompilerWrapper. This compilation level still minifies the code,
> which is what we care about the most for a release build. Most JS
> developers don't do more than basic minimization, as I've come to
> understand it. The more advanced stuff that the Closure compiler does is
> more out of the ordinary. Probably due to the potential for breaking
> things. I remember when I worked at Yahoo, the recommended best practice
> was to avoid renaming things during minification.
> 
> Can we change JSClosureCompilerWrapper to use WHITESPACE_ONLY instead?
> 
> - Josh