AS3 target issues

[Tim M]

Hi all,

So we did an AS3->Haxe conversion that went well. We can run the units from haxe with -swf output no problem. However, we need to back-integrate the converted haxe code in as3 for use in MXML applications.

For that I'm using -as3 target. A sample of my hxml looks like:

-lib air3

--macro "include('react', true, [])"

#--macro "include('com', true, ['com.hurlant.crypto.tls'])"

--macro "include('com', true)"

--macro "include('core', true, [])"

--macro "include('events', true, [])"

--macro "include('interfaces', true, [])"

--macro "include('util', true)"

-swf-version 23

-as3 asLib

The compile goes out and spits out a bunch of .as files to /asLib.  However, when I compile this directory in my flex app I get the following errors:

Description    Resource    Path    Location    Type
1180: Call to a possibly undefined method __foreach__.    NativeValueIterator.as    /uiLib/[source path] asLib/haxe/ds/_ObjectMap    line 19    Flex Problem
1180: Call to a possibly undefined method __foreach__.    NativeValueIterator.as    /uiLib/[source path] asLib/haxe/ds/_WeakMap    line 19    Flex Problem
1180: Call to a possibly undefined method __forin__.    NativePropertyIterator.as    /uiLib/[source path] asLib/haxe/ds/_ObjectMap    line 19    Flex Problem
1180: Call to a possibly undefined method __forin__.    NativePropertyIterator.as    /uiLib/[source path] asLib/haxe/ds/_WeakMap    line 19    Flex Problem
1180: Call to a possibly undefined method __has_next__.    NativePropertyIterator.as    /uiLib/[source path] asLib/haxe/ds/_ObjectMap    line 11    Flex Problem
1180: Call to a possibly undefined method __has_next__.    NativePropertyIterator.as    /uiLib/[source path] asLib/haxe/ds/_WeakMap    line 11    Flex Problem
1180: Call to a possibly undefined method __has_next__.    NativeValueIterator.as    /uiLib/[source path] asLib/haxe/ds/_ObjectMap    line 11    Flex Problem
1180: Call to a possibly undefined method __has_next__.    NativeValueIterator.as    /uiLib/[source path] asLib/haxe/ds/_WeakMap    line 11    Flex Problem

If I remove the directory /uiLib..../ds/_ObjectMap, for example, some of the errors go away. and if I remove _WeakMap, _ObjectMap, then all the errors go away. However there's obviously something wrong with the haxe as3 generation, and I'm not sure what's going on.

Secondly, once these errors are gone, I'm getting an immediate crash when running the app. I poked around a bit and found new __main__() seems to initialize the internal Boot MovieClip (Boot.mc). But I'm not sure if there's a better entry point I should be using.

So two questions:
1) What is thedeal with the __forin__ and other calls missing?
2) Is there a better entry point than new __main__()?

Thanks for the help!

[Juraj Kirchheim]

On Fri, Apr 14, 2017 at 2:25 AM, Tim M <moss...@gmail.com> wrote:

Hi all,

So we did an AS3->Haxe conversion that went well. We can run the units from haxe with -swf output no problem. However, we need to back-integrate the converted haxe code in as3 for use in MXML applications.

How about compiling to SWC? Here are a a few pointers: http://old.haxe.org/manual/swc#creating-swc-with-haxe

Best,

Juraj

[Jeff Ward]

Hi Tim,

We're doing the exact same thing. It's nice because this allows a continuous port process, moving functionality into Haxe piecemeal. It seems to work reasonably. I've tested both SWC and AS3 flows. If I recall, swc had its own set of weird-isms.

For the AS3 flow, we post-process the output from Haxe a bit. I don't want __main__.as to be the app entry point, but it also does some monkey-patching of the AS3 Objects that the generated AS3 code relies upon, so you need them. (e.g. Here's a bug report I filed before I realized that Haxe's AS3 monkey patches the Math class.)

I've created a gist that shows basically how we compile our .hx into AS3. We then post process the AS3 (we just add new post processing every time we run into an issue with the generated AS3). The biggest change is that we change __main__.as into HxLangPatches.as and then call it from our Main.as app main.

I think our patches may also disable flash.Lib.current, but you could probably also get that back if you use it. Or, again, set it up from your Main.as

I haven't run into the __forin__ issue yet, but in AS3 you can define global functions (unlike Haxe :P) by simply placing __forin__.as in a root source path, such as /generated_as3

LMK how it goes, or if you run into other issues.

Best,

-Jeff

[Tim M]

Thanks for the response.

We have been using a SWC, but it doesn't really work well with FlashBuilder because we can't debug into the swc. Building to as3 (at least for debugging) yields a better workflow. We actually run all our units direct (swc, hl) with Haxe debugging via HaxeDevelop. But that obviously doesn't apply to Flex development and mxml usage.

We poked and prodded a bit since yesterday and discovered that the _ObjetMap and _WeakMap issues are caused by some missing #if defines in haxe/std.  We submitted patches for those on github yesterday. https://github.com/HaxeFoundation/haxe/pull/6179

[Tim M]

Thanks for the thorough feedback Jeff.

So we are just including __main__() in our init code. The internal logic seems to just init for haxe env variables, and doesn't seem to add much overhead. Seems to work, although we're still working through other issues (setter/getter mangling). as3 target applies getter/'setter properly, but swc target does name replacement with a get_ or set_ call, which is annoying. I'll keep your gist handy if we run into any issues that need a deeper post-processing approach.

[Jeff Ward]

Interesting, I'll check out that PR.

We made a macro for generating AS3-style getters/setters for all Haxe getters/setters. I'm not sure it's ideal, but I believe it works ok. It auto-generates the commented out line here:

Best,

-Jeff