Ok Josh, thanks. When I read your explanation I matched directly with that compiler problem, it's a pity that not was related
Thanks El vie., 3 abr. 2020 a las 17:58, Josh Tynjala (<[email protected]>) escribió: > For the record, I'm pretty sure that the change that I made was something > completely different than what you were thinking it was. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev> > > > On Thu, Apr 2, 2020 at 4:47 PM Carlos Rovira <[email protected]> > wrote: > > > Hi > > > > I'm sorry to say that the Josh's fix I commented is not fixing the thing > I > > suggested. The problem of labels removed is still there as you can see in > > the following image (I had it today again): > > > > https://imgur.com/a/NEiUZXH > > > > The labels or icons that are removed change, so I think this could be > some > > thread problem since happens un one compilation from around other 15 or > > so... > > > > If someone could take a look at this, would be great, since I think is an > > important problem. > > I think we should detect what's happening if we can before 1.0 > > > > Thanks > > > > > > > > > > On Thu, Apr 2, 2020 at 9:23 PM Carlos Rovira < > [email protected]> > > > > wrote: > > > > > > > >> Hi Josh, > > > >> > > > >> many thanks for this report to see what changed: > > > >> > > > >> Although all is impressive, I think the second point is really > > > important, > > > >> if is what I think it's. > > > >> > > > >> From always, I had "false compilations" in TDJ (and other real apps) > > > that > > > >> make string labels in menus, list, and icons, be blank sometimes > and > > > >> randomly. I think is 1/20 compilations. So that change seems to fix > > that > > > >> if > > > >> I'm understanding correctly. > > > >> > > > >> I'll be watching that the following days to see if that's finally > > solved > > > >> or > > > >> I still can get a false compilation. > > > >> > > > >> If is solved, I think this change is key, since until now I think > an > > > user > > > >> getting that behaviour will think not so well about Royale > stability. > > > >> > > > >> Thanks!! :) > > > >> > > > >> Carlos > > > >> > > > >> > > > >> El mié., 1 abr. 2020 a las 21:04, Josh Tynjala (< > > > >> [email protected]>) > > > >> escribió: > > > >> > > > >> > Good news! I was able to expand on what Alex suggested to provide > a > > > >> > solution that prevents public variables from being renamed by > Google > > > >> > Closure in release builds. A few key points: > > > >> > > > > >> > - You can set public variables in MXML, and they will work > > > correctly > > > >> in > > > >> > release builds. Previously, only properties with setters worked > > in > > > >> > release > > > >> > builds. > > > >> > - I've also determined how to prevent Google Closure from > > creating > > > >> > multiple copies of static public variables, which caused some > > > values > > > >> > (numbers, boolean, strings) to get out of sync if changed at > > > runtime. > > > >> > This > > > >> > was a closely related issue. > > > >> > - I added prevent-rename-public-symbols and > > > >> > prevent-rename-protected-symbols compiler options. They are > true > > by > > > >> > default, but you can set them to false to go back to the old > > > behavior > > > >> > (which would include reporting a warning for public vars). > > > >> > - No changes were required to the MXMLDescriptor, so my changes > > > won't > > > >> > mess with debugging workflows that require inspecting that data > > > >> > structure > > > >> > at runtime. > > > >> > > > > >> > The process of implementing a better solution for this gave me > some > > > >> ideas > > > >> > related to adding more control over exports, so I plan to give > that > > > >> another > > > >> > try too. Thanks again to Alex for the suggestions that helped make > > > this > > > >> > happen. > > > >> > > > > >> > -- > > > >> > Josh Tynjala > > > >> > Bowler Hat LLC <https://bowlerhat.dev> > > > >> > > > > >> > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > -- Carlos Rovira http://about.me/carlosrovira
