Thanks for letting me know Brian. I had run all the examples locally as part of my testing before pushing the changes, and wasn't seeing any problems so I must have missed something. Will take a look very shortly. Usually I wait for the remote builds to run as a final check but I wasn't able to do that this time.
On Sat, May 23, 2020 at 6:44 AM Brian Raymes <[email protected]> wrote: > I will keep you updated over the coming weeks if I run into the same or > similar issue. > > In the meantime, > https://github.com/apache/royale-compiler/commit/96b42e5a980c1d919d0c3a620c500f7a0aff2e9d > seems to be breaking my ability to build royale-asjs with examples: > > Specifically, MXRoyale / RemoteObjectAMFTest errors for the following > reason causing the rest of the build to fail: > > Executing MXMLC in tool group Royale with args: > [-load-config=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/target/compile-app-config.xml, > -js-output=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/target/javascript, > -compiler.targets=JSRoyale, > /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/main/royale/App.mxml] > /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/main/royale/App.mxml > line 20 column 0 Error: Internal error in ASBlockWalker subsystem, when > generating code for: > /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/main/royale/App.mxml > line 20 column 0: java.lang.NullPointerException > at > org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleEmitter.emitPropertyDecls(MXMLRoyaleEmitter.java:1475) > at > org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleEmitter.emitDocument(MXMLRoyaleEmitter.java:884) > at > org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleBlockWalker.visitDocument(MXMLRoyaleBlockWalker.java:69) > at > org.apache.royale.compiler.internal.visitor.mxml.MXMLNodeSwitch.handle(MXMLNodeSwitch.java:89) > at > org.apache.royale.compiler.internal.codegen.mxml.MXMLBlockWalker.walk(MXMLBlockWalker.java:156) > at > org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleBlockWalker.visitFile(MXMLRoyaleBlockWalker.java:61) > at > org.apache.royale.compiler.internal.visitor.mxml.MXMLNodeSwitch.handle(MXMLNodeSwitch.java:95) > at > org.apache.royale.compiler.internal.codegen.mxml.MXMLBlockWalker.walk(MXMLBlockWalker.java:156) > at > org.apache.royale.compiler.internal.codegen.mxml.MXMLBlockWalker.visitCompilationUnit(MXMLBlockWalker.java:187) > at > org.apache.royale.compiler.internal.codegen.mxml.MXMLWriter.writeTo(MXMLWriter.java:69) > at > org.apache.royale.compiler.clients.MXMLJSCRoyale.compile(MXMLJSCRoyale.java:411) > at > org.apache.royale.compiler.clients.MXMLJSCRoyale._mainNoExit(MXMLJSCRoyale.java:259) > at > org.apache.royale.compiler.clients.MXMLJSCRoyale.mainNoExit(MXMLJSCRoyale.java:216) > at > org.apache.royale.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:363) > at > org.apache.royale.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:298) > at > org.apache.royale.compiler.clients.MXMLJSC.execute(MXMLJSC.java:228) > at org.apache.royale.maven.BaseMojo.execute(BaseMojo.java:383) > at > org.apache.royale.maven.CompileAppMojo.execute(CompileAppMojo.java:112) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:193) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347) > > > Thanks, > Brian > > -----Original Message----- > From: Carlos Rovira <[email protected]> > Sent: Friday, May 22, 2020 7:46 AM > To: Apache Royale Development <[email protected]> > Subject: Re: About the cumbersome random compilation issue > > Hi, > > if latest fixes as well fix this issue will be a great new for sure :) > since is random we just can see if it not happen again in the next 1-2 > weeks. > also maybe Brian can tell us about his experience too > > thanks > > > > El vie., 22 may. 2020 a las 13:27, Greg Dove (<[email protected]>) > escribió: > > > Carlos, please see if it still happens after the latest changes. > > I don't know if it will fix it or not, but it's worth a shot, based on > > the symptom that Brian Raymes described. > > > > > > > > On Fri, May 22, 2020 at 11:18 PM Carlos Rovira > > <[email protected]> > > wrote: > > > > > Hi Chris, > > > > > > maybe we're talking on different issues. The current problem is when > > > compiling or building a final application, so the compiler behaves > > > strangely sometimes doing things differently (for that reason I was > > > pointing to some thread throttle issue). If I understand you right, > > > I > > think > > > you're pointing to royale 3 repos building issues that from time to > > > time can hang. That use to be less frecuent than the problem I raise > here. > > > > > > > > > > > > El jue., 21 may. 2020 a las 8:43, Christofer Dutz (< > > > [email protected]>) escribió: > > > > > > > Hi folks, > > > > > > > > I think it might be a resource leak between multiple module > > compilations. > > > > > > > > I never had the issue when running only one module but hat it > > > > quite regularly when doing the full build with all modules. So I > > > > guess > > probably > > > > the modules coming later in the build have a higher chance of > > > > running > > > into > > > > this problem. > > > > > > > > Things did improve when Greg fixed one of the leaks. > > > > But it hasn't gone away completely. > > > > > > > > Chris > > > > ________________________________ > > > > Von: Carlos Rovira <[email protected]> > > > > Gesendet: Mittwoch, 20. Mai 2020 17:48 > > > > An: Apache Royale Development <[email protected]> > > > > Betreff: Re: About the cumbersome random compilation issue > > > > > > > > Hi Greg, > > > > > > > > next time I'll get a fail compilation I'll store the results and > > comment. > > > > Other thing I'm wondering if is something only related to TDJ > > > > (jewel > > > apps) > > > > and that's not happening for Basic, Express, or MXRoyale > > > > > > > > > > > > El mar., 19 may. 2020 a las 0:04, Greg Dove > > > > (<[email protected]>) > > > > escribió: > > > > > > > > > Carlos, it would be good to know if the issue you are seeing is > > > > > the > > > same > > > > > thing. > > > > > > > > > > I know you test mainly in release builds, so if you experience > > > > > that > > > issue > > > > > in a release build, can you confirm the issue is the same as > > > > > Brian > > > > reported > > > > > (missing 'prototype._bindings = [...' in the corresponding debug > > build? > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, May 19, 2020 at 9:55 AM Carlos Rovira < > > [email protected] > > > > > > > > > wrote: > > > > > > > > > > > Thanks Brian, > > > > > > > > > > > > I forgot you already sent similar info some weeks ago. > > > > > > > > > > > > @Greg, you that know that code better, maybe there's some > > > > > > thread > > > issue > > > > > > here? For something that works sometime ok and others not, I > > > > > > think > > > that > > > > > > random behaviour seems a thread issue where there's no syncing. > > Have > > > > that > > > > > > sense? > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > El lun., 18 may. 2020 a las 20:17, Greg Dove > > > > > > (<[email protected] > > >) > > > > > > escribió: > > > > > > > > > > > > > That's interesting Brian, thanks for sharing that. > > > > > > > > > > > > > > I have been working on a fix for inherited bindings, which > > > > > > > is > > > > something > > > > > > > that has never worked but which I needed to work (I now have > > > > > > > that > > > > > working > > > > > > > locally and expect to get that in today). I am not exactly > > > > > > > sure > > why > > > > > what > > > > > > > your saw was happening, but I have made another change > > > > > > > locally > > > which > > > > > > could > > > > > > > theoretically reduce the possibility of the type of thing > > > > > > > you > > > > described > > > > > > > from happening. I was going to revert it, as it is not > > > > > > > central to > > > the > > > > > > issue > > > > > > > for inherited bindings, but I will do more extensive testing > > > > > > > with > > > it > > > > > > > included and see if it is ok to leave in. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, May 19, 2020 at 5:35 AM Brian Raymes < > > > > [email protected] > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > I cannot speak for js-release, but it happens to me with > > js-debug > > > > in > > > > > > what > > > > > > > > seems like 1 in every 10 builds. Possibly more often. > > > > > > > > > > > > > > > > I've made copies a couple times to compare the output. > > > > > > > > Each > > time, > > > > it > > > > > > > > appears that some "prototype._bindings" are missing. Here > > > > > > > > is > > > > example > > > > > > > > related to TourDeJewel: > > > > > > > > > > > > > > > > In NavigationGroupExampleItemRenderer.js, the following is > > > missing > > > > > > > > entirely in a bad build: > > > > > > > > > > > > > > > > /** > > > > > > > > * @export > > > > > > > > */ > > > > > > > > > > > > itemRenderers.NavigationGroupExampleItemRenderer.prototype._bindin > > > > gs > > > > > = > > > > > > [ > > > > > > > > // > > > > > > > > // contents removed for brevity > > > > > > > > // > > > > > > > > ]; > > > > > > > > > > > > > > > > Several of these "xxxxx.prototype._bindings" sections were > > > missing > > > > > from > > > > > > > > the generated JavaScript. > > > > > > > > > > > > > > > > Hope this helps. > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Alex Harui <[email protected]> > > > > > > > > Sent: Sunday, May 17, 2020 8:26 AM > > > > > > > > To: [email protected] > > > > > > > > Subject: Re: About the cumbersome random compilation issue > > > > > > > > > > > > > > > > BTW, is this in js-debug or js-release? > > > > > > > > > > > > > > > > On 5/17/20, 8:20 AM, "Alex Harui" > > > > > > > > <[email protected]> > > > > wrote: > > > > > > > > > > > > > > > > Save a good build. When you think you have a bad > > > > > > > > build, > > > compare > > > > > the > > > > > > > > output. > > > > > > > > > > > > > > > > On 5/17/20, 3:46 AM, "Carlos Rovira" < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I want to open a thread about how to solve the > > > > > > > > weird > > > random > > > > > > > > compilation > > > > > > > > issue where, from time to time, renderers has no > > content. > > > > > > > > > > > > > > > > Since is random, this is hard to find, but seems > > > > > > > > the > > > > problem > > > > > is > > > > > > > > each time > > > > > > > > more easy to get. > > > > > > > > > > > > > > > > I suffer in compling TDJ from time to time. And > > > > > > > > the > > > result > > > > is > > > > > > > that > > > > > > > > some > > > > > > > > times all compiles ok, and other times I get some > > > Navigator > > > > > > > > itemrenders > > > > > > > > without content (use to be per Navigator > > > > > > > > component, so > > > all > > > > > > > renders > > > > > > > > in a > > > > > > > > control are affected), other times are TabBar > > > > > > > > items, > > > other > > > > > > times > > > > > > > > are list > > > > > > > > item renders inside List playground, and so on. > > > > > > > > Some > > > times > > > > > the > > > > > > > > problem > > > > > > > > affects many of the before mentioned controls, and > > other > > > > > times > > > > > > > are > > > > > > > > less of > > > > > > > > them. > > > > > > > > > > > > > > > > I think as TDJ grows, the problem increases, and I > > > > > > > > end > > > > > > compiling > > > > > > > > the same > > > > > > > > 2-3 consecutive times until I get the compilation > > right. > > > > > > > > > > > > > > > > For me this problem is one requirement to reach > > > > > > > > 1.0, > > > since > > > > it > > > > > > > > reveals a > > > > > > > > cumbersome issue, that seems to increase with size > > > > > > > > of > > the > > > > > > source > > > > > > > > code > > > > > > > > involved. > > > > > > > > > > > > > > > > I want to ask here if others are finding this > > > > > > > > issue too > > > in > > > > > > their > > > > > > > > projects, > > > > > > > > examples, etc.. > > > > > > > > > > > > > > > > As well what could be the problem. Any theory? > > > > > > > > > > > > > > > > The problem should be in a compilation task that > > involve > > > > > > > > components that > > > > > > > > uses renderers inside. A based renderer control > > > > > > > > can > > > compile > > > > > ok, > > > > > > > > but the > > > > > > > > next one not, and the next could be right > > > > > > > > again...it's > > > all > > > > > > > random. > > > > > > > > > > > > > > > > It seems a java thread issue where we need to sync > > better > > > > to > > > > > > > > endure things > > > > > > > > are build properly. > > > > > > > > > > > > > > > > Any idea or thing we could try to solve this problem? > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > -- > > > > > > > > Carlos Rovira > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout > > .me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C091b10b063f > > 747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637 > > 253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0 > > VBg%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Carlos Rovira > > > > > > http://about.me/carlosrovira > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Carlos Rovira > > > > http://about.me/carlosrovira > > > > > > > > > > > > > -- > > > Carlos Rovira > > > http://about.me/carlosrovira > > > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira >
