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