Problems with using some ASC 2.0 content (air extensions)

[Greg Dove <gr...@gmail.com>]

I'm sending this dev instead of users because it's related to the compiler.
Hopefully that makes sense.

I'd like some feedback on whether anyone else has seen problems with
including ASC 2.0 built content (in my case ANEs) in a flex/air app
(android in my case). Or perhaps Gordon or Alex might know about the
theoretical possibility of this if it is not common experience....

In a nutshell: is it known whether combining a swc (/ANE) built using ASC
2.0 within a project using the flex compiler could cause some invalid
bytecode in the end result?

Background:
I've been using flex/air to make android and iOS builds for a couple of
years now. Some of the build variants have a *lot* of extensions, so quite
familiar with them and overcoming the odd issue that crops up.

I've recently started experiencing problems with some of the latest
releases of extensions (latest versions of Air require updated extensions
for iOS/64bit so a lot of suppliers have been busy providing updates).

I think some of the problems might be that suppliers who previously were
building extensions with the flex compiler have switched to ASC 2.0 as well
as AIR 16+ fast AOT packaging (which is now the only option for iOS).

I am following up to confirm this, but at this point I suspect this might
be the reason. And perhaps it might be that they have swapped over because
I recall reading instructions somewhere that said (vaguely) 'you can't use
the old compiler any more, you need to use the new one'. I understood this
to relate to the iOS packaging approach and not flex compiler versus ASC
2.0. But perhaps some out there have not interpreted this the same way.....

Anyhow I think I was able to verify this issue somewhat with the chartboost
repo:
https://github.com/ChartBoost/air

Using the prebuilt version from the repo in a flex/air app results in an
immediate startup crash on android for me.

If I rebuild the extension with flex/air (using latest air 17beta, but I
don't think this part is relevant) then there is no crash.

Keen to hear thoughts and experiences here.

TIA,
Greg

Re: Problems with using some ASC 2.0 content (air extensions)

[Alex Harui <ah...@adobe.com>]

I’m not really a compiler person, I don’t know how the compiler factors
into ANEs.  I do know I’ve fixed a bunch of bugs in the compiler with how
it generated ActionScript byte code.  You can look at the Falcon compiler
code base.

-Alex

On 2/26/15, 9:50 PM, "Greg Dove" <gr...@gmail.com> wrote:

>I'm sending this dev instead of users because it's related to the
>compiler.
>Hopefully that makes sense.
>
>I'd like some feedback on whether anyone else has seen problems with
>including ASC 2.0 built content (in my case ANEs) in a flex/air app
>(android in my case). Or perhaps Gordon or Alex might know about the
>theoretical possibility of this if it is not common experience....
>
>In a nutshell: is it known whether combining a swc (/ANE) built using ASC
>2.0 within a project using the flex compiler could cause some invalid
>bytecode in the end result?
>
>Background:
>I've been using flex/air to make android and iOS builds for a couple of
>years now. Some of the build variants have a *lot* of extensions, so quite
>familiar with them and overcoming the odd issue that crops up.
>
>I've recently started experiencing problems with some of the latest
>releases of extensions (latest versions of Air require updated extensions
>for iOS/64bit so a lot of suppliers have been busy providing updates).
>
>I think some of the problems might be that suppliers who previously were
>building extensions with the flex compiler have switched to ASC 2.0 as
>well
>as AIR 16+ fast AOT packaging (which is now the only option for iOS).
>
>I am following up to confirm this, but at this point I suspect this might
>be the reason. And perhaps it might be that they have swapped over because
>I recall reading instructions somewhere that said (vaguely) 'you can't use
>the old compiler any more, you need to use the new one'. I understood this
>to relate to the iOS packaging approach and not flex compiler versus ASC
>2.0. But perhaps some out there have not interpreted this the same
>way.....
>
>Anyhow I think I was able to verify this issue somewhat with the
>chartboost
>repo:
>https://github.com/ChartBoost/air
>
>Using the prebuilt version from the repo in a flex/air app results in an
>immediate startup crash on android for me.
>
>If I rebuild the extension with flex/air (using latest air 17beta, but I
>don't think this part is relevant) then there is no crash.
>
>Keen to hear thoughts and experiences here.
>
>TIA,
>Greg