royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: GOOG::DEBUG
Date Wed, 12 Sep 2018 09:40:12 GMT
Sure. Good luck with the release process!

> On Sep 12, 2018, at 12:37 PM, Piotr Zarzycki <piotrzarzycki21@gmail.com> wrote:
> 
> Harbs,
> 
> Sorry I miss that email, so ignore last question in other thread!
> 
> Piotr
> 
> wt., 11 wrz 2018 o 20:36 Harbs <harbs.lists@gmail.com> napisał(a):
> 
>> OK. I reverted the rest param.
>> 
>> I’m now outputting rest = rest;if(!goog.DEBUG)return; instead of
>> if(!goog.DEBUG)return; if there’s a rest argument.
>> 
>> It’s a bit ugly, but it seems to make the closure compiler happy and gets
>> the desired result.
>> 
>> Thanks,
>> Harbs
>> 
>>> On Sep 10, 2018, at 6:52 AM, Alex Harui <aharui@adobe.com.INVALID>
>> wrote:
>>> 
>>> 
>>> 
>>> On 9/8/18, 10:05 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>>> 
>>>   I should have included a full explanation in my email.
>>> 
>>>   I tried {…*} but I got the same error as with {…}.
>>> 
>>>   {*} is not technically right as the arguments after the first is not
>> declared, but I tested trace with multiple arguments with the change and
>> the closure compiler did not complain. It’s the closest annotation I could
>> come up with that does not cause the error. (i.e. the first argument is
>> required) I can’t think of any downsides of leaving the rest of the
>> arguments out. Can you think of an issue with it?
>>> 
>>> If Closure Compiler did not notice that there were extra arguments, some
>> day they might fix it so it does notice.  We should annotate our code
>> correctly.
>>> 
>>>   Maybe a better fix is to update the closure compiler? Not sure…
>>> 
>>> IIRC, you recently added some code to the compiler to clean out empty
>> CSS selectors in release mode.  I wonder if there is a way to special case
>> trace and rewrite it in a way that Closure Compiler will know to remove
>> it.  Like remove every line of code or every line of code after the rest
>> handling.
>>> 
>>>   I just wanted to fix the build in the meantime.
>>> 
>>> I do not wish to see us release with the wrong annotations.  But feel
>> free to hack the final output code.
>>> 
>>>   Suggestions?
>>> 
>>>   Harbs
>>> 
>>>> On Sep 7, 2018, at 7:14 PM, Alex Harui <aharui@adobe.com.INVALID>
>> wrote:
>>>> 
>>>> The fix does not look right to me.  Here are a link that indicates that
>> variable number of arguments should be using "...".
>>>> 
>>>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler&amp;data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&amp;sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&amp;reserved=0
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler&amp;data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&amp;sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&amp;reserved=0
>>> 
>>>> 
>>>> This link indicates that the annotation for trace should be {...*}
>>>> 
>>>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F25474311%2Fannotating-zero-or-more-parameters-with-any-type-for-google-closure-compiler&amp;data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&amp;sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&amp;reserved=0
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F25474311%2Fannotating-zero-or-more-parameters-with-any-type-for-google-closure-compiler&amp;data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&amp;sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&amp;reserved=0
>>> 
>>>> 
>>>> What document led you to believe you could just use {*}, which
>> indicates only one parameter.
>>>> 
>>>> Thanks,
>>>> -Alex
>>>> 
>>>> On 9/7/18, 1:55 AM, "Harbs" <harbs.lists@gmail.com <mailto:
>> harbs.lists@gmail.com>> wrote:
>>>> 
>>>>  I just committed a fix for this.
>>>> 
>>>>  We can discuss further, but at least the build should work…
>>>> 
>>>>> On Sep 7, 2018, at 10:55 AM, Carlos Rovira <carlosrovira@apache.org>
>> wrote:
>>>>> 
>>>>> Right, I'm seeing as well JewelExample failing on compile
>>>>> 
>>>>> thanks
>>>>> 
>>>>> El vie., 7 sept. 2018 a las 9:13, Harbs (<harbs.lists@gmail.com>)
>> escribió:
>>>>> 
>>>>>> I’m saying that a param defined as {…} confuses the closure compiler
>> when
>>>>>> you have the rest redefined as an array anywhere but the first line
>> of the
>>>>>> function. It seems like a bug in the closure compiler.
>>>>>> 
>>>>>> Changing:
>>>>>> rest = Array.prototype.slice.call(arguments, 0);
>>>>>> to:
>>>>>> var rest = Array.prototype.slice.call(arguments, 0);
>>>>>> 
>>>>>> also makes the error go away, but we do get a reassignment warning.
>>>>>> 
>>>>>> I’m not sure what declaring a @param as {…} actually accomplishes
in
>> terms
>>>>>> of type checking.
>>>>>> 
>>>>>>> On Sep 7, 2018, at 10:02 AM, Alex Harui <aharui@adobe.com.INVALID>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Are you saying some recent change to the compiler is now generating:
>>>>>>> @param {...} rest
>>>>>>> 
>>>>>>> If so, what changed caused that output?  If not, why did it not
fail
>>>>>> before?
>>>>>>> 
>>>>>>> We should be generating whatever Google says we should generate
for
>> rest
>>>>>> parameters.  Although I did ponder the impact of having Royale's
>> trace not
>>>>>> take extra parameters.  Then folks would have to concat strings before
>>>>>> calling trace.
>>>>>>> 
>>>>>>> -Alex
>>>>>>> 
>>>>>>> On 9/6/18, 11:58 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>>>>> 
>>>>>>> It looks like the problem is caused by:
>>>>>>> * @param {...} rest
>>>>>>> 
>>>>>>> What would happen if we remove the @param or change it to @param
{*=}
>>>>>> rest?
>>>>>>> 
>>>>>>> Both of those work.
>>>>>>> 
>>>>>>>> On Sep 7, 2018, at 8:35 AM, Alex Harui <aharui@adobe.com.INVALID>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>> But first, I'm not sure your idea is going to work in all
cases.
>> See
>>>>>> if you get the same problem in JewelExample.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> --
>>>>> Carlos Rovira
>>>>> 
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&amp;sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&amp;reserved=0
>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&amp;sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&amp;reserved=0
>>> 
>>> 
>>> 
>> 
>> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*


Mime
View raw message