Linkage problem for asjs compiler

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Linkage problem for asjs compiler

mrchnk
Greetings!

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.


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.

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

Alex Harui-2

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

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings!

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

mrchnk
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 <[hidden email]> 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

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings!

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

Alex Harui-2

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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings!

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

Harbs
Are you using the remove-circulars compiler option?

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:
 
 
No guarantees that will fix your issue, but at least we can eliminate some possibilities.
 
HTH,
-Alex
 
From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler
 
Greetings! 
 
I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.
 
 
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.

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

mrchnk
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 <[hidden email]> wrote:
Are you using the remove-circulars compiler option?

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:
 
 
No guarantees that will fix your issue, but at least we can eliminate some possibilities.
 
HTH,
-Alex
 
From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler
 
Greetings! 
 
I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.
 
 
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.

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

Alex Harui-2

In addition to the data I asked for earlier, please also post link to openfl.swc and openfl.min.js.

 

Thanks,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

mrchnk
Alex, here are files you requested:


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 openfl@8.7.0

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

Alex Harui-2

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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

Alex Harui-2

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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

mrchnk
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):

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 <[hidden email]> 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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM


To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

Alex Harui-2

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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, December 17, 2018 at 9:48 AM
To: "[hidden email]" <[hidden email]>
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):

 

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 <[hidden email]> 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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM


To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

mrchnk
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

Build output and warnings are available at the old location (with prefix 1713-):

On Tue, Dec 18, 2018 at 11:43 AM Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, December 17, 2018 at 9:48 AM


To: "[hidden email]" <[hidden email]>
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):

 

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 <[hidden email]> 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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM


To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

mrchnk
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 <[hidden email]> 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

Build output and warnings are available at the old location (with prefix 1713-):

On Tue, Dec 18, 2018 at 11:43 AM Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, December 17, 2018 at 9:48 AM


To: "[hidden email]" <[hidden email]>
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):

 

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 <[hidden email]> 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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM


To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

mrchnk
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 <[hidden email]> 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 <[hidden email]> 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

Build output and warnings are available at the old location (with prefix 1713-):

On Tue, Dec 18, 2018 at 11:43 AM Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, December 17, 2018 at 9:48 AM


To: "[hidden email]" <[hidden email]>
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):

 

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 <[hidden email]> 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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM


To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

Alex Harui-2

Hi,

 

I saw that, but I think the compiler should be allowing that, so that’s what I’m going to look into next.

 

JavaScript should be able to set up these classes and constructors without problem.

 

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, December 18, 2018 at 12:24 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

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 <[hidden email]> 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 <[hidden email]> 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

 

Build output and warnings are available at the old location (with prefix 1713-):

 

On Tue, Dec 18, 2018 at 11:43 AM Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, December 17, 2018 at 9:48 AM


To: "[hidden email]" <[hidden email]>
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):

 

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 <[hidden email]> 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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM


To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

mrchnk
I appreciate your help, Alex!
Thanks. I pass linkage problems with that investigations.

On Wed, Dec 19, 2018 at 12:21 AM Alex Harui <[hidden email]> wrote:

Hi,

 

I saw that, but I think the compiler should be allowing that, so that’s what I’m going to look into next.

 

JavaScript should be able to set up these classes and constructors without problem.

 

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, December 18, 2018 at 12:24 PM


To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

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 <[hidden email]> 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 <[hidden email]> 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

 

Build output and warnings are available at the old location (with prefix 1713-):

 

On Tue, Dec 18, 2018 at 11:43 AM Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, December 17, 2018 at 9:48 AM


To: "[hidden email]" <[hidden email]>
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):

 

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 <[hidden email]> 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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM


To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

Alex Harui-2

FWIW, I just pushed changes that should allow this sort of configuration (even though, IMO, referencing subclasses from base classes is not a recommended practice).

 

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, December 18, 2018 at 1:26 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

I appreciate your help, Alex!

Thanks. I pass linkage problems with that investigations.

 

On Wed, Dec 19, 2018 at 12:21 AM Alex Harui <[hidden email]> wrote:

Hi,

 

I saw that, but I think the compiler should be allowing that, so that’s what I’m going to look into next.

 

JavaScript should be able to set up these classes and constructors without problem.

 

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, December 18, 2018 at 12:24 PM


To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

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 <[hidden email]> 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 <[hidden email]> 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

 

Build output and warnings are available at the old location (with prefix 1713-):

 

On Tue, Dec 18, 2018 at 11:43 AM Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, December 17, 2018 at 9:48 AM


To: "[hidden email]" <[hidden email]>
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):

 

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 <[hidden email]> 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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM


To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

mrchnk
I just tested latest nightly build 1735

