You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Harbs <ha...@gmail.com> on 2018/09/06 21:13:20 UTC
GOOG::DEBUG
I see code like this in MXRoyale:
if (GOOG::DEBUG)
trace("get_uid not implemented");
I’m not aware of a reason to use compiler definitions for this.
trace statements get stripped out on release. Why do we need this?
Harbs
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
I also see ROYALE::DISPLAYOBJECT
What’s the deal with that?
> On Sep 7, 2018, at 12:13 AM, Harbs <ha...@gmail.com> wrote:
>
> I see code like this in MXRoyale:
>
> if (GOOG::DEBUG)
> trace("get_uid not implemented");
>
> I’m not aware of a reason to use compiler definitions for this.
>
> trace statements get stripped out on release. Why do we need this?
>
> Harbs
Re: GOOG::DEBUG
Posted by Carlos Rovira <ca...@apache.org>.
Equal, Good luck releasing! Waiting for it! And I see many people as well
waiting for 0.9.4! :))
El mié., 12 sept. 2018 a las 11:40, Harbs (<ha...@gmail.com>)
escribió:
> Sure. Good luck with the release process!
>
> > On Sep 12, 2018, at 12:37 PM, Piotr Zarzycki <pi...@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 <ha...@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 <ah...@adobe.com.INVALID>
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 9/8/18, 10:05 AM, "Harbs" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&reserved=0
> >> <
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&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 <ca...@apache.org>
> >> wrote:
> >>>>>
> >>>>> Right, I'm seeing as well JewelExample failing on compile
> >>>>>
> >>>>> thanks
> >>>>>
> >>>>> El vie., 7 sept. 2018 a las 9:13, Harbs (<ha...@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 <ah...@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" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0
> >> <
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0
> >>>
> >>>
> >>>
> >>
> >>
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
Sure. Good luck with the release process!
> On Sep 12, 2018, at 12:37 PM, Piotr Zarzycki <pi...@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 <ha...@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 <ah...@adobe.com.INVALID>
>> wrote:
>>>
>>>
>>>
>>> On 9/8/18, 10:05 AM, "Harbs" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&reserved=0
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&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 <ca...@apache.org>
>> wrote:
>>>>>
>>>>> Right, I'm seeing as well JewelExample failing on compile
>>>>>
>>>>> thanks
>>>>>
>>>>> El vie., 7 sept. 2018 a las 9:13, Harbs (<ha...@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 <ah...@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" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0
>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0
>>>
>>>
>>>
>>
>>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
Re: GOOG::DEBUG
Posted by Piotr Zarzycki <pi...@gmail.com>.
Harbs,
Sorry I miss that email, so ignore last question in other thread!
Piotr
wt., 11 wrz 2018 o 20:36 Harbs <ha...@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 <ah...@adobe.com.INVALID>
> wrote:
> >
> >
> >
> > On 9/8/18, 10:05 AM, "Harbs" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&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 <ca...@apache.org>
> wrote:
> >>>
> >>> Right, I'm seeing as well JewelExample failing on compile
> >>>
> >>> thanks
> >>>
> >>> El vie., 7 sept. 2018 a las 9:13, Harbs (<ha...@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 <ah...@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" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0
> >
> >
> >
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 9/8/18, 10:05 AM, "Harbs" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&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 <ma...@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 <ca...@apache.org> wrote:
>>>
>>> Right, I'm seeing as well JewelExample failing on compile
>>>
>>> thanks
>>>
>>> El vie., 7 sept. 2018 a las 9:13, Harbs (<ha...@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 <ah...@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" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0>
>
>
Re: GOOG::DEBUG
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 9/8/18, 10:05 AM, "Harbs" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&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 <ma...@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 <ca...@apache.org> wrote:
>>
>> Right, I'm seeing as well JewelExample failing on compile
>>
>> thanks
>>
>> El vie., 7 sept. 2018 a las 9:13, Harbs (<ha...@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 <ah...@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" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0>
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
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?
Maybe a better fix is to update the closure compiler? Not sure…
I just wanted to fix the build in the meantime.
Suggestions?
Harbs
> On Sep 7, 2018, at 7:14 PM, Alex Harui <ah...@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://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler <https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler>
>
> This link indicates that the annotation for trace should be {...*}
>
> https://stackoverflow.com/questions/25474311/annotating-zero-or-more-parameters-with-any-type-for-google-closure-compiler <https://stackoverflow.com/questions/25474311/annotating-zero-or-more-parameters-with-any-type-for-google-closure-compiler>
>
> 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 <ma...@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 <ca...@apache.org> wrote:
>>
>> Right, I'm seeing as well JewelExample failing on compile
>>
>> thanks
>>
>> El vie., 7 sept. 2018 a las 9:13, Harbs (<ha...@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 <ah...@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" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C2f5d8746f67b4b5ea95308d6149fad18%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636719073367810463&sdata=3n3iyay30uyD88Q2nQBGT0v4LnV9sEkRGPhdteCqvME%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2f5d8746f67b4b5ea95308d6149fad18%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636719073367810463&sdata=3n3iyay30uyD88Q2nQBGT0v4LnV9sEkRGPhdteCqvME%3D&reserved=0>
Re: GOOG::DEBUG
Posted by Alex Harui <ah...@adobe.com.INVALID>.
The fix does not look right to me. Here are a link that indicates that variable number of arguments should be using "...".
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler
This link indicates that the annotation for trace should be {...*}
https://stackoverflow.com/questions/25474311/annotating-zero-or-more-parameters-with-any-type-for-google-closure-compiler
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" <ha...@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 <ca...@apache.org> wrote:
>
> Right, I'm seeing as well JewelExample failing on compile
>
> thanks
>
> El vie., 7 sept. 2018 a las 9:13, Harbs (<ha...@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 <ah...@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" <ha...@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 <ah...@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&data=02%7C01%7Caharui%40adobe.com%7C2f5d8746f67b4b5ea95308d6149fad18%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636719073367810463&sdata=3n3iyay30uyD88Q2nQBGT0v4LnV9sEkRGPhdteCqvME%3D&reserved=0
Re: GOOG::DEBUG
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
maven if passing right now (the only think that broken now is the latest
commit to typedefs, that I have to remove locally).
Thanks!
El vie., 7 sept. 2018 a las 10:55, Harbs (<ha...@gmail.com>) escribió:
> 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 <ca...@apache.org>
> wrote:
> >
> > Right, I'm seeing as well JewelExample failing on compile
> >
> > thanks
> >
> > El vie., 7 sept. 2018 a las 9:13, Harbs (<ha...@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 <ah...@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" <ha...@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 <ah...@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
> > http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
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 <ca...@apache.org> wrote:
>
> Right, I'm seeing as well JewelExample failing on compile
>
> thanks
>
> El vie., 7 sept. 2018 a las 9:13, Harbs (<ha...@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 <ah...@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" <ha...@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 <ah...@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
> http://about.me/carlosrovira
Re: GOOG::DEBUG
Posted by Carlos Rovira <ca...@apache.org>.
Right, I'm seeing as well JewelExample failing on compile
thanks
El vie., 7 sept. 2018 a las 9:13, Harbs (<ha...@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 <ah...@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" <ha...@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 <ah...@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
http://about.me/carlosrovira
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ah...@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.
>
>
>
Re: GOOG::DEBUG
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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.
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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.
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
OK. I’ll look into it.
> On Sep 7, 2018, at 8:35 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> This seems to be causing problems. The JewelExample is failing. I think it doesn't like the early exit before the rest parameter is handled.
>
> I don't think we need to worry about this for SWF output.
>
> There is a way to suppress asdoc tags. It is JSClosureCompilerWrapper.java, but I'd prefer we pick a name prefixed with royale. @debug might get used by some other framework some day.
>
> But first, I'm not sure your idea is going to work in all cases. See if you get the same problem in JewelExample.
>
> Thanks,
> -Alex
>
> On 9/6/18, 3:53 PM, "Harbs" <ha...@gmail.com> wrote:
>
> Well, actually I was only focused o JS output.
>
> Not sure how to make this work for SWF output…
>
>> On Sep 7, 2018, at 1:41 AM, Harbs <ha...@gmail.com> wrote:
>>
>> I don’t know how to add a compiler test for this, but we now have a universal way of declaring a method debug-only.
>
>
>
Re: GOOG::DEBUG
Posted by Alex Harui <ah...@adobe.com.INVALID>.
This seems to be causing problems. The JewelExample is failing. I think it doesn't like the early exit before the rest parameter is handled.
I don't think we need to worry about this for SWF output.
There is a way to suppress asdoc tags. It is JSClosureCompilerWrapper.java, but I'd prefer we pick a name prefixed with royale. @debug might get used by some other framework some day.
But first, I'm not sure your idea is going to work in all cases. See if you get the same problem in JewelExample.
Thanks,
-Alex
On 9/6/18, 3:53 PM, "Harbs" <ha...@gmail.com> wrote:
Well, actually I was only focused o JS output.
Not sure how to make this work for SWF output…
> On Sep 7, 2018, at 1:41 AM, Harbs <ha...@gmail.com> wrote:
>
> I don’t know how to add a compiler test for this, but we now have a universal way of declaring a method debug-only.
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
Well, actually I was only focused o JS output.
Not sure how to make this work for SWF output…
> On Sep 7, 2018, at 1:41 AM, Harbs <ha...@gmail.com> wrote:
>
> I don’t know how to add a compiler test for this, but we now have a universal way of declaring a method debug-only.
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
To be clear, I meant that all trace statements in an app (or framework code) is completely removed.
The trace statement itself exists in the following form:
x('org.apache.royale.utils.Language.trace',q());
This returns an empty function. Presumably this is because the method is exported.
Interestingly, my app has 919 assignments of q(). It looks like the vast majority of them are in interface classes.
> On Sep 7, 2018, at 1:41 AM, Harbs <ha...@gmail.com> wrote:
>
> I tested and all uses are now removed.
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
I just added a compiler feature to support @debug comments.
This causes the good.DEBUG bail-out to be added at the top of the method.
I tested and all uses are now removed.
I don’t know how to add a compiler test for this, but we now have a universal way of declaring a method debug-only.
The only issue I see is that we get this warning from the google compiler:
WARNING - Parse error. illegal use of unknown JSDoc tag "debug"; ignoring it
* @debug
^
Any suggestions on how to get rid of that warning?
Harbs
> On Sep 7, 2018, at 12:32 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Yeah, I think I saw that so I opted to try to use GOOG::DEBUG to eliminate the trace in the method body.
>
> ROYALE::DISPLAYOBJECT is some other substitution that helps with code clarity, although there is a chance it isn't needed anymore.
>
> -Alex
>
> On 9/6/18, 2:29 PM, "Harbs" <ha...@gmail.com> wrote:
>
> In practice this is not quite happening because trace is output like this:
>
> org.apache.royale.utils.Language.trace = function(rest) {
> rest = Array.prototype.slice.call(arguments, 0);
> var /** @type {*} */ theConsole;
> if (!goog.DEBUG)
> return;
> theConsole = goog.global["console"];
> if (theConsole === undefined) {
> if (typeof(window) !== "undefined") {
> theConsole = window.console;
> } else if (typeof(console) !== "undefined") {
> theConsole = console;
> }
> }
> try {
> if (theConsole && theConsole.log) {
> theConsole.log.apply(theConsole, rest);
> }
> } catch (e) {
> }
> };
>
> The first line does not get stripped out. If we could output that line after the good.DEBUG check, it would get completely stripped out…
>
> org.apache.royale.utils.Language.trace = function(rest) {
> if (!goog.DEBUG)
> return;
> rest = Array.prototype.slice.call(arguments, 0);
> var /** @type {*} */ theConsole;
> theConsole = goog.global["console"];
> if (theConsole === undefined) {
> if (typeof(window) !== "undefined") {
> theConsole = window.console;
> } else if (typeof(console) !== "undefined") {
> theConsole = console;
> }
> }
> try {
> if (theConsole && theConsole.log) {
> theConsole.log.apply(theConsole, rest);
> }
> } catch (e) {
> }
> };
>
> I wonder if we should add a @debug comment to methods which would cause the compiler to automatically add if(!goog.DEBUG)return; to the first line of the function…
>
> Harbs
>
>
>> On Sep 7, 2018, at 12:20 AM, Harbs <ha...@gmail.com> wrote:
>>
>> Language.trace has this at the beginning of the method:
>>
>> if (!goog.DEBUG) return;
>>
>> That should cause the google compiler to optimize out the entire function call.
>>
>>> On Sep 7, 2018, at 12:15 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> How do trace statements get removed from function bodies in release mode?
>>>
>>> On 9/6/18, 2:13 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> I see code like this in MXRoyale:
>>>
>>> if (GOOG::DEBUG)
>>> trace("get_uid not implemented");
>>>
>>> I’m not aware of a reason to use compiler definitions for this.
>>>
>>> trace statements get stripped out on release. Why do we need this?
>>>
>>> Harbs
>>>
>>
>
>
>
Re: GOOG::DEBUG
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Yeah, I think I saw that so I opted to try to use GOOG::DEBUG to eliminate the trace in the method body.
ROYALE::DISPLAYOBJECT is some other substitution that helps with code clarity, although there is a chance it isn't needed anymore.
-Alex
On 9/6/18, 2:29 PM, "Harbs" <ha...@gmail.com> wrote:
In practice this is not quite happening because trace is output like this:
org.apache.royale.utils.Language.trace = function(rest) {
rest = Array.prototype.slice.call(arguments, 0);
var /** @type {*} */ theConsole;
if (!goog.DEBUG)
return;
theConsole = goog.global["console"];
if (theConsole === undefined) {
if (typeof(window) !== "undefined") {
theConsole = window.console;
} else if (typeof(console) !== "undefined") {
theConsole = console;
}
}
try {
if (theConsole && theConsole.log) {
theConsole.log.apply(theConsole, rest);
}
} catch (e) {
}
};
The first line does not get stripped out. If we could output that line after the good.DEBUG check, it would get completely stripped out…
org.apache.royale.utils.Language.trace = function(rest) {
if (!goog.DEBUG)
return;
rest = Array.prototype.slice.call(arguments, 0);
var /** @type {*} */ theConsole;
theConsole = goog.global["console"];
if (theConsole === undefined) {
if (typeof(window) !== "undefined") {
theConsole = window.console;
} else if (typeof(console) !== "undefined") {
theConsole = console;
}
}
try {
if (theConsole && theConsole.log) {
theConsole.log.apply(theConsole, rest);
}
} catch (e) {
}
};
I wonder if we should add a @debug comment to methods which would cause the compiler to automatically add if(!goog.DEBUG)return; to the first line of the function…
Harbs
> On Sep 7, 2018, at 12:20 AM, Harbs <ha...@gmail.com> wrote:
>
> Language.trace has this at the beginning of the method:
>
> if (!goog.DEBUG) return;
>
> That should cause the google compiler to optimize out the entire function call.
>
>> On Sep 7, 2018, at 12:15 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> How do trace statements get removed from function bodies in release mode?
>>
>> On 9/6/18, 2:13 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I see code like this in MXRoyale:
>>
>> if (GOOG::DEBUG)
>> trace("get_uid not implemented");
>>
>> I’m not aware of a reason to use compiler definitions for this.
>>
>> trace statements get stripped out on release. Why do we need this?
>>
>> Harbs
>>
>
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
In practice this is not quite happening because trace is output like this:
org.apache.royale.utils.Language.trace = function(rest) {
rest = Array.prototype.slice.call(arguments, 0);
var /** @type {*} */ theConsole;
if (!goog.DEBUG)
return;
theConsole = goog.global["console"];
if (theConsole === undefined) {
if (typeof(window) !== "undefined") {
theConsole = window.console;
} else if (typeof(console) !== "undefined") {
theConsole = console;
}
}
try {
if (theConsole && theConsole.log) {
theConsole.log.apply(theConsole, rest);
}
} catch (e) {
}
};
The first line does not get stripped out. If we could output that line after the good.DEBUG check, it would get completely stripped out…
org.apache.royale.utils.Language.trace = function(rest) {
if (!goog.DEBUG)
return;
rest = Array.prototype.slice.call(arguments, 0);
var /** @type {*} */ theConsole;
theConsole = goog.global["console"];
if (theConsole === undefined) {
if (typeof(window) !== "undefined") {
theConsole = window.console;
} else if (typeof(console) !== "undefined") {
theConsole = console;
}
}
try {
if (theConsole && theConsole.log) {
theConsole.log.apply(theConsole, rest);
}
} catch (e) {
}
};
I wonder if we should add a @debug comment to methods which would cause the compiler to automatically add if(!goog.DEBUG)return; to the first line of the function…
Harbs
> On Sep 7, 2018, at 12:20 AM, Harbs <ha...@gmail.com> wrote:
>
> Language.trace has this at the beginning of the method:
>
> if (!goog.DEBUG) return;
>
> That should cause the google compiler to optimize out the entire function call.
>
>> On Sep 7, 2018, at 12:15 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> How do trace statements get removed from function bodies in release mode?
>>
>> On 9/6/18, 2:13 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I see code like this in MXRoyale:
>>
>> if (GOOG::DEBUG)
>> trace("get_uid not implemented");
>>
>> I’m not aware of a reason to use compiler definitions for this.
>>
>> trace statements get stripped out on release. Why do we need this?
>>
>> Harbs
>>
>
Re: GOOG::DEBUG
Posted by Harbs <ha...@gmail.com>.
Language.trace has this at the beginning of the method:
if (!goog.DEBUG) return;
That should cause the google compiler to optimize out the entire function call.
> On Sep 7, 2018, at 12:15 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> How do trace statements get removed from function bodies in release mode?
>
> On 9/6/18, 2:13 PM, "Harbs" <ha...@gmail.com> wrote:
>
> I see code like this in MXRoyale:
>
> if (GOOG::DEBUG)
> trace("get_uid not implemented");
>
> I’m not aware of a reason to use compiler definitions for this.
>
> trace statements get stripped out on release. Why do we need this?
>
> Harbs
>
Re: GOOG::DEBUG
Posted by Alex Harui <ah...@adobe.com.INVALID>.
How do trace statements get removed from function bodies in release mode?
On 9/6/18, 2:13 PM, "Harbs" <ha...@gmail.com> wrote:
I see code like this in MXRoyale:
if (GOOG::DEBUG)
trace("get_uid not implemented");
I’m not aware of a reason to use compiler definitions for this.
trace statements get stripped out on release. Why do we need this?
Harbs