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 of this is working on builds.a.o.
In flex-typedefs, the generated parseint.as should look like:
public function parseInt(num:*, base:Number = 0):Number { return
null; }
Because before the SWC compile, the es3.js should be patched to look like:
function parseInt(num, opt_base) {}
Thanks,
-Alex
On 3/14/17, 4:01 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi,
>
>There also looks to be a typedef issue. Current CCSUtils is failing to
>compile:
>
>/Users/justinmclean/flex-asjs/frameworks/projects/Core/src/main/flex/org/a
>pache/flex/utils/CSSUtils.as(52): col: 27 Incorrect number of arguments.
>Expected 2
>
> rgba[3] = parseInt(""+(rgba[3]/255)*1000) / 1000;
> ^
>
>The typedef has this comment which seems a clue:
>/**
> * Parse an integer. Use of {@code parseInt} without {@code base} is
>strictly
> * banned in Google. If you really want to parse octal or hex based
>on the
> * leader, then pass {@code undefined} as the base.
> *
>
>Thanks,
>Justin