Now I have another issue with linker:

That time some required dependencies are omitted in index.html. But that classes are declared with dependencies on themselves. Also, no circular dependencies reported while using "-diagnostics=32768".

   goog.addDependency('../../../oasis/gifts/WishGiftAddCommand.js', ['oasis.gifts.WishGiftAddCommand'], ['org.puremvc.as3.patterns.command.SimpleCommand', 'oasis.gifts.WishGiftAddCommand', 'oasis.gifts.WishGiftAddCommand', 'oasis.gifts.WishGiftAddCommand']);

Build output and warnings are available at the old location (with prefix 1735-):

On Thu, Dec 20, 2018 at 8:16 AM Alex Harui <[hidden email]> wrote:

FWIW, I just pushed changes that should allow this sort of configuration (even though, IMO, referencing subclasses from base classes is not a recommended practice).

 

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, December 18, 2018 at 1:26 PM


To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

I appreciate your help, Alex!

Thanks. I pass linkage problems with that investigations.

 

On Wed, Dec 19, 2018 at 12:21 AM Alex Harui <[hidden email]> wrote:

Hi,

 

I saw that, but I think the compiler should be allowing that, so that’s what I’m going to look into next.

 

JavaScript should be able to set up these classes and constructors without problem.

 

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, December 18, 2018 at 12:24 PM


To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

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 <[hidden email]> 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 <[hidden email]> 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

 

Build output and warnings are available at the old location (with prefix 1713-):

 

On Tue, Dec 18, 2018 at 11:43 AM Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, December 17, 2018 at 9:48 AM


To: "[hidden email]" <[hidden email]>
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):

 

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 <[hidden email]> 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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM


To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

Reply | Threaded
Open this post in threaded view
|

Re: Linkage problem for asjs compiler

Alex Harui-2

Interesting.  Can you post the output JS file and enough of the AS file to see the “public class” and “extends” and “implements”.  The properties and methods shouldn’t matter.

 

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Wednesday, December 26, 2018 at 1:46 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

I just tested latest nightly build 1735

 

Now I have another issue with linker:

 

That time some required dependencies are omitted in index.html. But that classes are declared with dependencies on themselves. Also, no circular dependencies reported while using "-diagnostics=32768".

 

   goog.addDependency('../../../oasis/gifts/WishGiftAddCommand.js', ['oasis.gifts.WishGiftAddCommand'], ['org.puremvc.as3.patterns.command.SimpleCommand', 'oasis.gifts.WishGiftAddCommand', 'oasis.gifts.WishGiftAddCommand', 'oasis.gifts.WishGiftAddCommand']);

 

Build output and warnings are available at the old location (with prefix 1735-):

 

On Thu, Dec 20, 2018 at 8:16 AM Alex Harui <[hidden email]> wrote:

FWIW, I just pushed changes that should allow this sort of configuration (even though, IMO, referencing subclasses from base classes is not a recommended practice).

 

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, December 18, 2018 at 1:26 PM


To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

I appreciate your help, Alex!

Thanks. I pass linkage problems with that investigations.

 

On Wed, Dec 19, 2018 at 12:21 AM Alex Harui <[hidden email]> wrote:

Hi,

 

I saw that, but I think the compiler should be allowing that, so that’s what I’m going to look into next.

 

JavaScript should be able to set up these classes and constructors without problem.

 

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, December 18, 2018 at 12:24 PM


To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

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 <[hidden email]> 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 <[hidden email]> 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

 

Build output and warnings are available at the old location (with prefix 1713-):

 

On Tue, Dec 18, 2018 at 11:43 AM Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, December 17, 2018 at 9:48 AM


To: "[hidden email]" <[hidden email]>
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):

 

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 <[hidden email]> 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/  The updated compiler should be in  build #1705 or later.

 

Thanks,

-Alex

 

From: Alex Harui <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:32 PM


To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 11:06 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: Linkage problem for asjs compiler

 

Alex, here are files you requested:

 

 

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 openfl@8.7.0

 

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 <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, December 14, 2018 at 8:22 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> wrote:

Are you using the remove-circulars compiler option?

 

On Dec 14, 2018, at 10:24 AM, Alex Harui <[hidden email]> 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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:24 PM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]> 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:

 

 

No guarantees that will fix your issue, but at least we can eliminate some possibilities.

 

HTH,

-Alex

 

From: mrchnk <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, December 13, 2018 at 10:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Linkage problem for asjs compiler

 

Greetings! 

 

I tried to compile a large project using npm distribution of Apache Royale asjs compiler (@apache-royale/royale-js@0.9.4). I changed all flash.* classes to openfl.*. After several hotfixes that project starts to compile.

 

 

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.

 

12