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