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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
