I actually realized that if I don’t do a clean before a regular compile, the
release is built from the modified JS files in the framework.
I moved "if (!goog.DEBUG)return;” to the very beginning of the function and
removed the @export tag. With that change, all traces of trace are removed.
(pun intended) ;-)
I think the takeaway should be that we should have some kind of metadata that
the compiler recognizes to not insert the @export tag and insert a bailout if
goog.DEBUG is false. That would allow us to define arbitrary functions to run
on a debug build and be automatically stripped out for release.
A @debug comment before the function declaration is probably the simplest
solution and fits with the current conventions.
I’m not sure what this would all look like for a swf compile.
Harbs
> On Jul 13, 2017, at 12:35 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> Bummer. It looks like you are using a custom template and I never tried
> that. I think you can just check for a null mainCU and get past that.
>
> On 7/12/17, 10:11 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> Maybe I’m doing something wrong, but I get the following error when I
>> tried using -skip-transpile:
>>
>> [java] java.lang.NullPointerException
>> org.apache.flex.compiler.internal.projects.FlexJSProject.computeTargetAttr
>> ibutes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.mx
>> ml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:554)o
>> rg.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.p
>> ublish(MXMLFlexJSPublisher.java:345)org.apache.flex.compiler.clients.MXMLJ
>> SCFlex.compile(MXMLJSCFlex.java:387)org.apache.flex.compiler.clients.MXMLJ
>> SCFlex._mainNoExit(MXMLJSCFlex.java:245)org.apache.flex.compiler.clients.M
>> XMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compiler.client
>> s.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.clients.MX
>> MLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clients.MXMLJSC
>> .staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.clients.MXMLJS
>> C.main(MXMLJSC.java:229)
>> [java]
>> [java]
>> [java] Java Result: 3
>>
>>> On Jul 12, 2017, at 7:48 PM, Alex Harui <aha...@adobe.com.INVALID>
>>> wrote:
>>>
>>> Trace supports multiple parameters and concatenates them with " "
>>> in-between.
>>>
>>> If you want to investigate more, you can use -sdk-js-lib to point to a
>>> hacked version of Language.js with goog.DEBUG around the "rest" code.
>>>
>>> I think you can also just modify what is in bin/js-debug and run the
>>> compiler with the -skip-transpile option and it won't re-transpile and
>>> just pass js-debug files to GCC and generate a new js-release output.
>>>
>>> -Alex
>>>
>>> On 7/12/17, 9:11 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>
>>>> That line was what was left of the trace function.
>>>>
>>>> The reason the trace function is not completely empty is because it has
>>>> this code generated from "…rest” at the start of the function:
>>>> rest = Array.prototype.slice.call(arguments, 0);
>>>>
>>>> I have no idea why that code is necessary. Maybe if it was not
>>>> generated
>>>> and the function was truly empty, the trace calls would be stripped out
>>>> as well?
>>>>
>>>> Leftover trace calls elsewhere in the code look something like this:
>>>> uM('unexpected condition in deferredBindingsHandler’);
>>>>
>>>>> On Jul 12, 2017, at 6:08 PM, Alex Harui <aha...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> If it were up to me, we'd strip traces based on the optimize compiler
>>>>> option. I think that's how it worked in the Flex SDK.
>>>>>
>>>>> I thought GCC had enough dead-code-removal logic to remove
>>>>> Language.trace
>>>>> once it saw that trace effectively did nothing.
>>>>>
>>>>> I can't seem to piece together from this thread what the original AS
>>>>> was
>>>>> and what the un-minified JS output was. Maybe there's something about
>>>>> the
>>>>> JS output that isn't right. It is strange to see the string name of
>>>>> the
>>>>> trace function.
>>>>>
>>>>> Regarding a logging system, I think folks are just used to trace and
>>>>> the
>>>>> cool thing about JS right now is that you can replace functions at
>>>>> runtime, so a logging bead would just replace Language.trace().
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 7/12/17, 6:44 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>>
>>>>>> Interesting scenarios. I would not have thought of that.
>>>>>>
>>>>>> If we could figure out how to strip the function call and leave the
>>>>>> parameter, the compiler would strip out the contents if it could be
>>>>>> safely removed.
>>>>>>
>>>>>> So trace(“something”) would become “something” which is en empty
>>>>>> statement and would be stripped out.
>>>>>>
>>>>>> Of course, I have no idea how to go about doing that… ;-)
>>>>>>
>>>>>> Harbs
>>>>>>
>>>>>>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <joshtynj...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Probably the same with function calls too:
>>>>>>>
>>>>>>> trace(someFunction());
>>>>>>>
>>>>>>> They wanted this to remain:
>>>>>>>
>>>>>>> someFunction();
>>>>>>>
>>>>>>> - Josh
>>>>>>>
>>>>>>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala
>>>>>>> <joshtynj...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> One thing to keep in mind with stripping out trace() calls is that
>>>>>>>> some
>>>>>>>> developers expect any modifications to variables that happen inside
>>>>>>>> the
>>>>>>>> arguments to remain. I remember a while back someone at Adobe
>>>>>>>> mentioning
>>>>>>>> that people complained when something like this was completely
>>>>>>>> stripped out:
>>>>>>>>
>>>>>>>> trace(doSomething++);
>>>>>>>>
>>>>>>>> Because they expected this part to remain:
>>>>>>>>
>>>>>>>> doSomething++;
>>>>>>>>
>>>>>>>> - Josh
>>>>>>>>
>>>>>>>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <harbs.li...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> My bad. It does in fact compile down to this:
>>>>>>>>>
>>>>>>>>> function
>>>>>>>>> uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>>>>>>>> e.flex.utils.Language.trace',uM);
>>>>>>>>>
>>>>>>>>> So trace does not actually do anything. Great! :-)
>>>>>>>>>
>>>>>>>>> However, it’s still being called by the client code. (It just does
>>>>>>>>> nothing.) Not super important, but it would be nice if at some
>>>>>>>>> point
>>>>>>>>> we can
>>>>>>>>> figure out if there’s a way to strip out the calls completely.
>>>>>>>>>
>>>>>>>>>> On Jul 12, 2017, at 10:07 AM, Harbs <harbs.li...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Oof. I think I’m still waking up. ;-)
>>>>>>>>>>
>>>>>>>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>>>>>>>> recollection is that trace statements are still being used in the
>>>>>>>>> release,
>>>>>>>>> but I’ll double check that.
>>>>>>>>>>
>>>>>>>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui
>>>>>>>>>>> <aha...@adobe.com.INVALID>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was to
>>>>>>>>> convince
>>>>>>>>>>> GCC to eliminate trace(). I haven't checked whether it is
>>>>>>>>>>> working
>>>>>>>>>>> or
>>>>>>>>> not.
>>>>>>>>>>> Requiring everyone to use goog.DEBUG around trace statements
>>>>>>>>>>> sounds
>>>>>>>>> like
>>>>>>>>>>> a pain. Probably better to teach the publisher to remove it if
>>>>>>>>>>> GCC
>>>>>>>>> can't
>>>>>>>>>>> be taught to do it. We visit almost every line of the JS output
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> publishers right now.
>>>>>>>>>>>
>>>>>>>>>>> My 2 cents,
>>>>>>>>>>> -Alex
>>>>>>>>>>>
>>>>>>>>>>> On 7/11/17, 11:47 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui
>>>>>>>>>>>>> <aha...@adobe.com.INVALID>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>>>>>>>
>>>>>>>>>>>> I completely agree. That’s why I have not been bringing this up
>>>>>>>>> despite
>>>>>>>>>>>> it being on my mind. When the discussion came up, I couldn’t
>>>>>>>>>>>> help
>>>>>>>>>>>> but
>>>>>>>>>>>> join. ;-)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks! I hadn’t noticed. I was missing an import of of
>>>>>>>>>>>> goog.DEBUG
>>>>>>>>>>>> in
>>>>>>>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and
>>>>>>>>>>>> goog.global
>>>>>>>>>>>> was
>>>>>>>>>>>> enough to make goog.DEBUG visible to the compiler in
>>>>>>>>>>>> Language.as.
>>>>>>>>>>>>
>>>>>>>>>>>> Once we’re on this topic, there’s something that I had wanted
>>>>>>>>>>>> to
>>>>>>>>> bring up
>>>>>>>>>>>> for a long time: I think trace statements should disappear in
>>>>>>>>>>>> the
>>>>>>>>> release
>>>>>>>>>>>> JS build. Should we put all the JS trace code inside an
>>>>>>>>>>>> if(goog.DEBUG)
>>>>>>>>>>>> block?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Harbs
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
