Hi Chris, Carlos, I understand that Crux is working in debug mode, but I
am also working with others to port an app with modules, so that is 'front
and centre' in my thinking as well. That app will use Robotlegs, so I
expect issues could be similar.
Things I have tried:
(a) without using link-reports, but with using variable-map/properties-map
outbound/inbound
classes are being redefined in the module js, but only exported in the app
js.
This means there are two copies of classes. The same renaming is being used
in the module as the main app (so org.apache.royale.utils.Language might be
renamed as 'P' in the main app, it is redefined as a new 'P' in the module,
but only exported as 'org.apache.royale.utils.Language' in the main app).
Apart from module code being much larger than it needs to be, this breaks
'x is Y' or 'x as Y' language checks for instances defined in the app
before the module code is run. It also means that reflection accesses the
old ('exported') class definition with getDefinitionByName (for example)
and not the new one. And it means that event bubbling can be messed up
because the check for the parent being an EventDispatcher doesn't work
(because EventDispatcher has been redefined since the original that was
used in the main app, and bubbling works by checking if 'parent is
EventDispatcher')
Another issue is that dead-code elimination can mean something is omitted
in one of these definitions and not in the other.
What I don't know is whether
-I am doing something wrong
-There is some sort of regression
-this is not new, but has not been observed as an issue under the specific
use cases in the past
(b) I was able to compile and build using link-report-js.xml. I was hoping
this would fix things, but it did not
(c) I tried switching gcc to SIMPLE_OPTIMIZATIONS but that also did not fix
the problem
(d) tried combination of (b) and (c)
Anyway, I can't spend more time on this until next weekend, but I just
wanted to check for consensus on the status of modules.
On Mon, Sep 28, 2020 at 3:49 AM Carlos Rovira <[email protected]>
wrote:
> Hi,
>
> crux app with lots of crux modules are the final objective. So getting that
> to work right is essential for Royale and for a 1.0 version (IMHO).
>
> El dom., 27 sept. 2020 a las 13:03, Christofer Dutz (<
> [email protected]>) escribió:
>
> > Hi Greg,
> >
> > For the sake of completeness (I know you know that I try to do all sorts
> > of "crazy" stuff ;-) )
> > In my application I make extensive use of modules. Every module on the
> > server-side has a set of up to 3 frontend modules (Main, User-Settings,
> > System-Settings)
> > Depending on the logged in users permissions the main loader application
> > loads all of the modules the user is allowed to use.
> >
> > Inside each module I create a Crux context, which becomes a child
> context,
> > accessing services of the main loader application.
> >
> > Chris
> >
> >
> > Am 27.09.20, 07:02 schrieb "Greg Dove" <[email protected]>:
> >
> > I'd be keen to hear others who are using/have used modules in Royale.
> >
> > Outside of very simple examples I see issues with release builds.
> >
> > For those that use them (with success) what build settings have you
> > used?
> >
> > In particular:
> > -are you using link-report as output from the application and input
> to
> > the
> > modules, as was the case in Flex?
> > -are you switching off any ADVANCED_OPTIMIZATIONS in GCC to get
> > modules to
> > work?
> >
> > thanks,
> > Greg
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
