I found the issue for that case. The problem is in Animation constructor:
...
if (_rootTimeline == null) {
if (_rootFrame == -1) {
_rootFrame = 0;
_rootFramesTimeline = new SimpleTimeline();
_rootTimeline = new SimpleTimeline();
_rootTimeline._startTime = getTimer() / 1000;
_rootFramesTimeline._startTime = 0;
_rootTimeline._active = _rootFramesTimeline._active = true;
ticker.addEventListener("enterFrame", _updateRoot, false, 0,
true);
} else {
return;
}
}
...
It tries to instantiate SimpleTimeout which is derived from Animation
itself. That's tricky.
After dealing with that I faced other circular dependencies:
- using a derived class in base's method:
class Base {
function doSomething() {
if (this is Derived) {
...
}
}
}
class Derived extends Base { ... }
- one more setup with static initialized const
class Facade {
static public var api: Service = new Service();
}
class Service {
function doSomething(forClient:Client) {
forClient.done();
}
}
class Client {
function doSomething() {
Facade.api.doSomething(this);
}
function done() {
trace("done");
}
}
On Tue, Dec 18, 2018 at 10:00 PM mrchnk <[email protected]> wrote:
> I think the problem with that classes that SimpleTimeline extends
> Animation, but Animation has fields (static too) with type SimpleTimeline.
>
> On Tue, Dec 18, 2018 at 9:54 PM mrchnk <[email protected]> wrote:
>
>> Hi, Alex.
>>
>> I tried build #1713. Log output says that following circular dependency
>> is found:
>>
>> ...
>> Circular Dependency Found
>> [com.greensock.core.Animation]
>> [com.greensock.core.SimpleTimeline]
>> [com.greensock.core.Animation]
>> End of Circular Dependency
>> ...
>>
>> Here are both .as and .js files mentioned in that dependency
>> https://gist.github.com/mrchnk/caba399919690a785761242c35e5a01a
>>
>> Build output and warnings are available at the old location (with prefix
>> 1713-):
>> https://drive.google.com/open?id=17IRbQ1xAfpAirjbW6YjQPFEYHmL1HnhC
>>
>> On Tue, Dec 18, 2018 at 11:43 AM Alex Harui <[email protected]> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> That log showed that lots of files are not in the sorted order, not just
>>> Client. In a test of the Tour De Flex running in Royale, all files 700+
>>> files end up in the sorted order. In trying to reproduce the issue, I
>>> discovered that circularities in the graph are not reported, so I’ve added
>>> that to the output. So wait a few hours for the new nightly (build #1712
>>> or later) and try again and search the output for
>>>
>>>
>>>
>>> Circular Dependency Found
>>>
>>>
>>>
>>> Hopefully there will be one which would explain the differences in the
>>> lists. It should be followed by a list of classes, then:
>>>
>>>
>>>
>>>
>>>
>>> End of Circular Dependency
>>>
>>>
>>>
>>> Post the list and the ActionScript sources and JavaScript from the
>>> output folder for the classes. The JS output may not handle certain kinds
>>> of static initializers and think there are static dependencies when there
>>> doesn’t need to be which could result in circularities that would work fine
>>> in SWF. We’ll see what it takes to make the compiler smarter, but you
>>> might make more progress by modifying the static initializers.
>>>
>>>
>>>
>>> One pattern for a workaround is to test if the class has been
>>> initialized and if not, initialize it. So instead of:
>>>
>>>
>>>
>>> public class SomeClass {
>>>
>>> public static var foo:int = SomeOtherClass.foo;
>>>
>>> }
>>>
>>>
>>>
>>> You could do:
>>>
>>> public class SomeClass {
>>>
>>> public static var initialized:Boolean;
>>>
>>> public static var foo:int;;
>>>
>>> public static function initialize() {
>>>
>>> SomeClass.foo = SomeOtherClass.foo;
>>>
>>> SomeClass.initialized = true;
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>> And then before you actually read SomeClass.foo, add
>>>
>>>
>>>
>>> if (!SomeClass.initialized) SomeClass.initialize();
>>>
>>>
>>>
>>> But first, we have to see if there is a circularity being reported.
>>>
>>>
>>>
>>> HTH,
>>>
>>> -Alex
>>>
>>>
>>>
>>> *From: *mrchnk <[email protected]>
>>> *Reply-To: *"[email protected]" <[email protected]>
>>> *Date: *Monday, December 17, 2018 at 9:48 AM
>>>
>>>
>>> *To: *"[email protected]" <[email protected]>
>>> *Subject: *Re: Linkage problem for asjs compiler
>>>
>>>
>>>
>>> Hi, Alex!
>>>
>>>
>>>
>>> I downloaded the latest nightly build of royale (which is 1707) and
>>> build my project using it with "-diagnostics=32768" argument.
>>>
>>> Here is build output (too large to be posted as a gist):
>>>
>>> https://drive.google.com/open?id=17IRbQ1xAfpAirjbW6YjQPFEYHmL1HnhC
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrive.google.com%2Fopen%3Fid%3D17IRbQ1xAfpAirjbW6YjQPFEYHmL1HnhC&data=02%7C01%7Caharui%40adobe.com%7C05c93f3d4cf94a178dcf08d66447e552%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636806657282447495&sdata=KKtA%2BHd3j5LqVB48JZS38dz%2BRRKJBWwI2WxPTTzWvN8%3D&reserved=0>
>>>
>>>
>>>
>>> I also enabled warnings for that build and save error output as a
>>> separated log file.
>>>
>>>
>>>
>>> That project is large and has a long history, so it could be really bad
>>> at dependencies with spaghetti code.
>>>
>>> But that seems to be ok for a mxmlc compiler from AIR SDK.
>>>
>>>
>>>
>>> On Mon, Dec 17, 2018 at 10:49 AM Alex Harui <[email protected]> wrote:
>>>
>>> Hi,,
>>>
>>>
>>>
>>> After more investigation, I’m not sure what is going wrong. I tested
>>> some scenarios with all dependencies removed and they worked. I added more
>>> diagnostics to the compiler. It can take several hours for the nightly
>>> build to update, but when it does, please add -diagnostics=32768 to your
>>> build and post a link to the output.
>>>
>>>
>>>
>>> Check the nightly build status here:
>>> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroyaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2Froyale-asjs%2F&data=02%7C01%7Caharui%40adobe.com%7C05c93f3d4cf94a178dcf08d66447e552%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636806657282457504&sdata=5yEN1QIB6suavS0edNLqbMhMq20I3JSZ9LBxKV52aT8%3D&reserved=0>
>>> The updated compiler should be in build #1705 or later.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> -Alex
>>>
>>>
>>>
>>> *From: *Alex Harui <[email protected]>
>>> *Reply-To: *"[email protected]" <[email protected]>
>>> *Date: *Friday, December 14, 2018 at 11:32 PM
>>>
>>>
>>> *To: *"[email protected]" <[email protected]>
>>> *Subject: *Re: Linkage problem for asjs compiler
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I think I found the problem. A class that had all of its dependencies
>>> removed in the circulars calculation (except its base class) wasn’t being
>>> output to the addDependency list because the base class dependency wasn’t
>>> being added into the addDependency list. I won’t have much time to work on
>>> it until Sunday evening.
>>>
>>>
>>>
>>> I did notice that openfl.swc does not contain externs/typedefs. That
>>> might be an issue for minification some day.
>>>
>>>
>>>
>>> -Alex
>>>
>>>
>>>
>>>
>>>
>>> *From: *mrchnk <[email protected]>
>>> *Reply-To: *"[email protected]" <[email protected]>
>>> *Date: *Friday, December 14, 2018 at 11:06 AM
>>> *To: *"[email protected]" <[email protected]>
>>> *Subject: *Re: Linkage problem for asjs compiler
>>>
>>>
>>>
>>> Alex, here are files you requested:
>>>
>>>
>>>
>>> https://gist.github.com/mrchnk/c0965fdfef6caf0632acc78d1138940c
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fmrchnk%2Fc0965fdfef6caf0632acc78d1138940c&data=02%7C01%7Caharui%40adobe.com%7C05c93f3d4cf94a178dcf08d66447e552%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636806657282457504&sdata=EgFnC9MiM5kcbyuZeOixqLgsT4h8RR52BMOLh2VLqmo%3D&reserved=0>
>>>
>>>
>>>
>>> I used npm distribution of openfl version 8.7.0. You can download it
>>> into the current directory using npm or yarn package manager:
>>>
>>>
>>>
>>> npm install [email protected]
>>>
>>>
>>>
>>> After that command, you can find openfl.swc, openfl.min.js as well as
>>> non-minified version openfl.js at path node_modules/openfl/dist of the
>>> current directory.
>>>
>>>
>>>
>>> Also I used npm script "asconfigc --debug=true" to build the code
>>>
>>>
>>>
>>> I tried to disable "remove-circulars" option (thanks to Harbs for
>>> pointing me to that). It still compiles, and linkage problems seem to goes
>>> away. But I figured out that circular dependencies cannot be resolved
>>> properly by the closure library after all. Is there any common solution to
>>> that problem?
>>>
>>>
>>>
>>> On Fri, Dec 14, 2018 at 8:56 PM Alex Harui <[email protected]> wrote:
>>>
>>> In addition to the data I asked for earlier, please also post link to
>>> openfl.swc and openfl.min.js.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> -Alex
>>>
>>>
>>>
>>> *From: *mrchnk <[email protected]>
>>> *Reply-To: *"[email protected]" <[email protected]>
>>> *Date: *Friday, December 14, 2018 at 8:22 AM
>>> *To: *"[email protected]" <[email protected]>
>>> *Subject: *Re: Linkage problem for asjs compiler
>>>
>>>
>>>
>>> I don't know anything about the option "remove-circulars", so I think I
>>> use the default value here, which is enabled I guess.
>>>
>>> Actually, I am using asconfigc wrapper over the compiler, but I have
>>> nothing about that option in my asconfig.json neither.
>>>
>>>
>>>
>>> On Fri, Dec 14, 2018 at 2:39 PM Harbs <[email protected]> wrote:
>>>
>>> Are you using the remove-circulars compiler option?
>>>
>>>
>>>
>>> On Dec 14, 2018, at 10:24 AM, Alex Harui <[email protected]> wrote:
>>>
>>>
>>>
>>> OK.
>>>
>>>
>>>
>>> Please post a link to the entire output of the compiler including, if
>>> possible, the command-line you used. I won’t have time to look at it right
>>> away as I am at the end of my work day.
>>>
>>>
>>>
>>> Also post links to Client.as, Client.js, OasisClient.as, OasisClient.js,
>>> OasisHTML5Launcher.as, OasisHTML5Launcher.js
>>>
>>>
>>>
>>> And also verify how the compiler “should” find Client.js. Is Client.as
>>> in the source-path or is Client.js in a SWC?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> -Alex
>>>
>>>
>>>
>>> *From: *mrchnk <[email protected]>
>>> *Reply-To: *"[email protected]" <[email protected]>
>>> *Date: *Thursday, December 13, 2018 at 10:24 PM
>>> *To: *"[email protected]" <[email protected]>
>>> *Subject: *Re: Linkage problem for asjs compiler
>>>
>>>
>>>
>>> Same problem with the nightly build. I also asked about my issue in
>>> openfl community.
>>>
>>> I think that problem may be related to circular dependencies in my code.
>>>
>>> Is there any way that can be handled automatically by royale compiler?
>>>
>>>
>>>
>>> On Thu, Dec 13, 2018 at 11:23 PM Alex Harui <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> Try a nightly build of Royale. I think some things have been fixed in
>>> the calculation of dependencies. I think if you are using npm, you can
>>> uninstall royale and then:
>>>
>>>
>>>
>>> npm install
>>> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/lastSuccessfulBuild/artifact/out/apache-royale-0.9.6-bin-js.tar.gz
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroyaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2Froyale-asjs%2FlastSuccessfulBuild%2Fartifact%2Fout%2Fapache-royale-0.9.6-bin-js.tar.gz&data=02%7C01%7Caharui%40adobe.com%7C05c93f3d4cf94a178dcf08d66447e552%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636806657282467513&sdata=etrcaueU%2BzRXWFDsPKnKXNEbwIqf%2FCljMHR7ODNPXWI%3D&reserved=0>
>>>
>>>
>>>
>>> No guarantees that will fix your issue, but at least we can eliminate
>>> some possibilities.
>>>
>>>
>>>
>>> HTH,
>>>
>>> -Alex
>>>
>>>
>>>
>>> *From: *mrchnk <[email protected]>
>>> *Reply-To: *"[email protected]" <[email protected]>
>>> *Date: *Thursday, December 13, 2018 at 10:34 AM
>>> *To: *"[email protected]" <[email protected]>
>>> *Subject: *Linkage problem for asjs compiler
>>>
>>>
>>>
>>> Greetings!
>>>
>>>
>>>
>>> I tried to compile a large project using npm distribution of Apache
>>> Royale asjs compiler (@apache-royale/[email protected]). I changed all
>>> flash.* classes to openfl.*. After several hotfixes that project starts to
>>> compile.
>>>
>>>
>>>
>>> Here is index.html generated:
>>> https://gist.github.com/mrchnk/4f468d1abb1b02466a0dad43265c4333
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fmrchnk%2F4f468d1abb1b02466a0dad43265c4333&data=02%7C01%7Caharui%40adobe.com%7C05c93f3d4cf94a178dcf08d66447e552%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636806657282467513&sdata=K1OCTkGVNCkMEbc%2Bw54O7qQ5PwwhOhMcw%2BZJadx1JLE%3D&reserved=0>
>>>
>>>
>>>
>>> The page is loaded with javascript errors:
>>>
>>> Uncaught Error: Undefined nameToPath for Client
>>>
>>> at visitNode (base.js:1356)
>>>
>>> at visitNode (base.js:1354)
>>>
>>> at Object.goog.writeScripts_ (base.js:1368)
>>>
>>> at Object.goog.require (base.js:705)
>>>
>>> at (index):1681
>>>
>>>
>>>
>>> (index):1687 Uncaught ReferenceError: OasisHTML5Launcher is not defined
>>>
>>> at (index):1687
>>>
>>>
>>>
>>> So Client.as is the superclass of OasisClient.as and is used in main
>>> OasisHTML5Launcher.
>>>
>>> It is successfully compiled to Client.js and declared as a dependency at
>>> index.html
>>>
>>> But a link to js file and declaration for that class is missing (I mean
>>> "goog.addDependency('../../../Client.as' ... )")
>>>
>>>
>>>
>>> So how to deal with that? Is it a Royale bug? Are there some guidelines
>>> I missed about my code?
>>>
>>>
>>>
>>> Thanks in advance.
>>>
>>>
>>>
>>> PS: I'm kinda new to mailing lists. So don't hesitate to correct me if I
>>> do something wrong.
>>>
>>>
>>>
>>>
