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 ()
escribió:
> Sure. Good luck with the release process!
>
> > On Sep 12, 2018, at 12:37 PM, Piotr Zarzycki
> wrote:
> >
> > Harbs,
> >
> > Sorry I miss
Sure. Good luck with the release process!
> On Sep 12, 2018, at 12:37 PM, Piotr Zarzycki
> wrote:
>
> Harbs,
>
> Sorry I miss that email, so ignore last question in other thread!
>
> Piotr
>
> wt., 11 wrz 2018 o 20:36 Harbs napisał(a):
>
>> OK. I reverted the rest param.
>>
>> I’m now
Harbs,
Sorry I miss that email, so ignore last question in other thread!
Piotr
wt., 11 wrz 2018 o 20:36 Harbs 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
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
On 9/8/18, 10:05 AM, "Harbs" 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
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 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 {...*}
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 () escribió:
> I just committed a fix for this.
>
> We can discuss further, but at least the build should work…
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 wrote:
>
> Right, I'm seeing as well JewelExample failing on compile
>
> thanks
>
> El vie., 7 sept. 2018 a las 9:13, Harbs () escribió:
>
>> I’m saying
Right, I'm seeing as well JewelExample failing on compile
thanks
El vie., 7 sept. 2018 a las 9:13, Harbs () 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
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 =
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
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 wrote:
>
> But first, I'm not sure your idea is going to work in all cases. See if you
> get
OK. I’ll look into it.
> On Sep 7, 2018, at 8:35 AM, Alex Harui 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
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
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 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.
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.
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
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&qu
> call.
>
>> On Sep 7, 2018, at 12:15 AM, Alex Harui wrote:
>>
>> How do trace statements get removed from function bodies in release mode?
>>
>> On 9/6/18, 2:13 PM, "Harbs" wrote:
>>
>> I see code like this in MXRoyale:
>&g
I also see ROYALE::DISPLAYOBJECT
What’s the deal with that?
> On Sep 7, 2018, at 12:13 AM, Harbs wrote:
>
> I see code like this in MXRoyale:
>
> if (GOOG::DEBUG)
> trace("get_uid not implemented");
>
>
How do trace statements get removed from function bodies in release mode?
On 9/6/18, 2:13 PM, "Harbs" wrote:
I see code like this in MXRoyale:
if (GOOG::DEBUG)
trace("get_uid not implemented");
I’m n
22 matches
Mail list logo
