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 >
