I'm unable to gather from this thread what code is being generated and
what errors are being generated when it doesn't work.
-Alex
On 7/12/17, 12:39 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>I tried on a simpler project and the only thing being output is a trace
>declaration with an empty function:
>u('org.apache.flex.utils.Language.trace',m());
>
>All calls to trace() are stripped out by the google compiler.
>
>This looks to be the case even without modifying the Language.trace
>output.
>
>FWIW, This is with -remove-circulars. When I tried to compile without
>-remove-circulars it had all kinds of runtime errors including calls to
>non-existent trace functions. I don’t know hwy. The project is really
>simple, and I’d think -remove-circulars should not be required.
>
>I have no idea why my more complex project outputs trace differently…
>
>Harbs
>
>> On Jul 12, 2017, at 8:11 PM, 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.computeTargetAtt
>>ributes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.
>>mxml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:55
>>4)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublish
>>er.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.cl
>>ients.MXMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compile
>>r.clients.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.c
>>lients.MXMLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clien
>>ts.MXMLJSC.staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.cli
>>ents.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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
