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.computeTargetAttributes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:554)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.publish(MXMLFlexJSPublisher.java:345)org.apache.flex.compiler.clients.MXMLJSCFlex.compile(MXMLJSCFlex.java:387)org.apache.flex.compiler.clients.MXMLJSCFlex._mainNoExit(MXMLJSCFlex.java:245)org.apache.flex.compiler.clients.MXMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clients.MXMLJSC.staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.clients.MXMLJSC.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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>
