You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2020/05/17 10:46:28 UTC
About the cumbersome random compilation issue
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
http://about.me/carlosrovira
Re: About the cumbersome random compilation issue
Posted by Christofer Dutz <ch...@c-ware.de>.
Oh,
ok ... indeed I was talking about the hanging of the build were you have to kill the process.
Sorry for the confusion.
Chris
锘緼m 22.05.20, 13:18 schrieb "Carlos Rovira" <ca...@apache.org>:
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 (<
christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
> Gesendet: Mittwoch, 20. Mai 2020 17:48
> An: Apache Royale Development <de...@royale.apache.org>
> 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 (<gr...@gmail.com>)
> 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 <ca...@apache.org>
> > 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 (<gr...@gmail.com>)
> > > 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 <
> brian.raymes@teotech.com
> > >
> > > > 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._bindings
> > =
> > > [
> > > > > //
> > > > > // 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 <ah...@adobe.com.INVALID>
> > > > > Sent: Sunday, May 17, 2020 8:26 AM
> > > > > To: dev@royale.apache.org
> > > > > 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" <ah...@adobe.com.INVALID>
> 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" <ca...@apache.org>
> > > > 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Carlos Rovira
http://about.me/carlosrovira
RE: About the cumbersome random compilation issue
Posted by Brian Raymes <br...@teotech.com>.
I want to say I may have seen the behavior once since the changes were made -- but I didn't compare the output to see if it was the same binding issue that I was seeing.
If I ever see it again, I'll compare and report back. Otherwise, I must be lucky 馃槈
-----Original Message-----
From: Carlos Rovira <ca...@apache.org>
Sent: Monday, September 7, 2020 1:13 AM
To: Apache Royale Development <de...@royale.apache.org>
Subject: Re: About the cumbersome random compilation issue
Hi Greg,
thanks for getting back this thread, I had in mind various times, but always other things come up and avoid to report.
I'm sorry to say that the problem is not solved 100%, but the issue happens much less than before.
I still can get the behaviour from time to time. I think the problem could be now much more hard to find and fix.
Did you know the cause so I can know more about it? At first glance, I thought we had some java thread problem in the compiler, since having different results sometimes is something that can be related to synchronization of thread. Could be that the case?. Maybe your solution made the code run more synchronously but we still need to add some thread safe code. Since I don't know much more about the problem maybe I'm saying nonsense here...
Thanks, anyway, the problem now is seen less times, which is far better from what we had 4 months ago :)
El lun., 7 sept. 2020 a las 6:25, Greg Dove (<gr...@gmail.com>)
escribi贸:
> Carlos, Brian, I am just curious whether there was an improvement/fix
> for the original problem from this thread.
> I have fingers crossed that it was fixed with the change I made
> earlier, but I did not hear anything to confirm that. (I am hopeful
> that 'no news is good news').
>
> The original problem was these:
> Carlos: 'weird random compilation issue where, from time to time,
> renderers has no content'
>
> Brian: missing 'prototype._bindings = [...' in the corresponding debug
> build js output )
>
>
>
>
> On Sat, May 23, 2020 at 10:39 AM Brian Raymes
> <br...@teotech.com>
> wrote:
>
> > No problem. I'm happy to assist. I'll update and let you know if I
> > run into any issues.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Greg Dove <gr...@gmail.com>
> > Sent: Friday, May 22, 2020 2:03 PM
> > To: Apache Royale Development <de...@royale.apache.org>
> > Subject: Re: About the cumbersome random compilation issue
> >
> > Thanks again, I believe it should be fixed now, Brian.
> > I think there was some unnecessary declaration output being written
> > previously that should not have been - for the generated 'operations'
> > Object of the RemoteObject in this case, but perhaps there could
> > have
> been
> > other cases where this was happening.
> >
> >
> > On Sat, May 23, 2020 at 7:50 AM Greg Dove <gr...@gmail.com> wrote:
> >
> > >
> > > Ok I repro'ed that. Not sure how I missed it at all... unless
> > > maybe I made some minor changes after my last test of the
> > > examples. Will figure
> > this out.
> > >
> > >
> > > On Sat, May 23, 2020 at 7:40 AM Greg Dove <gr...@gmail.com> wrote:
> > >
> > >> 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
> > >> <br...@teotech.com>
> > >> 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/96b42e5a980c1d9
> > >>> 19d0 c3a620c500f7a0aff2e9d 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/RemoteObj
> > >>> ectA MFTest/target/compile-app-config.xml,
> > >>> -js-output=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObject
> > >>> AMFT
> > >>> est/target/javascript,
> > >>> -compiler.targets=JSRoyale,
> > >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src
> > >>> /mai
> > >>> n/royale/App.mxml]
> > >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src
> > >>> /mai n/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
> > >>> /mai n/royale/App.mxml line 20 column 0:
> > >>> java.lang.NullPointerException
> > >>> at
> > >>>
> >
> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleEmit
> ter.emitPropertyDecls(MXMLRoyaleEmitter.java:1475)
> > >>> at
> > >>>
> >
> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleEmit
> ter.emitDocument(MXMLRoyaleEmitter.java:884)
> > >>> at
> > >>>
> >
> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleBloc
> kWalker.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.MXMLRoyaleBloc
> kWalker.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.visit
> CompilationUnit(MXMLBlockWalker.java:187)
> > >>> at
> > >>>
> >
> org.apache.royale.compiler.internal.codegen.mxml.MXMLWriter.writeTo(MX
> MLWriter.java:69)
> > >>> at
> > >>>
> >
> org.apache.royale.compiler.clients.MXMLJSCRoyale.compile(MXMLJSCRoyale
> .java:411)
> > >>> at
> > >>>
> >
> org.apache.royale.compiler.clients.MXMLJSCRoyale._mainNoExit(MXMLJSCRo
> yale.java:259)
> > >>> at
> > >>>
> >
> org.apache.royale.compiler.clients.MXMLJSCRoyale.mainNoExit(MXMLJSCRoy
> ale.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(DefaultB
> uildPluginManager.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.buildProjec
> t(LifecycleModuleBuilder.java:117)
> > >>> at
> > >>>
> >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProjec
> t(LifecycleModuleBuilder.java:81)
> > >>> at
> > >>>
> >
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThrea
> dedBuilder.build(SingleThreadedBuilder.java:56)
> > >>> at
> > >>>
> >
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycle
> Starter.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(
> > >>> Nati
> > >>> ve
> > >>> Method)
> > >>> at
> > >>>
> >
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeM
> ethodAccessorImpl.java:62)
> > >>> at
> > >>>
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Del
> egatingMethodAccessorImpl.java:43)
> > >>> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> > >>> at
> > >>>
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launc
> her.java:282)
> > >>> at
> > >>>
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java
> :225)
> > >>> at
> > >>>
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Lau
> ncher.java:406)
> > >>> at
> > >>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.
> > >>> java
> > >>> :347)
> > >>>
> > >>>
> > >>> Thanks,
> > >>> Brian
> > >>>
> > >>> -----Original Message-----
> > >>> From: Carlos Rovira <ca...@apache.org>
> > >>> Sent: Friday, May 22, 2020 7:46 AM
> > >>> To: Apache Royale Development <de...@royale.apache.org>
> > >>> 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
> > >>> (<gr...@gmail.com>)
> > >>> 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
> > >>> > <ca...@apache.org>
> > >>> > 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 (<
> > >>> > > christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
> > >>> > > > Gesendet: Mittwoch, 20. Mai 2020 17:48
> > >>> > > > An: Apache Royale Development <de...@royale.apache.org>
> > >>> > > > 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
> > >>> > > > (<gr...@gmail.com>)
> > >>> > > > 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 <
> > >>> > carlosrovira@apache.org
> > >>> > > >
> > >>> > > > > 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
> > >>> > > > > > (<greg.dove@gmail.com
> > >>> > >)
> > >>> > > > > > 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 <
> > >>> > > > brian.raymes@teotech.com
> > >>> > > > > >
> > >>> > > > > > > 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
> > >>> > > > ._bi
> > >>> > > > ndin
> > >>> > > > 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 <ah...@adobe.com.INVALID>
> > >>> > > > > > > > Sent: Sunday, May 17, 2020 8:26 AM
> > >>> > > > > > > > To: dev@royale.apache.org
> > >>> > > > > > > > Subject: Re: About the cumbersome random
> > >>> > > > > > > > compilation issue
> > >>> > > > > > > >
> > >>> > > > > > > > BTW, is this in js-debug or js-release?
> > >>> > > > > > > >
> > >>> > > > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui"
> > >>> > > > > > > > <ah...@adobe.com.INVALID>
> > >>> > > > 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" <
> > >>> > > carlosrovira@apache.org>
> > >>> > > > > > > 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
> > >>> > %2Fa
> > >>> > bout
> > >>> > .me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C091
> > >>> > b10b
> > >>> > 063f
> > >>> > 747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7
> > >>> > C0%7
> > >>> > C637
> > >>> > 253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZ
> > >>> > qw6K
> > >>> > qpo0
> > >>> > 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
> > >>>
> > >>
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: About the cumbersome random compilation issue
Posted by Carlos Rovira <ca...@apache.org>.
Hi Greg,
thanks for getting back this thread, I had in mind various times, but
always other things come up and avoid to report.
I'm sorry to say that the problem is not solved 100%, but the issue happens
much less than before.
I still can get the behaviour from time to time. I think the problem could
be now much more hard to find and fix.
Did you know the cause so I can know more about it? At first glance, I
thought we had some java thread problem in the compiler, since having
different results sometimes is something that can be related to
synchronization of thread. Could be that the case?. Maybe your solution
made the code run more synchronously but we still need to add some thread
safe code. Since I don't know much more about the problem maybe I'm saying
nonsense here...
Thanks, anyway, the problem now is seen less times, which is far better
from what we had 4 months ago :)
El lun., 7 sept. 2020 a las 6:25, Greg Dove (<gr...@gmail.com>)
escribi贸:
> Carlos, Brian, I am just curious whether there was an improvement/fix for
> the original problem from this thread.
> I have fingers crossed that it was fixed with the change I made earlier,
> but I did not hear anything to confirm that. (I am hopeful that 'no news is
> good news').
>
> The original problem was these:
> Carlos: 'weird random compilation issue where, from time to time, renderers
> has no content'
>
> Brian: missing 'prototype._bindings = [...' in the corresponding debug
> build js output )
>
>
>
>
> On Sat, May 23, 2020 at 10:39 AM Brian Raymes <br...@teotech.com>
> wrote:
>
> > No problem. I'm happy to assist. I'll update and let you know if I run
> > into any issues.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Greg Dove <gr...@gmail.com>
> > Sent: Friday, May 22, 2020 2:03 PM
> > To: Apache Royale Development <de...@royale.apache.org>
> > Subject: Re: About the cumbersome random compilation issue
> >
> > Thanks again, I believe it should be fixed now, Brian.
> > I think there was some unnecessary declaration output being written
> > previously that should not have been - for the generated 'operations'
> > Object of the RemoteObject in this case, but perhaps there could have
> been
> > other cases where this was happening.
> >
> >
> > On Sat, May 23, 2020 at 7:50 AM Greg Dove <gr...@gmail.com> wrote:
> >
> > >
> > > Ok I repro'ed that. Not sure how I missed it at all... unless maybe I
> > > made some minor changes after my last test of the examples. Will figure
> > this out.
> > >
> > >
> > > On Sat, May 23, 2020 at 7:40 AM Greg Dove <gr...@gmail.com> wrote:
> > >
> > >> 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
> > >> <br...@teotech.com>
> > >> 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/96b42e5a980c1d919d0
> > >>> c3a620c500f7a0aff2e9d 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/RemoteObjectA
> > >>> MFTest/target/compile-app-config.xml,
> > >>> -js-output=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFT
> > >>> est/target/javascript,
> > >>> -compiler.targets=JSRoyale,
> > >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/mai
> > >>> n/royale/App.mxml]
> > >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/mai
> > >>> n/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/mai
> > >>> n/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(Nati
> > >>> ve
> > >>> 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 <ca...@apache.org>
> > >>> Sent: Friday, May 22, 2020 7:46 AM
> > >>> To: Apache Royale Development <de...@royale.apache.org>
> > >>> 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 (<gr...@gmail.com>)
> > >>> 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
> > >>> > <ca...@apache.org>
> > >>> > 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 (<
> > >>> > > christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
> > >>> > > > Gesendet: Mittwoch, 20. Mai 2020 17:48
> > >>> > > > An: Apache Royale Development <de...@royale.apache.org>
> > >>> > > > 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
> > >>> > > > (<gr...@gmail.com>)
> > >>> > > > 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 <
> > >>> > carlosrovira@apache.org
> > >>> > > >
> > >>> > > > > 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
> > >>> > > > > > (<greg.dove@gmail.com
> > >>> > >)
> > >>> > > > > > 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 <
> > >>> > > > brian.raymes@teotech.com
> > >>> > > > > >
> > >>> > > > > > > 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._bi
> > >>> > > > ndin
> > >>> > > > 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 <ah...@adobe.com.INVALID>
> > >>> > > > > > > > Sent: Sunday, May 17, 2020 8:26 AM
> > >>> > > > > > > > To: dev@royale.apache.org
> > >>> > > > > > > > Subject: Re: About the cumbersome random compilation
> > >>> > > > > > > > issue
> > >>> > > > > > > >
> > >>> > > > > > > > BTW, is this in js-debug or js-release?
> > >>> > > > > > > >
> > >>> > > > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui"
> > >>> > > > > > > > <ah...@adobe.com.INVALID>
> > >>> > > > 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" <
> > >>> > > carlosrovira@apache.org>
> > >>> > > > > > > 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%2Fa
> > >>> > bout
> > >>> > .me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C091b10b
> > >>> > 063f
> > >>> > 747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7
> > >>> > C637
> > >>> > 253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6K
> > >>> > qpo0
> > >>> > 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
> > >>>
> > >>
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
RE: About the cumbersome random compilation issue
Posted by Brian Raymes <br...@teotech.com>.
In my case, no news has been great news. At the time, it was happening in 5-10% of all builds. It's been great since the change.
Thanks again for your support!
Brian
-----Original Message-----
From: Greg Dove <gr...@gmail.com>
Sent: Sunday, September 6, 2020 9:25 PM
To: Apache Royale Development <de...@royale.apache.org>
Subject: Re: About the cumbersome random compilation issue
Carlos, Brian, I am just curious whether there was an improvement/fix for the original problem from this thread.
I have fingers crossed that it was fixed with the change I made earlier, but I did not hear anything to confirm that. (I am hopeful that 'no news is good news').
The original problem was these:
Carlos: 'weird random compilation issue where, from time to time, renderers has no content'
Brian: missing 'prototype._bindings = [...' in the corresponding debug build js output )
On Sat, May 23, 2020 at 10:39 AM Brian Raymes <br...@teotech.com>
wrote:
> No problem. I'm happy to assist. I'll update and let you know if I run
> into any issues.
>
> Brian
>
> -----Original Message-----
> From: Greg Dove <gr...@gmail.com>
> Sent: Friday, May 22, 2020 2:03 PM
> To: Apache Royale Development <de...@royale.apache.org>
> Subject: Re: About the cumbersome random compilation issue
>
> Thanks again, I believe it should be fixed now, Brian.
> I think there was some unnecessary declaration output being written
> previously that should not have been - for the generated 'operations'
> Object of the RemoteObject in this case, but perhaps there could have
> been other cases where this was happening.
>
>
> On Sat, May 23, 2020 at 7:50 AM Greg Dove <gr...@gmail.com> wrote:
>
> >
> > Ok I repro'ed that. Not sure how I missed it at all... unless maybe
> > I made some minor changes after my last test of the examples. Will
> > figure
> this out.
> >
> >
> > On Sat, May 23, 2020 at 7:40 AM Greg Dove <gr...@gmail.com> wrote:
> >
> >> 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
> >> <br...@teotech.com>
> >> 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/96b42e5a980c1d919
> >>> d0 c3a620c500f7a0aff2e9d 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/RemoteObjec
> >>> tA MFTest/target/compile-app-config.xml,
> >>> -js-output=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAM
> >>> FT
> >>> est/target/javascript,
> >>> -compiler.targets=JSRoyale,
> >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/m
> >>> ai
> >>> n/royale/App.mxml]
> >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/m
> >>> ai n/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/m
> >>> ai n/royale/App.mxml line 20 column 0:
> >>> java.lang.NullPointerException
> >>> at
> >>>
> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleEmit
> ter.emitPropertyDecls(MXMLRoyaleEmitter.java:1475)
> >>> at
> >>>
> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleEmit
> ter.emitDocument(MXMLRoyaleEmitter.java:884)
> >>> at
> >>>
> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleBloc
> kWalker.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.MXMLRoyaleBloc
> kWalker.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.visit
> CompilationUnit(MXMLBlockWalker.java:187)
> >>> at
> >>>
> org.apache.royale.compiler.internal.codegen.mxml.MXMLWriter.writeTo(MX
> MLWriter.java:69)
> >>> at
> >>>
> org.apache.royale.compiler.clients.MXMLJSCRoyale.compile(MXMLJSCRoyale
> .java:411)
> >>> at
> >>>
> org.apache.royale.compiler.clients.MXMLJSCRoyale._mainNoExit(MXMLJSCRo
> yale.java:259)
> >>> at
> >>>
> org.apache.royale.compiler.clients.MXMLJSCRoyale.mainNoExit(MXMLJSCRoy
> ale.java:216)
> >>> at
> >>>
> org.apache.royale.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:36
> 3)
> >>> 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(DefaultB
> uildPluginManager.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.buildProjec
> t(LifecycleModuleBuilder.java:117)
> >>> at
> >>>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProjec
> t(LifecycleModuleBuilder.java:81)
> >>> at
> >>>
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThrea
> dedBuilder.build(SingleThreadedBuilder.java:56)
> >>> at
> >>>
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycle
> Starter.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(Na
> >>> ti
> >>> ve
> >>> Method)
> >>> at
> >>>
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeM
> ethodAccessorImpl.java:62)
> >>> at
> >>>
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Del
> egatingMethodAccessorImpl.java:43)
> >>> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> >>> at
> >>>
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launc
> her.java:282)
> >>> at
> >>>
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java
> :225)
> >>> at
> >>>
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Lau
> ncher.java:406)
> >>> at
> >>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.ja
> >>> va
> >>> :347)
> >>>
> >>>
> >>> Thanks,
> >>> Brian
> >>>
> >>> -----Original Message-----
> >>> From: Carlos Rovira <ca...@apache.org>
> >>> Sent: Friday, May 22, 2020 7:46 AM
> >>> To: Apache Royale Development <de...@royale.apache.org>
> >>> 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
> >>> (<gr...@gmail.com>)
> >>> 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
> >>> > <ca...@apache.org>
> >>> > 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 (<
> >>> > > christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
> >>> > > > Gesendet: Mittwoch, 20. Mai 2020 17:48
> >>> > > > An: Apache Royale Development <de...@royale.apache.org>
> >>> > > > 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
> >>> > > > (<gr...@gmail.com>)
> >>> > > > 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 <
> >>> > carlosrovira@apache.org
> >>> > > >
> >>> > > > > 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
> >>> > > > > > (<greg.dove@gmail.com
> >>> > >)
> >>> > > > > > 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 <
> >>> > > > brian.raymes@teotech.com
> >>> > > > > >
> >>> > > > > > > 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._
> >>> > > > bi
> >>> > > > ndin
> >>> > > > 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 <ah...@adobe.com.INVALID>
> >>> > > > > > > > Sent: Sunday, May 17, 2020 8:26 AM
> >>> > > > > > > > To: dev@royale.apache.org
> >>> > > > > > > > Subject: Re: About the cumbersome random compilation
> >>> > > > > > > > issue
> >>> > > > > > > >
> >>> > > > > > > > BTW, is this in js-debug or js-release?
> >>> > > > > > > >
> >>> > > > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui"
> >>> > > > > > > > <ah...@adobe.com.INVALID>
> >>> > > > 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" <
> >>> > > carlosrovira@apache.org>
> >>> > > > > > > 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%2
> >>> > Fa
> >>> > bout
> >>> > .me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C091b1
> >>> > 0b
> >>> > 063f
> >>> > 747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0
> >>> > %7
> >>> > C637
> >>> > 253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw
> >>> > 6K
> >>> > qpo0
> >>> > 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
> >>>
> >>
>
Re: About the cumbersome random compilation issue
Posted by Greg Dove <gr...@gmail.com>.
Carlos, Brian, I am just curious whether there was an improvement/fix for
the original problem from this thread.
I have fingers crossed that it was fixed with the change I made earlier,
but I did not hear anything to confirm that. (I am hopeful that 'no news is
good news').
The original problem was these:
Carlos: 'weird random compilation issue where, from time to time, renderers
has no content'
Brian: missing 'prototype._bindings = [...' in the corresponding debug
build js output )
On Sat, May 23, 2020 at 10:39 AM Brian Raymes <br...@teotech.com>
wrote:
> No problem. I'm happy to assist. I'll update and let you know if I run
> into any issues.
>
> Brian
>
> -----Original Message-----
> From: Greg Dove <gr...@gmail.com>
> Sent: Friday, May 22, 2020 2:03 PM
> To: Apache Royale Development <de...@royale.apache.org>
> Subject: Re: About the cumbersome random compilation issue
>
> Thanks again, I believe it should be fixed now, Brian.
> I think there was some unnecessary declaration output being written
> previously that should not have been - for the generated 'operations'
> Object of the RemoteObject in this case, but perhaps there could have been
> other cases where this was happening.
>
>
> On Sat, May 23, 2020 at 7:50 AM Greg Dove <gr...@gmail.com> wrote:
>
> >
> > Ok I repro'ed that. Not sure how I missed it at all... unless maybe I
> > made some minor changes after my last test of the examples. Will figure
> this out.
> >
> >
> > On Sat, May 23, 2020 at 7:40 AM Greg Dove <gr...@gmail.com> wrote:
> >
> >> 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
> >> <br...@teotech.com>
> >> 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/96b42e5a980c1d919d0
> >>> c3a620c500f7a0aff2e9d 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/RemoteObjectA
> >>> MFTest/target/compile-app-config.xml,
> >>> -js-output=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFT
> >>> est/target/javascript,
> >>> -compiler.targets=JSRoyale,
> >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/mai
> >>> n/royale/App.mxml]
> >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/mai
> >>> n/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/mai
> >>> n/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(Nati
> >>> ve
> >>> 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 <ca...@apache.org>
> >>> Sent: Friday, May 22, 2020 7:46 AM
> >>> To: Apache Royale Development <de...@royale.apache.org>
> >>> 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 (<gr...@gmail.com>)
> >>> 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
> >>> > <ca...@apache.org>
> >>> > 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 (<
> >>> > > christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
> >>> > > > Gesendet: Mittwoch, 20. Mai 2020 17:48
> >>> > > > An: Apache Royale Development <de...@royale.apache.org>
> >>> > > > 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
> >>> > > > (<gr...@gmail.com>)
> >>> > > > 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 <
> >>> > carlosrovira@apache.org
> >>> > > >
> >>> > > > > 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
> >>> > > > > > (<greg.dove@gmail.com
> >>> > >)
> >>> > > > > > 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 <
> >>> > > > brian.raymes@teotech.com
> >>> > > > > >
> >>> > > > > > > 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._bi
> >>> > > > ndin
> >>> > > > 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 <ah...@adobe.com.INVALID>
> >>> > > > > > > > Sent: Sunday, May 17, 2020 8:26 AM
> >>> > > > > > > > To: dev@royale.apache.org
> >>> > > > > > > > Subject: Re: About the cumbersome random compilation
> >>> > > > > > > > issue
> >>> > > > > > > >
> >>> > > > > > > > BTW, is this in js-debug or js-release?
> >>> > > > > > > >
> >>> > > > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui"
> >>> > > > > > > > <ah...@adobe.com.INVALID>
> >>> > > > 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" <
> >>> > > carlosrovira@apache.org>
> >>> > > > > > > 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%2Fa
> >>> > bout
> >>> > .me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C091b10b
> >>> > 063f
> >>> > 747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7
> >>> > C637
> >>> > 253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6K
> >>> > qpo0
> >>> > 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
> >>>
> >>
>
RE: About the cumbersome random compilation issue
Posted by Brian Raymes <br...@teotech.com>.
No problem. I'm happy to assist. I'll update and let you know if I run into any issues.
Brian
-----Original Message-----
From: Greg Dove <gr...@gmail.com>
Sent: Friday, May 22, 2020 2:03 PM
To: Apache Royale Development <de...@royale.apache.org>
Subject: Re: About the cumbersome random compilation issue
Thanks again, I believe it should be fixed now, Brian.
I think there was some unnecessary declaration output being written previously that should not have been - for the generated 'operations'
Object of the RemoteObject in this case, but perhaps there could have been other cases where this was happening.
On Sat, May 23, 2020 at 7:50 AM Greg Dove <gr...@gmail.com> wrote:
>
> Ok I repro'ed that. Not sure how I missed it at all... unless maybe I
> made some minor changes after my last test of the examples. Will figure this out.
>
>
> On Sat, May 23, 2020 at 7:40 AM Greg Dove <gr...@gmail.com> wrote:
>
>> 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
>> <br...@teotech.com>
>> 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/96b42e5a980c1d919d0
>>> c3a620c500f7a0aff2e9d 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/RemoteObjectA
>>> MFTest/target/compile-app-config.xml,
>>> -js-output=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFT
>>> est/target/javascript,
>>> -compiler.targets=JSRoyale,
>>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/mai
>>> n/royale/App.mxml]
>>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/mai
>>> n/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/mai
>>> n/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(Nati
>>> ve
>>> 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 <ca...@apache.org>
>>> Sent: Friday, May 22, 2020 7:46 AM
>>> To: Apache Royale Development <de...@royale.apache.org>
>>> 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 (<gr...@gmail.com>)
>>> 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
>>> > <ca...@apache.org>
>>> > 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 (<
>>> > > christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
>>> > > > Gesendet: Mittwoch, 20. Mai 2020 17:48
>>> > > > An: Apache Royale Development <de...@royale.apache.org>
>>> > > > 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
>>> > > > (<gr...@gmail.com>)
>>> > > > 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 <
>>> > carlosrovira@apache.org
>>> > > >
>>> > > > > 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
>>> > > > > > (<greg.dove@gmail.com
>>> > >)
>>> > > > > > 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 <
>>> > > > brian.raymes@teotech.com
>>> > > > > >
>>> > > > > > > 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._bi
>>> > > > ndin
>>> > > > 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 <ah...@adobe.com.INVALID>
>>> > > > > > > > Sent: Sunday, May 17, 2020 8:26 AM
>>> > > > > > > > To: dev@royale.apache.org
>>> > > > > > > > Subject: Re: About the cumbersome random compilation
>>> > > > > > > > issue
>>> > > > > > > >
>>> > > > > > > > BTW, is this in js-debug or js-release?
>>> > > > > > > >
>>> > > > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui"
>>> > > > > > > > <ah...@adobe.com.INVALID>
>>> > > > 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" <
>>> > > carlosrovira@apache.org>
>>> > > > > > > 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%2Fa
>>> > bout
>>> > .me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C091b10b
>>> > 063f
>>> > 747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7
>>> > C637
>>> > 253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6K
>>> > qpo0
>>> > 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
>>>
>>
Re: About the cumbersome random compilation issue
Posted by Greg Dove <gr...@gmail.com>.
Thanks again, I believe it should be fixed now, Brian.
I think there was some unnecessary declaration output being written
previously that should not have been - for the generated 'operations'
Object of the RemoteObject in this case, but perhaps there could have been
other cases where this was happening.
On Sat, May 23, 2020 at 7:50 AM Greg Dove <gr...@gmail.com> wrote:
>
> Ok I repro'ed that. Not sure how I missed it at all... unless maybe I made
> some minor changes after my last test of the examples. Will figure this out.
>
>
> On Sat, May 23, 2020 at 7:40 AM Greg Dove <gr...@gmail.com> wrote:
>
>> 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 <br...@teotech.com>
>> 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 <ca...@apache.org>
>>> Sent: Friday, May 22, 2020 7:46 AM
>>> To: Apache Royale Development <de...@royale.apache.org>
>>> 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 (<gr...@gmail.com>)
>>> 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
>>> > <ca...@apache.org>
>>> > 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 (<
>>> > > christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
>>> > > > Gesendet: Mittwoch, 20. Mai 2020 17:48
>>> > > > An: Apache Royale Development <de...@royale.apache.org>
>>> > > > 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
>>> > > > (<gr...@gmail.com>)
>>> > > > 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 <
>>> > carlosrovira@apache.org
>>> > > >
>>> > > > > 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
>>> > > > > > (<greg.dove@gmail.com
>>> > >)
>>> > > > > > 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 <
>>> > > > brian.raymes@teotech.com
>>> > > > > >
>>> > > > > > > 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 <ah...@adobe.com.INVALID>
>>> > > > > > > > Sent: Sunday, May 17, 2020 8:26 AM
>>> > > > > > > > To: dev@royale.apache.org
>>> > > > > > > > Subject: Re: About the cumbersome random compilation issue
>>> > > > > > > >
>>> > > > > > > > BTW, is this in js-debug or js-release?
>>> > > > > > > >
>>> > > > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui"
>>> > > > > > > > <ah...@adobe.com.INVALID>
>>> > > > 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" <
>>> > > carlosrovira@apache.org>
>>> > > > > > > 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
>>>
>>
Re: About the cumbersome random compilation issue
Posted by Greg Dove <gr...@gmail.com>.
Ok I repro'ed that. Not sure how I missed it at all... unless maybe I made
some minor changes after my last test of the examples. Will figure this out.
On Sat, May 23, 2020 at 7:40 AM Greg Dove <gr...@gmail.com> wrote:
> 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 <br...@teotech.com>
> 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 <ca...@apache.org>
>> Sent: Friday, May 22, 2020 7:46 AM
>> To: Apache Royale Development <de...@royale.apache.org>
>> 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 (<gr...@gmail.com>)
>> 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
>> > <ca...@apache.org>
>> > 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 (<
>> > > christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
>> > > > Gesendet: Mittwoch, 20. Mai 2020 17:48
>> > > > An: Apache Royale Development <de...@royale.apache.org>
>> > > > 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
>> > > > (<gr...@gmail.com>)
>> > > > 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 <
>> > carlosrovira@apache.org
>> > > >
>> > > > > 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
>> > > > > > (<greg.dove@gmail.com
>> > >)
>> > > > > > 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 <
>> > > > brian.raymes@teotech.com
>> > > > > >
>> > > > > > > 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 <ah...@adobe.com.INVALID>
>> > > > > > > > Sent: Sunday, May 17, 2020 8:26 AM
>> > > > > > > > To: dev@royale.apache.org
>> > > > > > > > Subject: Re: About the cumbersome random compilation issue
>> > > > > > > >
>> > > > > > > > BTW, is this in js-debug or js-release?
>> > > > > > > >
>> > > > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui"
>> > > > > > > > <ah...@adobe.com.INVALID>
>> > > > 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" <
>> > > carlosrovira@apache.org>
>> > > > > > > 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
>>
>
Re: About the cumbersome random compilation issue
Posted by Greg Dove <gr...@gmail.com>.
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 <br...@teotech.com>
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 <ca...@apache.org>
> Sent: Friday, May 22, 2020 7:46 AM
> To: Apache Royale Development <de...@royale.apache.org>
> 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 (<gr...@gmail.com>)
> 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
> > <ca...@apache.org>
> > 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 (<
> > > christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
> > > > Gesendet: Mittwoch, 20. Mai 2020 17:48
> > > > An: Apache Royale Development <de...@royale.apache.org>
> > > > 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
> > > > (<gr...@gmail.com>)
> > > > 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 <
> > carlosrovira@apache.org
> > > >
> > > > > 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
> > > > > > (<greg.dove@gmail.com
> > >)
> > > > > > 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 <
> > > > brian.raymes@teotech.com
> > > > > >
> > > > > > > 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 <ah...@adobe.com.INVALID>
> > > > > > > > Sent: Sunday, May 17, 2020 8:26 AM
> > > > > > > > To: dev@royale.apache.org
> > > > > > > > Subject: Re: About the cumbersome random compilation issue
> > > > > > > >
> > > > > > > > BTW, is this in js-debug or js-release?
> > > > > > > >
> > > > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui"
> > > > > > > > <ah...@adobe.com.INVALID>
> > > > 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" <
> > > carlosrovira@apache.org>
> > > > > > > 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
>
RE: About the cumbersome random compilation issue
Posted by Brian Raymes <br...@teotech.com>.
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 <ca...@apache.org>
Sent: Friday, May 22, 2020 7:46 AM
To: Apache Royale Development <de...@royale.apache.org>
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 (<gr...@gmail.com>)
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
> <ca...@apache.org>
> 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 (<
> > christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
> > > Gesendet: Mittwoch, 20. Mai 2020 17:48
> > > An: Apache Royale Development <de...@royale.apache.org>
> > > 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
> > > (<gr...@gmail.com>)
> > > 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 <
> carlosrovira@apache.org
> > >
> > > > 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
> > > > > (<greg.dove@gmail.com
> >)
> > > > > 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 <
> > > brian.raymes@teotech.com
> > > > >
> > > > > > 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 <ah...@adobe.com.INVALID>
> > > > > > > Sent: Sunday, May 17, 2020 8:26 AM
> > > > > > > To: dev@royale.apache.org
> > > > > > > Subject: Re: About the cumbersome random compilation issue
> > > > > > >
> > > > > > > BTW, is this in js-debug or js-release?
> > > > > > >
> > > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui"
> > > > > > > <ah...@adobe.com.INVALID>
> > > 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" <
> > carlosrovira@apache.org>
> > > > > > 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
Re: About the cumbersome random compilation issue
Posted by Carlos Rovira <ca...@apache.org>.
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 (<gr...@gmail.com>)
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 <ca...@apache.org>
> 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 (<
> > christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
> > > Gesendet: Mittwoch, 20. Mai 2020 17:48
> > > An: Apache Royale Development <de...@royale.apache.org>
> > > 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 (<gr...@gmail.com>)
> > > 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 <
> carlosrovira@apache.org
> > >
> > > > 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 (<greg.dove@gmail.com
> >)
> > > > > 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 <
> > > brian.raymes@teotech.com
> > > > >
> > > > > > 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._bindings
> > > > =
> > > > > [
> > > > > > > //
> > > > > > > // 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 <ah...@adobe.com.INVALID>
> > > > > > > Sent: Sunday, May 17, 2020 8:26 AM
> > > > > > > To: dev@royale.apache.org
> > > > > > > Subject: Re: About the cumbersome random compilation issue
> > > > > > >
> > > > > > > BTW, is this in js-debug or js-release?
> > > > > > >
> > > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui" <ah...@adobe.com.INVALID>
> > > 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" <
> > carlosrovira@apache.org>
> > > > > > 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%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
Re: About the cumbersome random compilation issue
Posted by Greg Dove <gr...@gmail.com>.
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 <ca...@apache.org>
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 (<
> christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
> > Gesendet: Mittwoch, 20. Mai 2020 17:48
> > An: Apache Royale Development <de...@royale.apache.org>
> > 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 (<gr...@gmail.com>)
> > 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 <carlosrovira@apache.org
> >
> > > 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 (<gr...@gmail.com>)
> > > > 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 <
> > brian.raymes@teotech.com
> > > >
> > > > > 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._bindings
> > > =
> > > > [
> > > > > > //
> > > > > > // 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 <ah...@adobe.com.INVALID>
> > > > > > Sent: Sunday, May 17, 2020 8:26 AM
> > > > > > To: dev@royale.apache.org
> > > > > > Subject: Re: About the cumbersome random compilation issue
> > > > > >
> > > > > > BTW, is this in js-debug or js-release?
> > > > > >
> > > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui" <ah...@adobe.com.INVALID>
> > 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" <
> carlosrovira@apache.org>
> > > > > 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: About the cumbersome random compilation issue
Posted by Carlos Rovira <ca...@apache.org>.
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 (<
christofer.dutz@c-ware.de>) 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 <ca...@apache.org>
> Gesendet: Mittwoch, 20. Mai 2020 17:48
> An: Apache Royale Development <de...@royale.apache.org>
> 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 (<gr...@gmail.com>)
> 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 <ca...@apache.org>
> > 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 (<gr...@gmail.com>)
> > > 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 <
> brian.raymes@teotech.com
> > >
> > > > 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._bindings
> > =
> > > [
> > > > > //
> > > > > // 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 <ah...@adobe.com.INVALID>
> > > > > Sent: Sunday, May 17, 2020 8:26 AM
> > > > > To: dev@royale.apache.org
> > > > > Subject: Re: About the cumbersome random compilation issue
> > > > >
> > > > > BTW, is this in js-debug or js-release?
> > > > >
> > > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui" <ah...@adobe.com.INVALID>
> 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" <ca...@apache.org>
> > > > 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: About the cumbersome random compilation issue
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ca...@apache.org>
Gesendet: Mittwoch, 20. Mai 2020 17:48
An: Apache Royale Development <de...@royale.apache.org>
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 (<gr...@gmail.com>)
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 <ca...@apache.org>
> 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 (<gr...@gmail.com>)
> > 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 <brian.raymes@teotech.com
> >
> > > 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._bindings
> =
> > [
> > > > //
> > > > // 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 <ah...@adobe.com.INVALID>
> > > > Sent: Sunday, May 17, 2020 8:26 AM
> > > > To: dev@royale.apache.org
> > > > Subject: Re: About the cumbersome random compilation issue
> > > >
> > > > BTW, is this in js-debug or js-release?
> > > >
> > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui" <ah...@adobe.com.INVALID> 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" <ca...@apache.org>
> > > 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: About the cumbersome random compilation issue
Posted by Carlos Rovira <ca...@apache.org>.
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 (<gr...@gmail.com>)
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 <ca...@apache.org>
> 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 (<gr...@gmail.com>)
> > 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 <brian.raymes@teotech.com
> >
> > > 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._bindings
> =
> > [
> > > > //
> > > > // 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 <ah...@adobe.com.INVALID>
> > > > Sent: Sunday, May 17, 2020 8:26 AM
> > > > To: dev@royale.apache.org
> > > > Subject: Re: About the cumbersome random compilation issue
> > > >
> > > > BTW, is this in js-debug or js-release?
> > > >
> > > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui" <ah...@adobe.com.INVALID> 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" <ca...@apache.org>
> > > 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: About the cumbersome random compilation issue
Posted by Greg Dove <gr...@gmail.com>.
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 <ca...@apache.org>
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 (<gr...@gmail.com>)
> 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 <br...@teotech.com>
> > 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._bindings =
> [
> > > //
> > > // 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 <ah...@adobe.com.INVALID>
> > > Sent: Sunday, May 17, 2020 8:26 AM
> > > To: dev@royale.apache.org
> > > Subject: Re: About the cumbersome random compilation issue
> > >
> > > BTW, is this in js-debug or js-release?
> > >
> > > 锘縊n 5/17/20, 8:20 AM, "Alex Harui" <ah...@adobe.com.INVALID> 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" <ca...@apache.org>
> > 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0
> > >
> > >
> > >
> > >
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: About the cumbersome random compilation issue
Posted by Carlos Rovira <ca...@apache.org>.
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 (<gr...@gmail.com>)
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 <br...@teotech.com>
> 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._bindings = [
> > //
> > // 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 <ah...@adobe.com.INVALID>
> > Sent: Sunday, May 17, 2020 8:26 AM
> > To: dev@royale.apache.org
> > Subject: Re: About the cumbersome random compilation issue
> >
> > BTW, is this in js-debug or js-release?
> >
> > 锘縊n 5/17/20, 8:20 AM, "Alex Harui" <ah...@adobe.com.INVALID> 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" <ca...@apache.org>
> 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0
> >
> >
> >
> >
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: About the cumbersome random compilation issue
Posted by Greg Dove <gr...@gmail.com>.
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 <br...@teotech.com>
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._bindings = [
> //
> // 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 <ah...@adobe.com.INVALID>
> Sent: Sunday, May 17, 2020 8:26 AM
> To: dev@royale.apache.org
> Subject: Re: About the cumbersome random compilation issue
>
> BTW, is this in js-debug or js-release?
>
> 锘縊n 5/17/20, 8:20 AM, "Alex Harui" <ah...@adobe.com.INVALID> 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" <ca...@apache.org> 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0
>
>
>
>
>
RE: About the cumbersome random compilation issue
Posted by Brian Raymes <br...@teotech.com>.
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._bindings = [
//
// 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 <ah...@adobe.com.INVALID>
Sent: Sunday, May 17, 2020 8:26 AM
To: dev@royale.apache.org
Subject: Re: About the cumbersome random compilation issue
BTW, is this in js-debug or js-release?
锘縊n 5/17/20, 8:20 AM, "Alex Harui" <ah...@adobe.com.INVALID> 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" <ca...@apache.org> 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0
Re: About the cumbersome random compilation issue
Posted by Alex Harui <ah...@adobe.com.INVALID>.
BTW, is this in js-debug or js-release?
锘縊n 5/17/20, 8:20 AM, "Alex Harui" <ah...@adobe.com.INVALID> 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" <ca...@apache.org> 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%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0
Re: About the cumbersome random compilation issue
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Save a good build. When you think you have a bad build, compare the output.
锘縊n 5/17/20, 3:46 AM, "Carlos Rovira" <ca...@apache.org> 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%7Cfcc61b7da78048769a4408d7fa4f98d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253092086147057&sdata=j9ArDJsHt8z3aBcNs62KmXClAqPUnBsCq3VJJ%2BSZs9o%3D&reserved=0