Re: Compiling Modules (was Re: Load time is very slow)
OK.
> On Jan 13, 2022, at 12:37 AM, Alex Harui wrote:
>
> The problem is that some output might look like this:
>
> bar.Foo.prototype.ROYALE_CLASS_INFO = { name: “Foo”. qName: “bar.Foo” };
>
> And the minifier will rename qName in the output differently in the main app
> vs the module:
>
> In the main app:
> bar.Foo..prototype.ROYALE_CLASS_INFO = { name: “Foo”. a: “bar.Foo” };
>
> In a module:
> bar.Baz..prototype.ROYALE_CLASS_INFO = { name: “Baz”. c: “bar.Baz” };
>
> Code that accesses someObj.ROYALE_CLASS_INFO.qName in the main app will do:
>
> Var qName = someObj.ROYALE_CLASS_INFO.a;
>
> And that won’t work for objects in the module that are using ‘c’ for QName.
>
> If you turn on -js-dynamic-access-unknown-members when building the SWCs,
> then these patterns in the SWC will look like:
>
> bar.Foo.prototype.ROYALE_CLASS_INFO = { name: “Foo”. ‘qName’: “bar.Foo” };
>
> But then every user of the SWC will never get qName renamed, which wastes
> bytes. So I think we want to not use -js-dynamic-access-unknown-members when
> building SWCs.
>
> So the -prevent-rename-object-keys option I added is only turned on for
> certain keys when building a module or a main app that loads a module. For
> the simple Module example, we only needed to prevent renaming of the
> following keys:
> cssData, _bindings, ROYALE_CLASS_INFO, superClass_, qName
>
> The Royale compiler copies JS files from the SWCs to bin/js-debug. What this
> option does is filter each file as it is copied, modifying the code for the
> keys. We’re already scanning every line in those files anyway in
> GoogDepsWriter. That way folks not building apps with modules get maximum
> renaming and only those needing to prevent renaming in their output can
> prevent that renaming.
>
> We’ll see if that holds up well for Roman. There was some additional hacking
> in the compiler since superclass_ is in base.js and not in our SWCs, so that
> file and key was special cased. Will there be more? Also I special cased
> Language.is/as/closure <http://language.is/as/closure> as they are not
> unknown members but are not exported and can be renamed in most apps but need
> to not be renamed for module and apps loading modules.
>
> You might find it useful to shave off a few bytes in your app where you don’t
> really want ALL unknown members to not be renamed. This option can let you
> specify just the list of members that matter.
>
> HTH,
> -Alex
>
>
> From: Harbs
> Reply-To: "users@royale.apache.org"
> Date: Wednesday, January 12, 2022 at 2:13 PM
> To: "users@royale.apache.org"
> Subject: Re: Compiling Modules (was Re: Load time is very slow)
>
> Didn’t totally grok what you said.
>
> Can you give a practical difference in when it would be used?
>
>
>> On Jan 12, 2022, at 7:39 PM, Alex Harui > <mailto:aha...@adobe.com>> wrote:
>>
>> The option I added takes a list of members and post-processes. I think all
>> other options change what is output during the compilation and
>> -js-dynamic-access-unknown-members doesn’t take a list of members.
>>
>> -Alex
>>
>> From: Harbs mailto:harbs.li...@gmail.com>>
>> Reply-To: "users@royale.apache.org <mailto:users@royale.apache.org>"
>> mailto:users@royale.apache.org>>
>> Date: Wednesday, January 12, 2022 at 2:30 AM
>> To: "users@royale.apache.org <mailto:users@royale.apache.org>"
>> mailto:users@royale.apache.org>>
>> Subject: Re: Compiling Modules (was Re: Load time is very slow)
>>
>> How is this different than -js-dynamic-access-unknown-members?
>>
>>
>>
>>> On Jan 12, 2022, at 10:04 AM, Alex Harui >> <mailto:aha...@adobe.com>> wrote:
>>>
>>> I added a -prevent-rename-object-keys compiler option that works as a
>>> post-processor. It scans the js files being copied into bin/js-debug and
>>> adds quotes around things.
Re: Compiling Modules (was Re: Load time is very slow)
The problem is that some output might look like this:
bar.Foo.prototype.ROYALE_CLASS_INFO = { name: “Foo”. qName: “bar.Foo” };
And the minifier will rename qName in the output differently in the main app vs
the module:
In the main app:
bar.Foo..prototype.ROYALE_CLASS_INFO = { name: “Foo”. a: “bar.Foo” };
In a module:
bar.Baz..prototype.ROYALE_CLASS_INFO = { name: “Baz”. c: “bar.Baz” };
Code that accesses someObj.ROYALE_CLASS_INFO.qName in the main app will do:
Var qName = someObj.ROYALE_CLASS_INFO.a;
And that won’t work for objects in the module that are using ‘c’ for QName.
If you turn on -js-dynamic-access-unknown-members when building the SWCs, then
these patterns in the SWC will look like:
bar.Foo.prototype.ROYALE_CLASS_INFO = { name: “Foo”. ‘qName’: “bar.Foo” };
But then every user of the SWC will never get qName renamed, which wastes
bytes. So I think we want to not use -js-dynamic-access-unknown-members when
building SWCs.
So the -prevent-rename-object-keys option I added is only turned on for certain
keys when building a module or a main app that loads a module. For the simple
Module example, we only needed to prevent renaming of the following keys:
cssData, _bindings, ROYALE_CLASS_INFO, superClass_, qName
The Royale compiler copies JS files from the SWCs to bin/js-debug. What this
option does is filter each file as it is copied, modifying the code for the
keys. We’re already scanning every line in those files anyway in
GoogDepsWriter. That way folks not building apps with modules get maximum
renaming and only those needing to prevent renaming in their output can prevent
that renaming.
We’ll see if that holds up well for Roman. There was some additional hacking
in the compiler since superclass_ is in base.js and not in our SWCs, so that
file and key was special cased. Will there be more? Also I special cased
Language.is/as/closure as they are not unknown members but are not exported and
can be renamed in most apps but need to not be renamed for module and apps
loading modules.
You might find it useful to shave off a few bytes in your app where you don’t
really want ALL unknown members to not be renamed. This option can let you
specify just the list of members that matter.
HTH,
-Alex
From: Harbs
Reply-To: "users@royale.apache.org"
Date: Wednesday, January 12, 2022 at 2:13 PM
To: "users@royale.apache.org"
Subject: Re: Compiling Modules (was Re: Load time is very slow)
Didn’t totally grok what you said.
Can you give a practical difference in when it would be used?
On Jan 12, 2022, at 7:39 PM, Alex Harui
mailto:aha...@adobe.com>> wrote:
The option I added takes a list of members and post-processes. I think all
other options change what is output during the compilation and
-js-dynamic-access-unknown-members doesn’t take a list of members.
-Alex
From: Harbs mailto:harbs.li...@gmail.com>>
Reply-To: "users@royale.apache.org<mailto:users@royale.apache.org>"
mailto:users@royale.apache.org>>
Date: Wednesday, January 12, 2022 at 2:30 AM
To: "users@royale.apache.org<mailto:users@royale.apache.org>"
mailto:users@royale.apache.org>>
Subject: Re: Compiling Modules (was Re: Load time is very slow)
How is this different than -js-dynamic-access-unknown-members?
On Jan 12, 2022, at 10:04 AM, Alex Harui
mailto:aha...@adobe.com>> wrote:
I added a -prevent-rename-object-keys compiler option that works as a
post-processor. It scans the js files being copied into bin/js-debug and adds
quotes around things.
Re: Compiling Modules (was Re: Load time is very slow)
Didn’t totally grok what you said. Can you give a practical difference in when it would be used? > On Jan 12, 2022, at 7:39 PM, Alex Harui wrote: > > The option I added takes a list of members and post-processes. I think all > other options change what is output during the compilation and > -js-dynamic-access-unknown-members doesn’t take a list of members. > > -Alex > > From: Harbs > Reply-To: "users@royale.apache.org" > Date: Wednesday, January 12, 2022 at 2:30 AM > To: "users@royale.apache.org" > Subject: Re: Compiling Modules (was Re: Load time is very slow) > > How is this different than -js-dynamic-access-unknown-members? > > >> On Jan 12, 2022, at 10:04 AM, Alex Harui > <mailto:aha...@adobe.com>> wrote: >> >> I added a -prevent-rename-object-keys compiler option that works as a >> post-processor. It scans the js files being copied into bin/js-debug and >> adds quotes around things.
Re: Compiling Modules (was Re: Load time is very slow)
The option I added takes a list of members and post-processes. I think all other options change what is output during the compilation and -js-dynamic-access-unknown-members doesn’t take a list of members. -Alex From: Harbs Reply-To: "users@royale.apache.org" Date: Wednesday, January 12, 2022 at 2:30 AM To: "users@royale.apache.org" Subject: Re: Compiling Modules (was Re: Load time is very slow) How is this different than -js-dynamic-access-unknown-members? On Jan 12, 2022, at 10:04 AM, Alex Harui mailto:aha...@adobe.com>> wrote: I added a -prevent-rename-object-keys compiler option that works as a post-processor. It scans the js files being copied into bin/js-debug and adds quotes around things.
Re: Compiling Modules (was Re: Load time is very slow)
Thanks for the update. I will pull the release modules branch source, build and test again. One question what compilation options should be used for this test ? Load externs, externs, link report ? Which options should be applied for the main and which option should be used for the module ? >From your mail below I can see that a new option have been added so I need clarity on this before I proceed with this test. On Wed, 12 Jan 2022, 09:04 Alex Harui, wrote: > I pushed a ReleaseModules branch in royale-compiler and royale-asjs. > > > > These changes cause the royale-asjs/examples/royale/ModuleExample release > version to work. > > > > The big challenge is that it turned out there is a fair amount of > infrastructure that is not exported/public. The Language utilities, > ROYALE_CLASS_INFO, the superclass_ property, cssData and others are going > to get renamed. And thus renamed differently in the main app vs the module. > > > > That’s why the current compiler’s strategy was to try to copy the renaming > map from the main app to the module, but it didn’t always work. There > seems to be a bug in the Closure Compiler that a set of externs causes the > compiler to mis-handle package-paths. Also, it meant that the module > contained its own copy of most of the infrastructure > > > > The new compiler strategy is a bit more like the old Flex module > strategy. The module tries to not contain a copy of code that already > exists in the main app. Some of the goog/base.js stuff still gets copied > though. Then because we avoid renaming more things, the module can > reference the shared infrastructure in the main app. > > > > The new compiler detects if what is being compiled is a loader of modules > (because it is generating an externs-report) or is a Module and prevents > renaming of Language APIs, modified base.js to not rename the superClass_ > property used for calling super() and a few other things. In addition, I > added a -prevent-rename-object-keys compiler option that works as a > post-processor. It scans the js files being copied into bin/js-debug and > adds quotes around things. > > > > By making these changes, I was able to get the closure compiler to > mis-handle the packages in a more predictable way, so another thing the new > compiler does is post-process the output file to remove the incorrect > package code. The incorrect code would re-init package paths like “org” or > “org.apache.royale”. > > > > Anyway, give it a try and see if it works. Probably we’ll find out there > is more infrastructure that needs to not be renamed, but I think this has a > better chance of working as we aren’t blocked by the compiler outputting > bad code. Many months ago I tried to understand how why the Closure > Compiler output bad code, but ran out of time. > > > > Another difference is that the new compiler strategy doesn’t use custom > overrides of Closure Compiler passes which was fragile and will make it > easier to upgrade to newer versions of Closure Compiler. > > > > HTH, > > -Alex > > > > *From: *Alex Harui > *Reply-To: *"users@royale.apache.org" > *Date: *Wednesday, January 5, 2022 at 9:53 AM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > I probably won’t have time to really dig into this until the weekend. It > is looking like the Closure Compiler gets confused when presented with > externs for the same package tree that the module is generating new classes > for. > > > > -Alex > > > > *From: *Roman Isitua > *Reply-To: *"users@royale.apache.org" > *Date: *Tuesday, January 4, 2022 at 1:57 PM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > Okay. I knew I was missing something. > > > > I will test again when the update for load-externs is available. > > > > On Tue, Jan 4, 2022 at 6:02 PM Alex Harui wrote: > > Essentially, -externs-report is for the Closure (JS) Compiler. > -link-report and -load-externs (one leading ‘-‘) is for the Royale Compiler > to tell the Royale Compiler what classes to feed to the Closure Compiler. > Both contain the same data (the set of classes used in the main app), just > formatted differently and used differently. > > > > The –externs option for the Closure Compiler then tells the Closure > Compiler not to look for classes in the set of files it is supposed to > minify. > > > > So, you have the right settings for the main app, but for the module, it > should be: > > *-js-compiler-option=--externs extrep.txt; -loa
Re: Compiling Modules (was Re: Load time is very slow)
How is this different than -js-dynamic-access-unknown-members? > On Jan 12, 2022, at 10:04 AM, Alex Harui wrote: > > I added a -prevent-rename-object-keys compiler option that works as a > post-processor. It scans the js files being copied into bin/js-debug and > adds quotes around things.
Re: Compiling Modules (was Re: Load time is very slow)
Sounds great Alex! I will try to check it out early next week. I especially like this: "Another difference is that the new compiler strategy doesn’t use custom overrides of Closure Compiler passes which was fragile and will make it easier to upgrade to newer versions of Closure Compiler." I tried and failed at one point to figure out how to migrate that stuff to a more recent version. On Wed, Jan 12, 2022 at 9:04 PM Alex Harui wrote: > I pushed a ReleaseModules branch in royale-compiler and royale-asjs. > > > > These changes cause the royale-asjs/examples/royale/ModuleExample release > version to work. > > > > The big challenge is that it turned out there is a fair amount of > infrastructure that is not exported/public. The Language utilities, > ROYALE_CLASS_INFO, the superclass_ property, cssData and others are going > to get renamed. And thus renamed differently in the main app vs the module. > > > > That’s why the current compiler’s strategy was to try to copy the renaming > map from the main app to the module, but it didn’t always work. There > seems to be a bug in the Closure Compiler that a set of externs causes the > compiler to mis-handle package-paths. Also, it meant that the module > contained its own copy of most of the infrastructure > > > > The new compiler strategy is a bit more like the old Flex module > strategy. The module tries to not contain a copy of code that already > exists in the main app. Some of the goog/base.js stuff still gets copied > though. Then because we avoid renaming more things, the module can > reference the shared infrastructure in the main app. > > > > The new compiler detects if what is being compiled is a loader of modules > (because it is generating an externs-report) or is a Module and prevents > renaming of Language APIs, modified base.js to not rename the superClass_ > property used for calling super() and a few other things. In addition, I > added a -prevent-rename-object-keys compiler option that works as a > post-processor. It scans the js files being copied into bin/js-debug and > adds quotes around things. > > > > By making these changes, I was able to get the closure compiler to > mis-handle the packages in a more predictable way, so another thing the new > compiler does is post-process the output file to remove the incorrect > package code. The incorrect code would re-init package paths like “org” or > “org.apache.royale”. > > > > Anyway, give it a try and see if it works. Probably we’ll find out there > is more infrastructure that needs to not be renamed, but I think this has a > better chance of working as we aren’t blocked by the compiler outputting > bad code. Many months ago I tried to understand how why the Closure > Compiler output bad code, but ran out of time. > > > > Another difference is that the new compiler strategy doesn’t use custom > overrides of Closure Compiler passes which was fragile and will make it > easier to upgrade to newer versions of Closure Compiler. > > > > HTH, > > -Alex > > > > *From: *Alex Harui > *Reply-To: *"users@royale.apache.org" > *Date: *Wednesday, January 5, 2022 at 9:53 AM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > I probably won’t have time to really dig into this until the weekend. It > is looking like the Closure Compiler gets confused when presented with > externs for the same package tree that the module is generating new classes > for. > > > > -Alex > > > > *From: *Roman Isitua > *Reply-To: *"users@royale.apache.org" > *Date: *Tuesday, January 4, 2022 at 1:57 PM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > Okay. I knew I was missing something. > > > > I will test again when the update for load-externs is available. > > > > On Tue, Jan 4, 2022 at 6:02 PM Alex Harui wrote: > > Essentially, -externs-report is for the Closure (JS) Compiler. > -link-report and -load-externs (one leading ‘-‘) is for the Royale Compiler > to tell the Royale Compiler what classes to feed to the Closure Compiler. > Both contain the same data (the set of classes used in the main app), just > formatted differently and used differently. > > > > The –externs option for the Closure Compiler then tells the Closure > Compiler not to look for classes in the set of files it is supposed to > minify. > > > > So, you have the right settings for the main app, but for the module, it > should be: > > *-js-compiler-option=--externs extrep.txt; -load-externs linkrep.txt;*
Re: Compiling Modules (was Re: Load time is very slow)
Okay. I knew I was missing something. I will test again when the update for load-externs is available. On Tue, Jan 4, 2022 at 6:02 PM Alex Harui wrote: > Essentially, -externs-report is for the Closure (JS) Compiler. > -link-report and -load-externs (one leading ‘-‘) is for the Royale Compiler > to tell the Royale Compiler what classes to feed to the Closure Compiler. > Both contain the same data (the set of classes used in the main app), just > formatted differently and used differently. > > > > The –externs option for the Closure Compiler then tells the Closure > Compiler not to look for classes in the set of files it is supposed to > minify. > > > > So, you have the right settings for the main app, but for the module, it > should be: > > *-js-compiler-option=--externs extrep.txt; -load-externs linkrep.txt;* > > > > However, even that won’t work today, as the Royale Compiler is not > handling -load-externs on the JS prep for Closure Compiler. I have some > local changes to the compiler that mixes most of it, but am facing issues > with how Closure handles package paths. If that can be resolved, then we > have a good chance of things working. > > > > -Alex > > > > *From: *Roman Isitua > *Reply-To: *"users@royale.apache.org" > *Date: *Tuesday, January 4, 2022 at 12:39 AM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > Thanks for the update. > > > > I attempted the following: > > > > 1. In the main application, I use the following setting: > > *-externs-report=extrep.txt; -link-report=linkrep.txt;* > > > > 2. In the module I use the following > > > > *-js-compiler-option=--externs extrep.txt; > -js-compiler-option+=--load-externs linkrep.txt;* > > > > The main application compiles successfully, I get a compilation error with > the module > > > > "--load-externs" is not a valid option > Sample usage: --compilation_level (-O) VAL --externs VAL --js VAL > --js_output_file VAL --warning_level (-W) [QUIET | DEFAULT > | VERBOSE] > Run with --help for all options and details > Internal error: java.lang.NullPointerException > com.google.javascript.jscomp.CommandLineRunner.createOptions(CommandLineRunner.java:1809)org.apache.royale.compiler.utils.JSClosureCompilerWrapper$CompilerOptionsParser.getOptions(JSClosureCompilerWrapper.java:529)org.apache.royale.compiler.utils.JSClosureCompilerWrapper.(JSClosureCompilerWrapper.java:77)org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyalePublisher.publish(MXMLRoyalePublisher.java:395)org.apache.royale.compiler.clients.M > > > > > > > > I don't think I am using this option correctly. > > > > > > > > . > > > > On Tue, Jan 4, 2022 at 8:44 AM Alex Harui wrote: > > I found some time to investigate. The -externs-report option is mostly > working correctly, but other compiler changes are needed to try to avoid > duplicate code in the module. I might have time to investigate more this > coming weekend. It does appear that if we can correctly reference the > app’s class from the module that it will work. The Closure Compiler let me > compile the module after I externalize and avoid requires on everything in > the main app’s externs report and -js link report, but the references in > the module have collapsed packages which is either incorrect or aliases > need to be created. > > > > However I think this new approach has a better chance of working than > trying to match renaming tables. > > > > -Alex > > > > *From: *Alex Harui > *Reply-To: *"users@royale.apache.org" > *Date: *Monday, January 3, 2022 at 2:30 PM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > The -externs-report option should be similar to the -link-report option. > It takes a filename. The compiler should output the classes used in the JS > compile into that file. To use externs, I think you don’t need to prevent > renaming in the application as long as public variables are exported. I > think you specify -externs-report when compiling the application. > > > > You may also need to output a -link-report from the application as well. > > > > I think you then specify the externs-report file as an -externs for the > -js-compiler-options when compiling the module. And maybe also specify the > -link-report output as a -load-externs in the same way it was used when > compiling Flex modules. The goal for the module is, like Flex, to not have > any classes in the module that exist in the main ap
Re: Compiling Modules (was Re: Load time is very slow)
Alex, this is probably more a topic for dev list (and we can definitely continue it there if need be, I would have done so, but could not figure out how to link to *this* thread properly in the archives). When you originally worked on this, did you eliminate using the GCC approach to creating 'modules' (it used to be called 'modules' in older GCC apparently, perhaps even the one we are currently locked to, but is now called 'chunks' in more recent GCC versions) ? Perhaps there is a technical difference or some other reason (e.g. the feature may not have been well documented) that meant it could not be used. However, if that was able to be used for royale modules, it seems like it would be faster/easier, because it is a single release compilation pass that splits the release build into multiple files, instead of using multiple passes. After reading the description for that [1] it does seem like it does all the hard work of avoiding the issues, in particular avoiding the need for the various output and input files related for renaming etc that are needed for multiple passes. 1. https://github.com/google/closure-compiler/wiki/Chunk-output-for-dynamic-loading On Wed, Jan 5, 2022 at 6:02 AM Alex Harui wrote: > Essentially, -externs-report is for the Closure (JS) Compiler. > -link-report and -load-externs (one leading ‘-‘) is for the Royale Compiler > to tell the Royale Compiler what classes to feed to the Closure Compiler. > Both contain the same data (the set of classes used in the main app), just > formatted differently and used differently. > > > > The –externs option for the Closure Compiler then tells the Closure > Compiler not to look for classes in the set of files it is supposed to > minify. > > > > So, you have the right settings for the main app, but for the module, it > should be: > > *-js-compiler-option=--externs extrep.txt; -load-externs linkrep.txt;* > > > > However, even that won’t work today, as the Royale Compiler is not > handling -load-externs on the JS prep for Closure Compiler. I have some > local changes to the compiler that mixes most of it, but am facing issues > with how Closure handles package paths. If that can be resolved, then we > have a good chance of things working. > > > > -Alex > > > > *From: *Roman Isitua > *Reply-To: *"users@royale.apache.org" > *Date: *Tuesday, January 4, 2022 at 12:39 AM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > Thanks for the update. > > > > I attempted the following: > > > > 1. In the main application, I use the following setting: > > *-externs-report=extrep.txt; -link-report=linkrep.txt;* > > > > 2. In the module I use the following > > > > *-js-compiler-option=--externs extrep.txt; > -js-compiler-option+=--load-externs linkrep.txt;* > > > > The main application compiles successfully, I get a compilation error with > the module > > > > "--load-externs" is not a valid option > Sample usage: --compilation_level (-O) VAL --externs VAL --js VAL > --js_output_file VAL --warning_level (-W) [QUIET | DEFAULT > | VERBOSE] > Run with --help for all options and details > Internal error: java.lang.NullPointerException > com.google.javascript.jscomp.CommandLineRunner.createOptions(CommandLineRunner.java:1809)org.apache.royale.compiler.utils.JSClosureCompilerWrapper$CompilerOptionsParser.getOptions(JSClosureCompilerWrapper.java:529)org.apache.royale.compiler.utils.JSClosureCompilerWrapper.(JSClosureCompilerWrapper.java:77)org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyalePublisher.publish(MXMLRoyalePublisher.java:395)org.apache.royale.compiler.clients.M > > > > > > > > I don't think I am using this option correctly. > > > > > > > > . > > > > On Tue, Jan 4, 2022 at 8:44 AM Alex Harui wrote: > > I found some time to investigate. The -externs-report option is mostly > working correctly, but other compiler changes are needed to try to avoid > duplicate code in the module. I might have time to investigate more this > coming weekend. It does appear that if we can correctly reference the > app’s class from the module that it will work. The Closure Compiler let me > compile the module after I externalize and avoid requires on everything in > the main app’s externs report and -js link report, but the references in > the module have collapsed packages which is either incorrect or aliases > need to be created. > > > > However I think this new approach has a better chance of working than > trying to match renaming tables. > > > > -Alex > > > > *From: *Alex Harui > *Reply-To: *"use
Re: Compiling Modules (was Re: Load time is very slow)
Thanks for the update. I attempted the following: 1. In the main application, I use the following setting: *-externs-report=extrep.txt; -link-report=linkrep.txt;* 2. In the module I use the following *-js-compiler-option=--externs extrep.txt; -js-compiler-option+=--load-externs linkrep.txt;* The main application compiles successfully, I get a compilation error with the module "--load-externs" is not a valid option Sample usage: --compilation_level (-O) VAL --externs VAL --js VAL --js_output_file VAL --warning_level (-W) [QUIET | DEFAULT | VERBOSE] Run with --help for all options and details Internal error: java.lang.NullPointerException com.google.javascript.jscomp.CommandLineRunner.createOptions(CommandLineRunner.java:1809)org.apache.royale.compiler.utils.JSClosureCompilerWrapper$CompilerOptionsParser.getOptions(JSClosureCompilerWrapper.java:529)org.apache.royale.compiler.utils.JSClosureCompilerWrapper.(JSClosureCompilerWrapper.java:77)org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyalePublisher.publish(MXMLRoyalePublisher.java:395)org.apache.royale.compiler.clients.M I don't think I am using this option correctly. . On Tue, Jan 4, 2022 at 8:44 AM Alex Harui wrote: > I found some time to investigate. The -externs-report option is mostly > working correctly, but other compiler changes are needed to try to avoid > duplicate code in the module. I might have time to investigate more this > coming weekend. It does appear that if we can correctly reference the > app’s class from the module that it will work. The Closure Compiler let me > compile the module after I externalize and avoid requires on everything in > the main app’s externs report and -js link report, but the references in > the module have collapsed packages which is either incorrect or aliases > need to be created. > > > > However I think this new approach has a better chance of working than > trying to match renaming tables. > > > > -Alex > > > > *From: *Alex Harui > *Reply-To: *"users@royale.apache.org" > *Date: *Monday, January 3, 2022 at 2:30 PM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > The -externs-report option should be similar to the -link-report option. > It takes a filename. The compiler should output the classes used in the JS > compile into that file. To use externs, I think you don’t need to prevent > renaming in the application as long as public variables are exported. I > think you specify -externs-report when compiling the application. > > > > You may also need to output a -link-report from the application as well. > > > > I think you then specify the externs-report file as an -externs for the > -js-compiler-options when compiling the module. And maybe also specify the > -link-report output as a -load-externs in the same way it was used when > compiling Flex modules. The goal for the module is, like Flex, to not have > any classes in the module that exist in the main app. Then it doesn’t > matter about class renaming within the release-mode JS file. > > > > HTH, > > -Alex > > > > *From: *Roman Isitua > *Reply-To: *"users@royale.apache.org" > *Date: *Monday, January 3, 2022 at 12:37 PM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > > > I can confirm that classes are being renamed in both files. > > > > I have attempted your suggestion i.e. removing variable maps and property > maps then use > > -externs-report;-export-public-symbols=true;-prevent-rename-public-symbols=true; > > > > > I get the below error > > > > command line Error: configuration variable 'externs-report' expected 1 > argument(s), got 0. > > > > I cannot find any documentation on how to use the -externs-report > argument. What does it do ? and what are the acceptable values ? > > > > Regards, > > > > > > On Sun, Jan 2, 2022 at 9:06 AM Alex Harui wrote: > > Hi Roman, > > > > It might be more complicated. The settings are probably doing something > since you reported that the error occurred in the app vs the module > depending on the settings. > > > > I went back and looked at the original module example in > examples/royale/ModuleExample and was surprised there weren’t more compiler > settings. I thought we’d found a way to externalize the main app’s code > for the module. Because if both the app and module have a copy of > SimpleCSSValuesImpl or any other class that both JS files use, there could > be issues as to which one gets loaded (maybe both) and what export aliases > are
Re: Compiling Modules (was Re: Load time is very slow)
I can confirm that classes are being renamed in both files. I have attempted your suggestion i.e. removing variable maps and property maps then use -externs-report;-export-public-symbols=true;-prevent-rename-public-symbols=true; I get the below error command line Error: configuration variable 'externs-report' expected 1 argument(s), got 0. I cannot find any documentation on how to use the -externs-report argument. What does it do ? and what are the acceptable values ? Regards, On Sun, Jan 2, 2022 at 9:06 AM Alex Harui wrote: > Hi Roman, > > > > It might be more complicated. The settings are probably doing something > since you reported that the error occurred in the app vs the module > depending on the settings. > > > > I went back and looked at the original module example in > examples/royale/ModuleExample and was surprised there weren’t more compiler > settings. I thought we’d found a way to externalize the main app’s code > for the module. Because if both the app and module have a copy of > SimpleCSSValuesImpl or any other class that both JS files use, there could > be issues as to which one gets loaded (maybe both) and what export aliases > are pointing to. Sounds like changing settings affected whether the > aliases pointed at module code vs app code. > > > > I thought we were using similar settings to what we used for SWF where the > module would not contain a copy of SimpleCSSValuesImpl so it would use the > one loaded by the main app, but I didn’t see those settings. We might need > to make that work because otherwise I think static initializations won’t do > the right thing. Or maybe we’ve figured out that it is simpler just to > write defensive code that doesn’t get broken. But also, if the module has > its own copy of code already loaded by the main app, that’s sort of a waste > of bytes. Maybe there was a minification issue with not having the module > link in classes already linked into the main app. I see an -externs-report > option in the compiler but the example doesn’t seem to use it. > > > > You should be able to scan the JS files and see if a class is in both > module and app and if it is getting renamed. > > > > I don’t know if I will have time to investigate further. The currently > recommended options for modules involving variable maps and property maps > may need to be abandoned in favor of externs and preventing renames. > > > > -Alex > > > > > > *From: *Roman Isitua > *Reply-To: *"users@royale.apache.org" > *Date: *Saturday, January 1, 2022 at 3:02 AM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > Alex, thank you for your detailed analysis of the error log. > > > > I agree with you that the best strategy is to prevent renaming of > public/exports used by the module. I have tried different options to > prevent renaming > > It appears none of them stops this. From my observation, it appears that > this default options below > > > > > -export-public-symbols=true;-prevent-rename-public-symbols=true;-prevent-rename-public-instance-accessors=true; > > > > Only seem to affect the main application (main module) but have no effect > on the other modules even though I ensured they were applied in > their respective module pom. I came to this conclusion when I decided to > turn set -prevent-rename-public-symbols=false > > > > I noticed that I got the same error but this time around in the main > module. > > > > Uncaught TypeError: this.rb[(intermediate value).Kd(...)] is not a function > at HN.iI.send (FrontEnd.js:970) > at nI.EH.Ea (FrontEnd.js:880) > at ON.q6 (FrontEnd.js:1815) > at TN.L2 (FrontEnd.js:2034) > at hF.Xf (FrontEnd.js:2063) > at lF.kb (FrontEnd.js:1233) > at lF.Vf (FrontEnd.js:1224) > at cF.O (FrontEnd.js:659) > at cF.M.w (FrontEnd.js:661) > at gQ.mA.M (FrontEnd.js:241) > > > > FrontEnd.js maps to FrontEnd.as in my application and is the entry point > of the application. This confirms that -prevent-rename-public-symbols=false > has > > an effect on the main module but no effect on other modules even though > they were applied in the respective module pom's. > > > > Maybe there are other options I am overlooking. > > > > On Sat, Jan 1, 2022 at 9:31 AM Alex Harui wrote: > > In case it helps, the minification (variable renaming) mechanism is > essentially guaranteed to cause problems in modules. The Closure Compiler > basically takes variables, sees if it is worth renaming it, then gives it > the name ‘a’, then ‘b’, and so-on, (it skips a few letters, IIRC), then >
Re: Compiling Modules (was Re: Load time is very slow)
I am using maven modules in a hierarchy as well. Mine is like
MainApp
Overview
I think the main difference between yours and mine is that I am using
j:ModuleLoader at runtime to load a module when a side menu is clicked.
On Sat, Jan 1, 2022 at 4:02 AM Maria Jose Esteve wrote:
> I think, as Greg says, "after 3 McAllan I can only have faith" , we are
> having a misconception
>
> If you are using j:ModuleLoader, you are using runtime module loading,
> like we used to do in Flex is that right? This is different from Maven
> modules.
>
>
>
> Maven modules are somewhat different, although conceptually they are
> similar. Imagine a "library" that is composed of different
> "sub-libraries/modules", each of them could be a module, swc, configured in
> a pom. In my case, I have a main pom (I think your SpacioFM2) that contains
> 2 sub-modules the application and the library. In the module "royaleapp"
> are all the "views" and in the library there is a module for each
> logical/conceptual entity I need: For example, I have a module that is
> "royalecomponents", another one that is "royaledto", another one
> "royaleproducts", etc... etc.
>
>
>
> In my main pom I have configured the following modules: royeleapp and
> royalelibs
>
>
>
>
>
>
>
> royaleapp
>
> royalelibs
>
>
>
>
>
>
>
> In the royalelibs pom I have configured different modules:
>
>
>
>
>
>
>
>
>
> royalecustomtheme
>
> royaleecharts
>
> royalejscalendar
>
> royalecomponents
>
> royaleinspiretree
>
> royalearq
>
> royaledto
>
> royalecommons
>
> royaleconfig
>
> royaleconfigsystem
>
> royalesproducts
>
> …
>
>
>
>
>
> When I refer to the Maven modules I mean these, the ones that are between
> in some of the pom's.
>
>
>
> I don't know if I have explained myself well Roman
>
>
>
> Overview.mxml where is it located in your pom's hierarchy? In the lib
> (royalelibs)?
>
>
>
> Hiedra
>
>
>
> *De:* Roman Isitua
> *Enviado el:* viernes, 31 de diciembre de 2021 19:41
> *Para:* users@royale.apache.org
> *Asunto:* Re: Compiling Modules (was Re: Load time is very slow)
>
>
>
> I have tested on both. The error log is the same.
>
>
>
> I don't understand your second question. Kindly clarify ?
>
>
>
>
>
> I followed strictly the approach used for loading modules here in this
> example.
>
> This is the only method I know for loading modules. If there is another
> method please share.
>
>
>
>
>
>
> https://royale.apache.org/dividing-an-apache-royale-application-with-modules/
>
>
>
> On Fri, 31 Dec 2021, 19:14 Maria Jose Esteve, wrote:
>
> @Roman, which branch did you compile the SDK from, ROYALE_INTERFACE_INFO
> or develop?
>
> Could you pass the Overview.mxml view to the main application? (to rule
> it out)
>
>
>
> Hiedra
>
>
>
> *De:* Roman Isitua
> *Enviado el:* viernes, 31 de diciembre de 2021 17:56
> *Para:* users@royale.apache.org
> *Asunto:* Re: Compiling Modules (was Re: Load time is very slow)
>
>
>
> I have tried tracing where the errors are happening whenever I test the
> release version
>
> Uncaught TypeError: Ql.valuesImpl.init is not a function
> at Hr.Cr.um (Overview.js:846)
> at Function.ep.generateMXMLProperties (Overview.js:795)
> at Hr.Sp.generateMXMLAttributes (Overview.js:599)
> at new Hr (Overview.js:864)
> at PN.M.loadHandler (FrontEnd.js:2042)
> 9Overview.js:173 Uncaught TypeError: this.createElement is not a function
> at $B.V (Overview.js:173)
> at new $B (FrontEnd.js:2430)
> at EP.convert (FrontEnd.js:2430)
> at Zy (FrontEnd.js:261)
> at HTMLAnchorElement.Uy (FrontEnd.js:121)
> at HTMLAnchorElement.Sy.b (FrontEnd.js:117)
>
>
>
>
>
> The highlighted code in red is declared as follows in the Overview.mxml
> (maven module)
>
>
>
>
>
>
>
>
>
>
>
> The j:valuesImpl points to the following code in jewel Module.js
>
>
>
> /**
> * @nocollapse
> * @export
> * @type {org.apache.royale.core.IValuesImpl}
> */
> org.apache.royale.jewel.Module.prototype.valuesImpl;
>
>
> org.apache.royale.jewel.Module.prototype.set__valuesImpl = function(value)
> {
> org.apache.royale.core.ValuesManager.valuesImpl.init(this);
> };
>
>
>
>
>
> it appears this fu
Re: Compiling Modules (was Re: Load time is very slow)
Alex, thank you for your detailed analysis of the error log. I agree with you that the best strategy is to prevent renaming of public/exports used by the module. I have tried different options to prevent renaming It appears none of them stops this. From my observation, it appears that this default options below -export-public-symbols=true;-prevent-rename-public-symbols=true;-prevent-rename-public-instance-accessors=true; Only seem to affect the main application (main module) but have no effect on the other modules even though I ensured they were applied in their respective module pom. I came to this conclusion when I decided to turn set -prevent-rename-public-symbols=false I noticed that I got the same error but this time around in the main module. Uncaught TypeError: this.rb[(intermediate value).Kd(...)] is not a function at HN.iI.send (FrontEnd.js:970) at nI.EH.Ea (FrontEnd.js:880) at ON.q6 (FrontEnd.js:1815) at TN.L2 (FrontEnd.js:2034) at hF.Xf (FrontEnd.js:2063) at lF.kb (FrontEnd.js:1233) at lF.Vf (FrontEnd.js:1224) at cF.O (FrontEnd.js:659) at cF.M.w (FrontEnd.js:661) at gQ.mA.M (FrontEnd.js:241) FrontEnd.js maps to FrontEnd.as in my application and is the entry point of the application. This confirms that -prevent-rename-public-symbols=false has an effect on the main module but no effect on other modules even though they were applied in the respective module pom's. Maybe there are other options I am overlooking. On Sat, Jan 1, 2022 at 9:31 AM Alex Harui wrote: > In case it helps, the minification (variable renaming) mechanism is > essentially guaranteed to cause problems in modules. The Closure Compiler > basically takes variables, sees if it is worth renaming it, then gives it > the name ‘a’, then ‘b’, and so-on, (it skips a few letters, IIRC), then > moves on to ‘aa’, and ‘ab’, etc. The odds that the compiler will encounter > the same variables in the same order when compiling an app and one or more > modules is close to zero. > > > > I did some work to try to dump the mapping of the renamed variables in the > main app and use that when compiling the modules. It was working for a > while, then some code was added to the framework that started fooling the > Closure Compiler. I spent some time trying to fix the Closure Compiler, > but ran out of time. Meanwhile, Josh was adding more control over renaming > so I moved on to other things. > > > > IMO, the best strategy to take would be to try to control what gets > renamed. All public/exports from the app that are used by the module > should not be renamed. That will definitely make the app and modules > bigger, but unless the Closure Compiler folks become interested in > runtime-loaded modules, it is challenging for the Royale compiler to allow > aggressive renaming. > > > > I think what is going on with the exceptions below is that exporting > doesn’t really prevent renaming. It only sets up an externally-visible > alias to a renamed variable. Especially for static members. So it isn’t > sufficient to export public variables, the code within the module must not > let the Closure Compiler think that the intra-module references can be > renamed, in this case, from SimpleCSSValuesImpl to QI > > > > I don’t know the renaming options we’ve added to the Royale Compiler, so I > don’t know if there is an option to control that. I think there is a way > to convince the Closure Compiler to not rename SimpleCSSValuesImpl because > I’ve seen other class names not get renamed. > > > > HTH, > > -Alex > > > > *From: *Roman Isitua > *Reply-To: *"users@royale.apache.org" > *Date: *Friday, December 31, 2021 at 10:42 AM > *To: *"users@royale.apache.org" > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > I have tested on both. The error log is the same. > > > > I don't understand your second question. Kindly clarify ? > > > > > > I followed strictly the approach used for loading modules here in this > example. > > This is the only method I know for loading modules. If there is another > method please share. > > > > > > > https://royale.apache.org/dividing-an-apache-royale-application-with-modules/ > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Froyale.apache.org%2Fdividing-an-apache-royale-application-with-modules%2F=04%7C01%7Caharui%40adobe.com%7C37895fe9f5244b9170fa08d9cc8d5b56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637765729789686368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=8RPrsLji8JNT15c9yCv1IuJiy8A7%2BKQrR4k3pDluTOg%3D=0> > > > > On Fri, 31 Dec 2021, 19:14 Maria Jose Esteve, wrote: > > @Roman, which bra
Re: Compiling Modules (was Re: Load time is very slow)
It will likely >>> cause issues. If you get it to work without those options, you can try to >>> add them back in and see if it still works. >>> 2. You seem to be missing the compiler options explained here: >>> https://apache.github.io/royale-docs/features/modules#minification >>> >>> For a pom, it would look something like this (adjust your paths to match >>> your setup): >>> >>> Main app: >>> -source-map=true;-js-compiler-option=--variable_map_output_file >>> gccvars.txt;-js-compiler-option+=--property_map_output_file >>> gccprops.txt >>> >>> Module: >>> -source-map=true;-js-compiler-option=--variable_map_input_file >>> ../../../../../MainApp/bin/js-release/gccvars.txt;-js-compiler-option+=--property_map_input_file >>> ../../../../../MainApp/bin/js-release/gccprops.txt >>> >>> On Dec 30, 2021, at 7:43 PM, Roman Isitua wrote: >>> >>> I think it will be better for me to share my pom's that way you can see >>> all the compilation options used. The pom for the parent (FmClient2), the >>> MainApp and one module (Overview) have been attached to this email. >>> >>> >>> On Thu, Dec 30, 2021 at 6:22 PM Harbs wrote: >>> >>>> Roman, can you share your full compiler options? >>>> >>>> I decided to remove the below settings completely >>>>> -export-public-symbols=false >>>>> -prevent-rename-protected-symbols=false >>>>> -prevent-rename-public-symbols=false >>>>> -prevent-rename-internal-symbols=false >>>>> >>>>> >>>>> I enabled the below settings >>>>> >>>>> -js-dynamic-access-unknown-members=true; >>>>> -js-default-initializers=true >>>>> >>>>> >>>>> The release version starts up >>>>> >>>>> >>>>> >>>> Hiedra, that’s great! >>>> >>>> On Dec 30, 2021, at 7:15 PM, Roman Isitua >>>> wrote: >>>> >>>> >>>> Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO >>>> >>>> On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve >>>> wrote: >>>> >>>>> Roman, are you testing with the SDK compiled from the Harb branches, >>>>> ROYALE_INTERFACE_INFO, or from develop? >>>>> >>>>> >>>>> >>>>> Hiedra >>>>> >>>>> >>>>> >>>>> *De:* Roman Isitua >>>>> *Enviado el:* jueves, 30 de diciembre de 2021 16:52 >>>>> *Para:* users@royale.apache.org >>>>> *Asunto:* Re: Compiling Modules (was Re: Load time is very slow) >>>>> >>>>> >>>>> >>>>> I decided to remove the below settings completely >>>>> -export-public-symbols=false >>>>> -prevent-rename-protected-symbols=false >>>>> -prevent-rename-public-symbols=false >>>>> -prevent-rename-internal-symbols=false >>>>> >>>>> >>>>> I enabled the below settings >>>>> >>>>> -js-dynamic-access-unknown-members=true; >>>>> -js-default-initializers=true >>>>> >>>>> >>>>> The release version starts up >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> However, the moment I launch a module. I get the below error >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> It appears to be failing when I launch the "*Overview*" module >>>>> (by clicking the Overview side menu). >>>>> >>>>> >>>>> >>>>> So my current observation is that by retaining only two settings >>>>> >>>>> >>>>> >>>>> -js-dynamic-access-unknown-members=true; >>>>> -js-default-initializers=true >>>>> >>>>> >>>>> >>>>> The release module starts up but the app fails whenever
Re: Compiling Modules (was Re: Load time is very slow)
gt;>> -export-public-symbols=false >>>> -prevent-rename-protected-symbols=false >>>> -prevent-rename-public-symbols=false >>>> -prevent-rename-internal-symbols=false >>>> >>>> >>>> I enabled the below settings >>>> >>>> -js-dynamic-access-unknown-members=true; >>>> -js-default-initializers=true >>>> >>>> >>>> The release version starts up >>>> >>>> >>>> >>> Hiedra, that’s great! >>> >>> On Dec 30, 2021, at 7:15 PM, Roman Isitua wrote: >>> >>> >>> Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO >>> >>> On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve >>> wrote: >>> >>>> Roman, are you testing with the SDK compiled from the Harb branches, >>>> ROYALE_INTERFACE_INFO, or from develop? >>>> >>>> >>>> >>>> Hiedra >>>> >>>> >>>> >>>> *De:* Roman Isitua >>>> *Enviado el:* jueves, 30 de diciembre de 2021 16:52 >>>> *Para:* users@royale.apache.org >>>> *Asunto:* Re: Compiling Modules (was Re: Load time is very slow) >>>> >>>> >>>> >>>> I decided to remove the below settings completely >>>> -export-public-symbols=false >>>> -prevent-rename-protected-symbols=false >>>> -prevent-rename-public-symbols=false >>>> -prevent-rename-internal-symbols=false >>>> >>>> >>>> I enabled the below settings >>>> >>>> -js-dynamic-access-unknown-members=true; >>>> -js-default-initializers=true >>>> >>>> >>>> The release version starts up >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> However, the moment I launch a module. I get the below error >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> It appears to be failing when I launch the "*Overview*" module >>>> (by clicking the Overview side menu). >>>> >>>> >>>> >>>> So my current observation is that by retaining only two settings >>>> >>>> >>>> >>>> -js-dynamic-access-unknown-members=true; >>>> -js-default-initializers=true >>>> >>>> >>>> >>>> The release module starts up but the app fails whenever I launch a >>>> module. >>>> >>>> >>>> >>>> The smallest size settings in the documentation do not work. The app >>>> does not start up. >>>> >>>> >>>> >>>> -export-public-symbols=false >>>> -prevent-rename-protected-symbols=false >>>> -prevent-rename-public-symbols=false >>>> -prevent-rename-internal-symbols=false >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The error trace is below >>>> >>>> >>>> >>>> >>>> >>>> Uncaught TypeError: cm.valuesImpl.init is not a function >>>> at Wr.Rr.pl <http://wr.rr.pl/> (Overview.js:792) >>>> at Function.mq.generateMXMLProperties (Overview.js:743) >>>> at Wr.lq.generateMXMLAttributes (Overview.js:551) >>>> at new Wr (Overview.js:810) >>>> at QN.J.loadHandler (FrontEnd.js:1978) >>>> 3Overview.js:56 Uncaught TypeError: Cannot read properties of undefined >>>> (reading 'prototype') >>>> at P (Overview.js:56) >>>> at VG.convert (FrontEnd.js:910) >>>> at ny (FrontEnd.js:250) >>>> at HTMLElement.iy (FrontEnd.js:125) >>>> at HTMLElement.b (FrontEnd.js:121) >>>> FrontEnd.js:1649 Uncaught TypeError: M is not a function >>>> at sM.J.handleMouseOut (FrontEnd.js:1649) >>>> at Function.ny [as googFireListener] (FrontEnd.js:123) >>>> at ny (FrontEnd.js:250) >>>> at HTMLAnchorElement.iy (FrontEnd.js:125) >>>> at HTMLAnchorElement.b (FrontEnd.js:121) >>>> FrontEn
Re: Compiling Modules (was Re: Load time is very slow)
ler options? >> >>> I decided to remove the below settings completely >>> -export-public-symbols=false >>> -prevent-rename-protected-symbols=false >>> -prevent-rename-public-symbols=false >>> -prevent-rename-internal-symbols=false >>> >>> >>> I enabled the below settings >>> >>> -js-dynamic-access-unknown-members=true; >>> -js-default-initializers=true >>> >>> >>> The release version starts up >>> >>> >>> >> >> Hiedra, that’s great! >> >>> On Dec 30, 2021, at 7:15 PM, Roman Isitua >> <mailto:romanisi...@gmail.com>> wrote: >>> >>> >>> Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO >>> >>> On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve >> <mailto:mjest...@iest.com>> wrote: >>> Roman, are you testing with the SDK compiled from the Harb branches, >>> ROYALE_INTERFACE_INFO, or from develop? >>> >>> >>> >>> Hiedra >>> >>> >>> >>> De: Roman Isitua mailto:romanisi...@gmail.com>> >>> Enviado el: jueves, 30 de diciembre de 2021 16:52 >>> Para: users@royale.apache.org <mailto:users@royale.apache.org> >>> Asunto: Re: Compiling Modules (was Re: Load time is very slow) >>> >>> >>> >>> I decided to remove the below settings completely >>> -export-public-symbols=false >>> -prevent-rename-protected-symbols=false >>> -prevent-rename-public-symbols=false >>> -prevent-rename-internal-symbols=false >>> >>> >>> I enabled the below settings >>> >>> -js-dynamic-access-unknown-members=true; >>> -js-default-initializers=true >>> >>> >>> The release version starts up >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> However, the moment I launch a module. I get the below error >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> It appears to be failing when I launch the "Overview" module (by clicking >>> the Overview side menu). >>> >>> >>> >>> So my current observation is that by retaining only two settings >>> >>> >>> >>> -js-dynamic-access-unknown-members=true; >>> -js-default-initializers=true >>> >>> >>> >>> The release module starts up but the app fails whenever I launch a module. >>> >>> >>> >>> The smallest size settings in the documentation do not work. The app does >>> not start up. >>> >>> >>> >>> -export-public-symbols=false >>> -prevent-rename-protected-symbols=false >>> -prevent-rename-public-symbols=false >>> -prevent-rename-internal-symbols=false >>> >>> >>> >>> >>> >>> >>> >>> The error trace is below >>> >>> >>> >>> >>> >>> Uncaught TypeError: cm.valuesImpl.init is not a function >>> at Wr.Rr.pl <http://wr.rr.pl/> (Overview.js:792) >>> at Function.mq.generateMXMLProperties (Overview.js:743) >>> at Wr.lq.generateMXMLAttributes (Overview.js:551) >>> at new Wr (Overview.js:810) >>> at QN.J.loadHandler (FrontEnd.js:1978) >>> 3Overview.js:56 Uncaught TypeError: Cannot read properties of undefined >>> (reading 'prototype') >>> at P (Overview.js:56) >>> at VG.convert (FrontEnd.js:910) >>> at ny (FrontEnd.js:250) >>> at HTMLElement.iy (FrontEnd.js:125) >>> at HTMLElement.b (FrontEnd.js:121) >>> FrontEnd.js:1649 Uncaught TypeError: M is not a function >>> at sM.J.handleMouseOut (FrontEnd.js:1649) >>> at Function.ny [as googFireListener] (FrontEnd.js:123) >>> at ny (FrontEnd.js:250) >>> at HTMLAnchorElement.iy (FrontEnd.js:125) >>> at HTMLAnchorElement.b (FrontEnd.js:121) >>> FrontEnd.js:1649 Uncaught TypeError: M is not a function >>> at sM.J.handleMouseOver (FrontEnd.js:1649) >>> at Function.ny [as googFireListener] (FrontEnd.js:123) >>> at ny (FrontEnd.js:250) >>
RE: Compiling Modules (was Re: Load time is very slow)
No Harb, we have in common the Maven compilation and the use of Maven modules.
But I take this opportunity to show you a "curious" test, look at the error
displayed in the Debug Console... (The sdk compiled from develop the error
references the js-debug folder, even though it is running from js-release)
A : SDK compiled on branch ROYALE_INTERFACE_INFO
B: SDK compiled on branch develop
Test 1) Basic:
Additional options in the Library (mvn modules) and in the main application:
-source-map=true;
-show-binding-warnings=false;
-source-map-source-root=${project.basedir}/src/main/royale/;
-js-default-initializers=true;
-js-dynamic-access-unknown-members=true;
-keep-as3-metadata+=Inject,Dispatcher,EventHandler,Event,PostConstruct,PreDestroy,ViewAdded,ViewRemoved,Bindable,Transient;
-keep-code-with-metadata=Inject;
A.
DEBUG: OK
RELEASE: Error
Se produjo una excepción: ReferenceError: Error #1065: Variable
com.iest.winplusweb.models.MasterConfigSystemModel is not defined.
at MQ (http://localhost:8080/WPWebRelease/App.js:4315:1727)
at Function.I$.getMetadataHost
(http://localhost:8080/WPWebRelease/App.js:6303:45)
at F9.getMetadataHost (http://localhost:8080/WPWebRelease/App.js:6711:147)
at F9.getMetadataHosts (http://localhost:8080/WPWebRelease/App.js:6710:299)
at F9.fromTypeDefinition
(http://localhost:8080/WPWebRelease/App.js:6711:381)
at Function.dT.getTypeDescriptor
(http://localhost:8080/WPWebRelease/App.js:5469:885)
at Function.GW.constructBean
(http://localhost:8080/WPWebRelease/App.js:2753:296)
at n$.initializeBeans (http://localhost:8080/WPWebRelease/App.js:5994:1046)
at n$.initialize (http://localhost:8080/WPWebRelease/App.js:5994:915)
at oW.constructProviders
(http://localhost:8080/WPWebRelease/App.js:1152:254)
Message in Console:
Uncaught ReferenceError: Error #1065: Variable
com.iest.winplusweb.models.MasterConfigSystemModel is not defined.
MQ @
D:\Develop_Royale\Projects\WinPlusWebSuite\royaleapp\royalelogin\target\javascript\bin\js-release\App.js:4315:1727
B.
DEBUG:OK
RELEASE: Same error
Message in Console:
Uncaught ReferenceError: Error #1065: Variable
com.iest.winplusweb.models.MasterConfigSystemModel is not defined.
MQ @
d:\Develop_Royale\Projects\WinPlusWebSuite\royaleapp\royalelogin\target\javascript\bin\js-debug\org\apache\royale\reflection\getDefinitionByName.js:61:11
Hiedra
De: Harbs
Enviado el: jueves, 30 de diciembre de 2021 19:42
Para: users@royale.apache.org
Asunto: Re: Compiling Modules (was Re: Load time is very slow)
Wait. I’m confused.
Does your app work? I’m assuming that your app is not the same as Roman’s.
On Dec 30, 2021, at 8:07 PM, Maria Jose Esteve
mailto:mjest...@iest.com>> wrote:
I was preparing an email with a battery of tests but I don't use any
configuration or property files... maybe I'd better stop and read it to you.
Hiedra
De: Harbs mailto:harbs.li...@gmail.com>>
Enviado el: jueves, 30 de diciembre de 2021 18:56
Para: users@royale.apache.org<mailto:users@royale.apache.org>
Asunto: Re: Compiling Modules (was Re: Load time is very slow)
1. I’d get rid of the agressive minification options. It will likely cause
issues. If you get it to work without those options, you can try to add them
back in and see if it still works.
2. You seem to be missing the compiler options explained here:
https://apache.github.io/royale-docs/features/modules#minification
For a pom, it would look something like this (adjust your paths to match your
setup):
Main app:
-source-map=true;-js-compiler-option=--variable_map_output_file
gccvars.txt;-js-compiler-option+=--property_map_output_file
gccprops.txt
Module:
-source-map=true;-js-compiler-option=--variable_map_input_file
../../../../../MainApp/bin/js-release/gccvars.txt;-js-compiler-option+=--property_map_input_file
../../../../../MainApp/bin/js-release/gccprops.txt
On Dec 30, 2021, at 7:43 PM, Roman Isitua
mailto:romanisi...@gmail.com>> wrote:
I think it will be better for me to share my pom's that way you can see all the
compilation options used. The pom for the parent (FmClient2), the MainApp and
one module (Overview) have been attached to this email.
On Thu, Dec 30, 2021 at 6:22 PM Harbs
mailto:harbs.li...@gmail.com>> wrote:
Roman, can you share your full compiler options?
I decided to remove the below settings completely
-export-public-symbols=false
-prevent-rename-protected-symbols=false
-prevent-rename-public-symbols=false
-prevent-rename-internal-symbols=false
I enabled the below settings
-js-dynamic-access-unknown-members=true;
-js-default-initializers=true
The release version starts up
Hiedra, that’s great!
On Dec 30, 2021, at 7:15 PM, Roman Isitua
mailto:romanisi...@gmail.com>> wrote:
Yes
Re: Compiling Modules (was Re: Load time is very slow)
Wait. I’m confused. Does your app work? I’m assuming that your app is not the same as Roman’s. > On Dec 30, 2021, at 8:07 PM, Maria Jose Esteve wrote: > > I was preparing an email with a battery of tests but I don't use any > configuration or property files... maybe I'd better stop and read it to you. > > Hiedra > > De: Harbs > Enviado el: jueves, 30 de diciembre de 2021 18:56 > Para: users@royale.apache.org > Asunto: Re: Compiling Modules (was Re: Load time is very slow) > > 1. I’d get rid of the agressive minification options. It will likely cause > issues. If you get it to work without those options, you can try to add them > back in and see if it still works. > 2. You seem to be missing the compiler options explained here: > https://apache.github.io/royale-docs/features/modules#minification > <https://apache.github.io/royale-docs/features/modules#minification> > > For a pom, it would look something like this (adjust your paths to match your > setup): > > Main app: > -source-map=true;-js-compiler-option=--variable_map_output_file > gccvars.txt;-js-compiler-option+=--property_map_output_file > gccprops.txt > > Module: > -source-map=true;-js-compiler-option=--variable_map_input_file > > ../../../../../MainApp/bin/js-release/gccvars.txt;-js-compiler-option+=--property_map_input_file > > ../../../../../MainApp/bin/js-release/gccprops.txt > > On Dec 30, 2021, at 7:43 PM, Roman Isitua <mailto:romanisi...@gmail.com>> wrote: > > I think it will be better for me to share my pom's that way you can see all > the compilation options used. The pom for the parent (FmClient2), the > MainApp and one module (Overview) have been attached to this email. > > > On Thu, Dec 30, 2021 at 6:22 PM Harbs <mailto:harbs.li...@gmail.com>> wrote: > Roman, can you share your full compiler options? > > I decided to remove the below settings completely > -export-public-symbols=false > -prevent-rename-protected-symbols=false > -prevent-rename-public-symbols=false > -prevent-rename-internal-symbols=false > > > I enabled the below settings > > -js-dynamic-access-unknown-members=true; > -js-default-initializers=true > > > The release version starts up > > Hiedra, that’s great! > > > On Dec 30, 2021, at 7:15 PM, Roman Isitua <mailto:romanisi...@gmail.com>> wrote: > > > Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO > > On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve <mailto:mjest...@iest.com>> wrote: > Roman, are you testing with the SDK compiled from the Harb branches, > ROYALE_INTERFACE_INFO, or from develop? > > Hiedra > > De: Roman Isitua mailto:romanisi...@gmail.com>> > Enviado el: jueves, 30 de diciembre de 2021 16:52 > Para: users@royale.apache.org <mailto:users@royale.apache.org> > Asunto: Re: Compiling Modules (was Re: Load time is very slow) > > I decided to remove the below settings completely > -export-public-symbols=false > -prevent-rename-protected-symbols=false > -prevent-rename-public-symbols=false > -prevent-rename-internal-symbols=false > > > I enabled the below settings > > -js-dynamic-access-unknown-members=true; > -js-default-initializers=true > > > The release version starts up > > > > > > > > > However, the moment I launch a module. I get the below error > > > > > It appears to be failing when I launch the "Overview" module (by clicking the > Overview side menu). > > So my current observation is that by retaining only two settings > > -js-dynamic-access-unknown-members=true; > -js-default-initializers=true > > The release module starts up but the app fails whenever I launch a module. > > The smallest size settings in the documentation do not work. The app does not > start up. > > -export-public-symbols=false > -prevent-rename-protected-symbols=false > -prevent-rename-public-symbols=false > -prevent-rename-internal-symbols=false > > > > The error trace is below > > > Uncaught TypeError: cm.valuesImpl.init is not a function > at Wr.Rr.pl <http://wr.rr.pl/> (Overview.js:792) > at Function.mq.generateMXMLProperties (Overview.js:743) > at Wr.lq.generateMXMLAttributes (Overview.js:551) > at new Wr (Overview.js:810) > at QN.J.loadHandler (FrontEnd.js:1978) > 3Overview.js:56 Uncaught TypeError: Cannot read properties of undefined > (reading 'prototype') > at P (Overview.js:56) > at VG.convert (FrontEnd.js:910) > at ny (FrontEnd.js:250) > at HTMLElement.iy (FrontEnd.j
Re: Compiling Modules (was Re: Load time is very slow)
I’d try removing these: -export-public-symbols=false;-prevent-rename-protected-symbols=false;-prevent-rename-public-symbols=false;-prevent-rename-internal-symbols=false; https://apache.github.io/royale-docs/create-an-application/optimizations/minification#smallest-size > On Dec 30, 2021, at 8:04 PM, Roman Isitua wrote: > > Kindly clarify what you mean by "no 1. Get rid of aggressive mimification > options " ? Which of the options are aggressive ? > > > I will apply no 2 and revert with my findings. > > On Thu, 30 Dec 2021, 18:56 Harbs, <mailto:harbs.li...@gmail.com>> wrote: > 1. I’d get rid of the agressive minification options. It will likely cause > issues. If you get it to work without those options, you can try to add them > back in and see if it still works. > 2. You seem to be missing the compiler options explained here: > https://apache.github.io/royale-docs/features/modules#minification > <https://apache.github.io/royale-docs/features/modules#minification> > > For a pom, it would look something like this (adjust your paths to match your > setup): > > Main app: > -source-map=true;-js-compiler-option=--variable_map_output_file > gccvars.txt;-js-compiler-option+=--property_map_output_file > gccprops.txt > > Module: > -source-map=true;-js-compiler-option=--variable_map_input_file > > ../../../../../MainApp/bin/js-release/gccvars.txt;-js-compiler-option+=--property_map_input_file > > ../../../../../MainApp/bin/js-release/gccprops.txt > >> On Dec 30, 2021, at 7:43 PM, Roman Isitua > <mailto:romanisi...@gmail.com>> wrote: >> >> I think it will be better for me to share my pom's that way you can see all >> the compilation options used. The pom for the parent (FmClient2), the >> MainApp and one module (Overview) have been attached to this email. >> >> >> On Thu, Dec 30, 2021 at 6:22 PM Harbs > <mailto:harbs.li...@gmail.com>> wrote: >> Roman, can you share your full compiler options? >> >>> I decided to remove the below settings completely >>> -export-public-symbols=false >>> -prevent-rename-protected-symbols=false >>> -prevent-rename-public-symbols=false >>> -prevent-rename-internal-symbols=false >>> >>> >>> I enabled the below settings >>> >>> -js-dynamic-access-unknown-members=true; >>> -js-default-initializers=true >>> >>> >>> The release version starts up >>> >>> >>> >> >> Hiedra, that’s great! >> >>> On Dec 30, 2021, at 7:15 PM, Roman Isitua >> <mailto:romanisi...@gmail.com>> wrote: >>> >>> >>> Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO >>> >>> On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve >> <mailto:mjest...@iest.com>> wrote: >>> Roman, are you testing with the SDK compiled from the Harb branches, >>> ROYALE_INTERFACE_INFO, or from develop? >>> >>> >>> >>> Hiedra >>> >>> >>> >>> De: Roman Isitua mailto:romanisi...@gmail.com>> >>> Enviado el: jueves, 30 de diciembre de 2021 16:52 >>> Para: users@royale.apache.org <mailto:users@royale.apache.org> >>> Asunto: Re: Compiling Modules (was Re: Load time is very slow) >>> >>> >>> >>> I decided to remove the below settings completely >>> -export-public-symbols=false >>> -prevent-rename-protected-symbols=false >>> -prevent-rename-public-symbols=false >>> -prevent-rename-internal-symbols=false >>> >>> >>> I enabled the below settings >>> >>> -js-dynamic-access-unknown-members=true; >>> -js-default-initializers=true >>> >>> >>> The release version starts up >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> However, the moment I launch a module. I get the below error >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> It appears to be failing when I launch the "Overview" module (by clicking >>> the Overview side menu). >>> >>> >>> >>> So my current observation is that by retaining only two settings >>> >>> >>> >>> -js-dynamic-access-unknown-members=tru
RE: Compiling Modules (was Re: Load time is very slow)
I was preparing an email with a battery of tests but I don't use any configuration or property files... maybe I'd better stop and read it to you. Hiedra De: Harbs Enviado el: jueves, 30 de diciembre de 2021 18:56 Para: users@royale.apache.org Asunto: Re: Compiling Modules (was Re: Load time is very slow) 1. I’d get rid of the agressive minification options. It will likely cause issues. If you get it to work without those options, you can try to add them back in and see if it still works. 2. You seem to be missing the compiler options explained here: https://apache.github.io/royale-docs/features/modules#minification For a pom, it would look something like this (adjust your paths to match your setup): Main app: -source-map=true;-js-compiler-option=--variable_map_output_file gccvars.txt;-js-compiler-option+=--property_map_output_file gccprops.txt Module: -source-map=true;-js-compiler-option=--variable_map_input_file ../../../../../MainApp/bin/js-release/gccvars.txt;-js-compiler-option+=--property_map_input_file ../../../../../MainApp/bin/js-release/gccprops.txt On Dec 30, 2021, at 7:43 PM, Roman Isitua mailto:romanisi...@gmail.com>> wrote: I think it will be better for me to share my pom's that way you can see all the compilation options used. The pom for the parent (FmClient2), the MainApp and one module (Overview) have been attached to this email. On Thu, Dec 30, 2021 at 6:22 PM Harbs mailto:harbs.li...@gmail.com>> wrote: Roman, can you share your full compiler options? I decided to remove the below settings completely -export-public-symbols=false -prevent-rename-protected-symbols=false -prevent-rename-public-symbols=false -prevent-rename-internal-symbols=false I enabled the below settings -js-dynamic-access-unknown-members=true; -js-default-initializers=true The release version starts up Hiedra, that’s great! On Dec 30, 2021, at 7:15 PM, Roman Isitua mailto:romanisi...@gmail.com>> wrote: Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve mailto:mjest...@iest.com>> wrote: Roman, are you testing with the SDK compiled from the Harb branches, ROYALE_INTERFACE_INFO, or from develop? Hiedra De: Roman Isitua mailto:romanisi...@gmail.com>> Enviado el: jueves, 30 de diciembre de 2021 16:52 Para: users@royale.apache.org<mailto:users@royale.apache.org> Asunto: Re: Compiling Modules (was Re: Load time is very slow) I decided to remove the below settings completely -export-public-symbols=false -prevent-rename-protected-symbols=false -prevent-rename-public-symbols=false -prevent-rename-internal-symbols=false I enabled the below settings -js-dynamic-access-unknown-members=true; -js-default-initializers=true The release version starts up However, the moment I launch a module. I get the below error It appears to be failing when I launch the "Overview" module (by clicking the Overview side menu). So my current observation is that by retaining only two settings -js-dynamic-access-unknown-members=true; -js-default-initializers=true The release module starts up but the app fails whenever I launch a module. The smallest size settings in the documentation do not work. The app does not start up. -export-public-symbols=false -prevent-rename-protected-symbols=false -prevent-rename-public-symbols=false -prevent-rename-internal-symbols=false The error trace is below Uncaught TypeError: cm.valuesImpl.init is not a function at Wr.Rr.pl<http://wr.rr.pl/> (Overview.js:792) at Function.mq.generateMXMLProperties (Overview.js:743) at Wr.lq.generateMXMLAttributes (Overview.js:551) at new Wr (Overview.js:810) at QN.J.loadHandler (FrontEnd.js:1978) 3Overview.js:56 Uncaught TypeError: Cannot read properties of undefined (reading 'prototype') at P (Overview.js:56) at VG.convert (FrontEnd.js:910) at ny (FrontEnd.js:250) at HTMLElement.iy (FrontEnd.js:125) at HTMLElement.b (FrontEnd.js:121) FrontEnd.js:1649 Uncaught TypeError: M is not a function at sM.J.handleMouseOut (FrontEnd.js:1649) at Function.ny [as googFireListener] (FrontEnd.js:123) at ny (FrontEnd.js:250) at HTMLAnchorElement.iy (FrontEnd.js:125) at HTMLAnchorElement.b (FrontEnd.js:121) FrontEnd.js:1649 Uncaught TypeError: M is not a function at sM.J.handleMouseOver (FrontEnd.js:1649) at Function.ny [as googFireListener] (FrontEnd.js:123) at ny (FrontEnd.js:250) at HTMLAnchorElement.iy (FrontEnd.js:125) at HTMLAnchorElement.b (FrontEnd.js:121) J.handleMouseOver @ FrontEnd.js:1649 ny @ FrontEnd.js:123 ny @ FrontEnd.js:250 iy @ FrontEnd.js:125 b @ FrontEnd.js:121 FrontEnd.js:1649 Uncaught TypeError: M is not a function at sM.J.handleMouseOut (FrontEnd.js:1649) at Function.ny [as googFireListener] (FrontEnd.js:123) at ny (FrontEnd.js:250) at HTMLAnchorElement.iy (FrontEnd.js:125) at HT
Re: Compiling Modules (was Re: Load time is very slow)
Kindly clarify what you mean by "no 1. Get rid of aggressive mimification options " ? Which of the options are aggressive ? I will apply no 2 and revert with my findings. On Thu, 30 Dec 2021, 18:56 Harbs, wrote: > 1. I’d get rid of the agressive minification options. It will likely cause > issues. If you get it to work without those options, you can try to add > them back in and see if it still works. > 2. You seem to be missing the compiler options explained here: > https://apache.github.io/royale-docs/features/modules#minification > > For a pom, it would look something like this (adjust your paths to match > your setup): > > Main app: > -source-map=true;-js-compiler-option=--variable_map_output_file > gccvars.txt;-js-compiler-option+=--property_map_output_file > gccprops.txt > > Module: > -source-map=true;-js-compiler-option=--variable_map_input_file > ../../../../../MainApp/bin/js-release/gccvars.txt;-js-compiler-option+=--property_map_input_file > ../../../../../MainApp/bin/js-release/gccprops.txt > > On Dec 30, 2021, at 7:43 PM, Roman Isitua wrote: > > I think it will be better for me to share my pom's that way you can see > all the compilation options used. The pom for the parent (FmClient2), the > MainApp and one module (Overview) have been attached to this email. > > > On Thu, Dec 30, 2021 at 6:22 PM Harbs wrote: > >> Roman, can you share your full compiler options? >> >> I decided to remove the below settings completely >>> -export-public-symbols=false >>> -prevent-rename-protected-symbols=false >>> -prevent-rename-public-symbols=false >>> -prevent-rename-internal-symbols=false >>> >>> >>> I enabled the below settings >>> >>> -js-dynamic-access-unknown-members=true; >>> -js-default-initializers=true >>> >>> >>> The release version starts up >>> >>> >>> >> Hiedra, that’s great! >> >> On Dec 30, 2021, at 7:15 PM, Roman Isitua wrote: >> >> >> Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO >> >> On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve >> wrote: >> >>> Roman, are you testing with the SDK compiled from the Harb branches, >>> ROYALE_INTERFACE_INFO, or from develop? >>> >>> >>> >>> Hiedra >>> >>> >>> >>> *De:* Roman Isitua >>> *Enviado el:* jueves, 30 de diciembre de 2021 16:52 >>> *Para:* users@royale.apache.org >>> *Asunto:* Re: Compiling Modules (was Re: Load time is very slow) >>> >>> >>> >>> I decided to remove the below settings completely >>> -export-public-symbols=false >>> -prevent-rename-protected-symbols=false >>> -prevent-rename-public-symbols=false >>> -prevent-rename-internal-symbols=false >>> >>> >>> I enabled the below settings >>> >>> -js-dynamic-access-unknown-members=true; >>> -js-default-initializers=true >>> >>> >>> The release version starts up >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> However, the moment I launch a module. I get the below error >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> It appears to be failing when I launch the "*Overview*" module >>> (by clicking the Overview side menu). >>> >>> >>> >>> So my current observation is that by retaining only two settings >>> >>> >>> >>> -js-dynamic-access-unknown-members=true; >>> -js-default-initializers=true >>> >>> >>> >>> The release module starts up but the app fails whenever I launch a >>> module. >>> >>> >>> >>> The smallest size settings in the documentation do not work. The app >>> does not start up. >>> >>> >>> >>> -export-public-symbols=false >>> -prevent-rename-protected-symbols=false >>> -prevent-rename-public-symbols=false >>> -prevent-rename-internal-symbols=false >>> >>> >>> >>> >>> >>> >>> >>> The error trace is below >>> >>> >>> >>> >>> >>> Uncaught TypeError: cm.valuesImpl.init is not a function >>> at Wr.Rr.pl <http://wr.r
Re: Compiling Modules (was Re: Load time is very slow)
1. I’d get rid of the agressive minification options. It will likely cause issues. If you get it to work without those options, you can try to add them back in and see if it still works. 2. You seem to be missing the compiler options explained here: https://apache.github.io/royale-docs/features/modules#minification For a pom, it would look something like this (adjust your paths to match your setup): Main app: -source-map=true;-js-compiler-option=--variable_map_output_file gccvars.txt;-js-compiler-option+=--property_map_output_file gccprops.txt Module: -source-map=true;-js-compiler-option=--variable_map_input_file ../../../../../MainApp/bin/js-release/gccvars.txt;-js-compiler-option+=--property_map_input_file ../../../../../MainApp/bin/js-release/gccprops.txt > On Dec 30, 2021, at 7:43 PM, Roman Isitua wrote: > > I think it will be better for me to share my pom's that way you can see all > the compilation options used. The pom for the parent (FmClient2), the > MainApp and one module (Overview) have been attached to this email. > > > On Thu, Dec 30, 2021 at 6:22 PM Harbs <mailto:harbs.li...@gmail.com>> wrote: > Roman, can you share your full compiler options? > >> I decided to remove the below settings completely >> -export-public-symbols=false >> -prevent-rename-protected-symbols=false >> -prevent-rename-public-symbols=false >> -prevent-rename-internal-symbols=false >> >> >> I enabled the below settings >> >> -js-dynamic-access-unknown-members=true; >> -js-default-initializers=true >> >> >> The release version starts up >> >> >> > > Hiedra, that’s great! > >> On Dec 30, 2021, at 7:15 PM, Roman Isitua > <mailto:romanisi...@gmail.com>> wrote: >> >> >> Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO >> >> On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve > <mailto:mjest...@iest.com>> wrote: >> Roman, are you testing with the SDK compiled from the Harb branches, >> ROYALE_INTERFACE_INFO, or from develop? >> >> >> >> Hiedra >> >> >> >> De: Roman Isitua mailto:romanisi...@gmail.com>> >> Enviado el: jueves, 30 de diciembre de 2021 16:52 >> Para: users@royale.apache.org <mailto:users@royale.apache.org> >> Asunto: Re: Compiling Modules (was Re: Load time is very slow) >> >> >> >> I decided to remove the below settings completely >> -export-public-symbols=false >> -prevent-rename-protected-symbols=false >> -prevent-rename-public-symbols=false >> -prevent-rename-internal-symbols=false >> >> >> I enabled the below settings >> >> -js-dynamic-access-unknown-members=true; >> -js-default-initializers=true >> >> >> The release version starts up >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> However, the moment I launch a module. I get the below error >> >> >> >> >> >> >> >> >> >> It appears to be failing when I launch the "Overview" module (by clicking >> the Overview side menu). >> >> >> >> So my current observation is that by retaining only two settings >> >> >> >> -js-dynamic-access-unknown-members=true; >> -js-default-initializers=true >> >> >> >> The release module starts up but the app fails whenever I launch a module. >> >> >> >> The smallest size settings in the documentation do not work. The app does >> not start up. >> >> >> >> -export-public-symbols=false >> -prevent-rename-protected-symbols=false >> -prevent-rename-public-symbols=false >> -prevent-rename-internal-symbols=false >> >> >> >> >> >> >> >> The error trace is below >> >> >> >> >> >> Uncaught TypeError: cm.valuesImpl.init is not a function >> at Wr.Rr.pl <http://wr.rr.pl/> (Overview.js:792) >> at Function.mq.generateMXMLProperties (Overview.js:743) >> at Wr.lq.generateMXMLAttributes (Overview.js:551) >> at new Wr (Overview.js:810) >> at QN.J.loadHandler (FrontEnd.js:1978) >> 3Overview.js:56 Uncaught TypeError: Cannot read properties of undefined >> (reading 'prototype') >> at P (Overview.js:56) >> at VG.convert (FrontEnd.js:910) >> at ny (FrontEnd.js:250) >> at HTMLElement.iy (Fro
Re: Compiling Modules (was Re: Load time is very slow)
I think it will be better for me to share my pom's that way you can see all the compilation options used. The pom for the parent (FmClient2), the MainApp and one module (Overview) have been attached to this email. On Thu, Dec 30, 2021 at 6:22 PM Harbs wrote: > Roman, can you share your full compiler options? > > I decided to remove the below settings completely >> -export-public-symbols=false >> -prevent-rename-protected-symbols=false >> -prevent-rename-public-symbols=false >> -prevent-rename-internal-symbols=false >> >> >> I enabled the below settings >> >> -js-dynamic-access-unknown-members=true; >> -js-default-initializers=true >> >> >> The release version starts up >> >> >> > Hiedra, that’s great! > > On Dec 30, 2021, at 7:15 PM, Roman Isitua wrote: > > > Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO > > On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve > wrote: > >> Roman, are you testing with the SDK compiled from the Harb branches, >> ROYALE_INTERFACE_INFO, or from develop? >> >> >> >> Hiedra >> >> >> >> *De:* Roman Isitua >> *Enviado el:* jueves, 30 de diciembre de 2021 16:52 >> *Para:* users@royale.apache.org >> *Asunto:* Re: Compiling Modules (was Re: Load time is very slow) >> >> >> >> I decided to remove the below settings completely >> -export-public-symbols=false >> -prevent-rename-protected-symbols=false >> -prevent-rename-public-symbols=false >> -prevent-rename-internal-symbols=false >> >> >> I enabled the below settings >> >> -js-dynamic-access-unknown-members=true; >> -js-default-initializers=true >> >> >> The release version starts up >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> However, the moment I launch a module. I get the below error >> >> >> >> >> >> >> >> >> >> It appears to be failing when I launch the "*Overview*" module >> (by clicking the Overview side menu). >> >> >> >> So my current observation is that by retaining only two settings >> >> >> >> -js-dynamic-access-unknown-members=true; >> -js-default-initializers=true >> >> >> >> The release module starts up but the app fails whenever I launch a module. >> >> >> >> The smallest size settings in the documentation do not work. The app does >> not start up. >> >> >> >> -export-public-symbols=false >> -prevent-rename-protected-symbols=false >> -prevent-rename-public-symbols=false >> -prevent-rename-internal-symbols=false >> >> >> >> >> >> >> >> The error trace is below >> >> >> >> >> >> Uncaught TypeError: cm.valuesImpl.init is not a function >> at Wr.Rr.pl <http://wr.rr.pl/> (Overview.js:792) >> at Function.mq.generateMXMLProperties (Overview.js:743) >> at Wr.lq.generateMXMLAttributes (Overview.js:551) >> at new Wr (Overview.js:810) >> at QN.J.loadHandler (FrontEnd.js:1978) >> 3Overview.js:56 Uncaught TypeError: Cannot read properties of undefined >> (reading 'prototype') >> at P (Overview.js:56) >> at VG.convert (FrontEnd.js:910) >> at ny (FrontEnd.js:250) >> at HTMLElement.iy (FrontEnd.js:125) >> at HTMLElement.b (FrontEnd.js:121) >> FrontEnd.js:1649 Uncaught TypeError: M is not a function >> at sM.J.handleMouseOut (FrontEnd.js:1649) >> at Function.ny [as googFireListener] (FrontEnd.js:123) >> at ny (FrontEnd.js:250) >> at HTMLAnchorElement.iy (FrontEnd.js:125) >> at HTMLAnchorElement.b (FrontEnd.js:121) >> FrontEnd.js:1649 Uncaught TypeError: M is not a function >> at sM.J.handleMouseOver (FrontEnd.js:1649) >> at Function.ny [as googFireListener] (FrontEnd.js:123) >> at ny (FrontEnd.js:250) >> at HTMLAnchorElement.iy (FrontEnd.js:125) >> at HTMLAnchorElement.b (FrontEnd.js:121) >> J.handleMouseOver @ FrontEnd.js:1649 >> ny @ FrontEnd.js:123 >> ny @ FrontEnd.js:250 >> iy @ FrontEnd.js:125 >> b @ FrontEnd.js:121 >> FrontEnd.js:1649 Uncaught TypeError: M is not a function >> at sM.J.handleMouseOut (FrontEnd.js:1649) >> at Function.ny [as googFireListener] (FrontEnd.js:123) >> at ny (FrontEnd.js:250) >> at HTMLAnchorElement.iy (FrontEnd.js:125) >> at H
Re: Compiling Modules (was Re: Load time is very slow)
Roman, can you share your full compiler options? > I decided to remove the below settings completely > -export-public-symbols=false > -prevent-rename-protected-symbols=false > -prevent-rename-public-symbols=false > -prevent-rename-internal-symbols=false > > > I enabled the below settings > > -js-dynamic-access-unknown-members=true; > -js-default-initializers=true > > > The release version starts up > > > Hiedra, that’s great! > On Dec 30, 2021, at 7:15 PM, Roman Isitua wrote: > > > Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO > > On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve <mailto:mjest...@iest.com>> wrote: > Roman, are you testing with the SDK compiled from the Harb branches, > ROYALE_INTERFACE_INFO, or from develop? > > > > Hiedra > > > > De: Roman Isitua mailto:romanisi...@gmail.com>> > Enviado el: jueves, 30 de diciembre de 2021 16:52 > Para: users@royale.apache.org <mailto:users@royale.apache.org> > Asunto: Re: Compiling Modules (was Re: Load time is very slow) > > > > I decided to remove the below settings completely > -export-public-symbols=false > -prevent-rename-protected-symbols=false > -prevent-rename-public-symbols=false > -prevent-rename-internal-symbols=false > > > I enabled the below settings > > -js-dynamic-access-unknown-members=true; > -js-default-initializers=true > > > The release version starts up > > > > > > > > > > > > > > > > > > However, the moment I launch a module. I get the below error > > > > > > > > > > It appears to be failing when I launch the "Overview" module (by clicking the > Overview side menu). > > > > So my current observation is that by retaining only two settings > > > > -js-dynamic-access-unknown-members=true; > -js-default-initializers=true > > > > The release module starts up but the app fails whenever I launch a module. > > > > The smallest size settings in the documentation do not work. The app does not > start up. > > > > -export-public-symbols=false > -prevent-rename-protected-symbols=false > -prevent-rename-public-symbols=false > -prevent-rename-internal-symbols=false > > > > > > > > The error trace is below > > > > > > Uncaught TypeError: cm.valuesImpl.init is not a function > at Wr.Rr.pl <http://wr.rr.pl/> (Overview.js:792) > at Function.mq.generateMXMLProperties (Overview.js:743) > at Wr.lq.generateMXMLAttributes (Overview.js:551) > at new Wr (Overview.js:810) > at QN.J.loadHandler (FrontEnd.js:1978) > 3Overview.js:56 Uncaught TypeError: Cannot read properties of undefined > (reading 'prototype') > at P (Overview.js:56) > at VG.convert (FrontEnd.js:910) > at ny (FrontEnd.js:250) > at HTMLElement.iy (FrontEnd.js:125) > at HTMLElement.b (FrontEnd.js:121) > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOut (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOver (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOver @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOut (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOut @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOver (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOver @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > FrontEnd.js:1649 Uncaught TypeE
Re: Compiling Modules (was Re: Load time is very slow)
Hi Harb, Thanks for your response. I have gone through the documentation. I will do my test again starting with the smallest size option and share my findings. Regards, On Thu, Dec 30, 2021 at 10:59 AM Harbs wrote: > Sorry for my deal in responding. > > Let’s take a step back. > > I’m not sure how you are compiling your modules. I just added some content > to the module documentation page which explains what compiler options you > need while compiling modules. (It still needs some editing.) > https://apache.github.io/royale-docs/features/modules#minification > > Are you using those options? > > On Dec 29, 2021, at 2:19 AM, Maria Jose Esteve wrote: > > Hi, Let me join you with these tests > > @Harb, I have compiled the SDK from this branch, > feature/ROYALE_INTERFACE_INFO, > and when running in debug I get this error: > > Message on the PURGE CONSOLE is displayed: > > Cannot convert org.apache.royale.reflection.beads.ClassAliasBead to IBead > > Message in the IDE Window: > > Se produjo una excepción: TypeError: Cannot convert [object Object] to > IBead > at App.org.apache.royale.core.ElementWrapper.addBead ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/core/ElementWrapper.js:114:11 > ) > at App.org.apache.royale.core.HTMLElementWrapper.addBead ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/core/HTMLElementWrapper.js:43:65 > ) > at App.org.apache.royale.jewel.Application.start ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/jewel/Application.js:246:10 > ) > at App.App_loadXML (http://localhost:8080/WNetSuitePlus/App.js:1681:25 > ) > at > org.apache.royale.net.URLLoader.org.apache.royale.events.EventDispatcher.fireListeners > ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/events/EventDispatcher.js:97:23 > ) > at Function.goog.events.EventTarget.dispatchEventInternal_ ( > http://localhost:8080/WNetSuitePlus/library/closure/goog/events/eventtarget.js:381:26 > ) > at > org.apache.royale.net.URLLoader.org.apache.royale.events.EventDispatcher.dispatchEvent > ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/events/EventDispatcher.js:72:37 > ) > at org.apache.royale.net.URLLoader.jsEventHandler ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/net/URLLoader.js:169:12 > ) > > Call stack: > > > > [INFO] Executing MXMLC in tool group Royale with args: [ > > -load-config=D:\Develop_Royale\Projects\WinPlusWebSuite\royaleapp\royalelogin\target\compile-app-config.xml, > -js-default-initializers=true, > -source-map=true, > -js-dynamic-access-unknown-members=true, > > -keep-as3-metadata+=Inject,Dispatcher,EventHandler,Event,PostConstruct,PreDestroy,ViewAdded,ViewRemoved,Bindable,Transient, > -keep-code-with-metadata=Inject, > -show-binding-warnings=false, > -export-public-symbols=false, > -prevent-rename-protected-symbols=false, > -prevent-rename-internal-symbols=false, > > -js-output=D:\Develop_Royale\Projects\WinPlusWebSuite\royaleapp\royalelogin\target\javascript, > -compiler.targets=JSRoyale, > > D:\Develop_Royale\Projects\WinPlusWebSuite\royaleapp\royalelogin\src\main\royale\App.mxml > > > The release execution does not change, the error is the same as before > (SDK compilation from the develop branch): > > Se produjo una excepción: ReferenceError: Error #1065: Variable > com.iest.winplusweb.models.MasterConfigSystemModel is not defined. > at yR (http://localhost:8080/WPWebRelease/App.js:3605:1771) > at Mya (http://localhost:8080/WPWebRelease/App.js:3343:365) > at AR.J.usa (http://localhost:8080/WPWebRelease/App.js:434:441) > at GFa.J.fromTypeDefinition ( > http://localhost:8080/WPWebRelease/App.js:5706:139) > at Function.YT.getTypeDescriptor ( > http://localhost:8080/WPWebRelease/App.js:4570:820) > at Function.fX.constructBean ( > http://localhost:8080/WPWebRelease/App.js:2336:472) > at r$.J.initialize (http://localhost:8080/WPWebRelease/App.js:5041:66) > at OW.J.init (http://localhost:8080/WPWebRelease/App.js:950:452) > at OW.J.u (http://localhost:8080/WPWebRelease/App.js:951:454) > at $$.J.addBead (http://localhost:8080/WPWebRelease/App.js:357:549) > > The main difference: > project compiled from "SDK-develop" runs fine in js-debug and gives error > in js-release and, compiled from "SDK-ROYALE_INTERFACE_INFO" does not > launch because of conversion error. > > Hiedra > > *De:* Roman Isitua > *Enviado el:* martes, 28 de diciembre de 2021 15:55 > *Para:* users@royale.apache.org > *Asunto:* Re: Load time is very slow > > @Harb > > I have checked out the feature/ROYALE_INTERFACE_INFO branch and compiled > asjs and compiler. I have rebuilt my application with modules in release > mode. > > I get the following error when I attempt to launch a module > > > > > > The module loads fine in debug mode > > > > > Snippets of the log > > Overview.js:786 Uncaught TypeError: cm.valuesImpl.init is not a function > at Rr.Mr.yl (Overview.js:786) > at Function.iq.generateMXMLProperties
