OK. I'll take a look at the failing test later.
Thanks again for working on this.
-Alex
On 3/22/17, 9:40 AM, "Greg Dove" wrote:
>Alex, I pushed this change, using undefined as discussed in the ticket.
>The standard compiler tests all pass, but there is, I think, an unrelated
>test
>in flexjs.
Alex, I pushed this change, using undefined as discussed in the ticket.
The standard compiler tests all pass, but there is, I think, an unrelated test
in flexjs.dependent.tests that is currently failing
in TestFlexJSMXMLApplication (I admit that I did not revert my change to
check it was occurring
On 3/20/17, 12:00 AM, "Greg Dove" wrote:
>I agree that 10 is wrong, but
>reading both AS and JS doc, I'm now thinking that if the second argument
>is missing that the compiler should use 0.
+1. Let's use 0.
Thanks for doing such a through investigation.
-Alex
HI,
> I agree that 10 is wrong
I assume you mean as a default?
Thanks,
Justin
I agree that 10 is wrong, but
reading both AS and JS doc, I'm now thinking that if the second argument
is missing that the compiler should use 0.
Please see the note in the comment of this ticket[1]:
We need to decide whether we should add undefined as the second param (it
seems this is the prefer
On 3/14/17, 11:17 PM, "Greg Dove" wrote:
>to clarify :
>
>I got the typedefs building eventually and compiling the single arg
>signature for partseInt is fine, but the compiler makes a fixed assumption
>for 10 radix for any string and adds that second param instead of allowing
>the native imple
to clarify :
I got the typedefs building eventually and compiling the single arg
signature for partseInt is fine, but the compiler makes a fixed assumption
for 10 radix for any string and adds that second param instead of allowing
the native implementation to do its thing.
If there are string for
On 3/14/17, 10:42 PM, "Greg Dove" wrote:
>On Wed, Mar 15, 2017 at 6:33 PM, Alex Harui wrote:
>
>> Here's a better link to the old thread. Looks like I did mess around
>>with
>> parseInt earlier.
>>
>> https://s.apache.org/rHq2
>>
>>
>> The goal is to match what AS does and get the performance
On Wed, Mar 15, 2017 at 6:33 PM, Alex Harui wrote:
> Here's a better link to the old thread. Looks like I did mess around with
> parseInt earlier.
>
> https://s.apache.org/rHq2
>
>
> The goal is to match what AS does and get the performance benefit you
> measured and maybe prevent browsers from
Here's a better link to the old thread. Looks like I did mess around with
parseInt earlier.
https://s.apache.org/rHq2
The goal is to match what AS does and get the performance benefit you
measured and maybe prevent browsers from doing something strange.
Hopefully it won't require sniffing the
>
> I'm not sure what you are referring to. I don't think the compiler
> currently supplies the second argument. I didn't think it was needed, but
> your tests indicate otherwise, so if that's what you are referring to,
> please file a JIRA so we don't forget to do it.
>
>
>
It seems it does - it
On 3/14/17, 10:05 PM, "Greg Dove" wrote:
> var test :String = "0x99"
>trace(parseInt(test));
>
>gives :
> var /** @type {string} */ test = "0x99";
> org.apache.flex.utils.Language.trace(parseInt(test, 10));
>
>which is wrong
>
>I can take a look at it this weekend if no-one else
If the compiler outputs 10 for everything then it is different to
actionscript which checks for "0x" and decides on 16 or 10
We can change the behaviour, but it won't be identical to :
"Strings beginning with 0x are interpreted as hexadecimal numbers"
Maybe it is better to not support '0x' strings
On 3/14/17, 10:02 PM, "Greg Dove" wrote:
>Actually I just checked and it looks like there is a bug in the compiler
>for this
I'm not sure what you are referring to. I don't think the compiler
currently supplies the second argument. I didn't think it was needed, but
your tests indicate otherw
var test :String = "0x99"
trace(parseInt(test));
gives :
var /** @type {string} */ test = "0x99";
org.apache.flex.utils.Language.trace(parseInt(test, 10));
which is wrong
I can take a look at it this weekend if no-one else gets to it
On Wed, Mar 15, 2017 at 6:02 PM, Greg Dove
On 3/14/17, 9:54 PM, "Greg Dove" wrote:
>Alex, I agree, it seems whatever prompted this was elsewhere, but the
>outcome is IMO (a small amount of) better framework code in CSSUtils.
>I would take this as a small win - nothing is broken, and a utility method
>is theoretically slightly faster.
I
On 3/14/17, 9:41 PM, "Justin Mclean" wrote:
>
>The current SDK code uses parseInt(number, “10”) in 29 different places.
>
>This line which I fixed, was the only instance of parseInt(number).
>
>Can you give a valid reason why I should revert it? So far I’m not seeing
>one.
Again, we should no
Actually I just checked and it looks like there is a bug in the compiler
for this
Greg Dove
Dove Software Development Ltd
http://greg-dove.com
On Wed, Mar 15, 2017 at 5:54 PM, Greg Dove wrote:
> Alex, I agree, it seems whatever prompted this was elsewhere, but the
> outcome is IMO (a small am
Alex, I agree, it seems whatever prompted this was elsewhere, but the
outcome is IMO (a small amount of) better framework code in CSSUtils.
I would take this as a small win - nothing is broken, and a utility method
is theoretically slightly faster.
On Wed, Mar 15, 2017 at 5:19 PM, Alex Harui wro
Hi,
> It would not be my recommendation to have us add default parameters to all
> of the places we could for "code clarity" or performance. Folks who write
> code in ActionScript should know or can find from the documentation that,
> for example, the second parameter to parseInt is optional and t
Thanks for running the test. Maybe I'm not understanding the issue, but
here's my summary.
Justin was getting a compile error where code that was known to work
wouldn't compile because there was only one argument passed to parseInt in
ActionScript source.
ActionScript defines parseInt as having
I think code clarity is one thing, but performance is another - that should
be faster, so I ran a quick check.
I know it can vary across browsers, but
var timeOne = function(){var d=new Date();var b=0; for (var
i=0;i<1000;i++) {b= parseInt(""+(127/255)*1000, 10) / 1000;}
console.log(new Date(
Hi,
> Please revert CSSUtils and investigate why parseInt is requiring the second
> argument.
Even if it is a typedef bug IMO passing the base there makes the code intent
clearer as the code is dealing with both base 16 and base 10 numbers.
This is the code in question:
public static f
Hmm. That would be a bug in the typedefs build. The Ant build attempts
to fix up parseInt to make the second parameter optional. AS developers
shouldn't have to add the second argument. Please revert CSSUtils and
investigate why parseInt is requiring the second argument.
It is strange that all
24 matches
Mail list logo
