Re: Royale compiler remove labels and/or icons randomly (was Re: Control over export/rename: Finally giving up)

[Josh Tynjala]

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 


On Thu, Apr 2, 2020 at 4:47 PM Carlos Rovira 
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 
> > > 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 (<
> > >> joshtynj...@bowlerhat.dev>)
> > >> 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 
> > >> >
> > >> >
> >
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Royale compiler remove labels and/or icons randomly (was Re: Control over export/rename: Finally giving up)

[Carlos Rovira]

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 
> > 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 (<
> >> joshtynj...@bowlerhat.dev>)
> >> 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 
> >> >
> >> >
>
-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Control over export/rename: Finally giving up

[Greg Dove]

' fix coming hopefully in the next few hours ' <- by which I mean I have
already done it, and it works, just working through some other things.


On Thu, Apr 2, 2020 at 9:42 PM Greg Dove  wrote:

>
> FWIW, I have a somewhat related fix coming hopefully in the next few hours
> for an issue with complex static initializers of consts or vars. The issue
> is that while the declarations are working better with the getter/setters
> at startup, the access to the var or const from other code was broken.
>
> It needed an empty declaration against the class with the original
> approach (without initializers, so only really as clues for GCC) against
> the class - without that, the @lends directive in the
> Object.defineProperties declaration for the getter/setter approach was not
> working because it seems GCC needs the original empty definition of the
> static field to 'match' to with the @lends directive.
>
>
>
>
> On Thu, Apr 2, 2020 at 9:23 PM Carlos Rovira 
> 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 (<
>> joshtynj...@bowlerhat.dev>)
>> 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 
>> >
>> >
>> > On Mon, Mar 30, 2020 at 10:48 AM Josh Tynjala <
>> joshtynj...@bowlerhat.dev>
>> > wrote:
>> >
>> > > I did a quick test, and I can confirm that a public variable will not
>> be
>> > > renamed if a public getter with the same name exists on a different
>> > class.
>> > >
>> > > --
>> > > Josh Tynjala
>> > > Bowler Hat LLC 
>> > >
>> > >
>> > > On Thu, Mar 26, 2020 at 1:03 PM Josh Tynjala <
>> joshtynj...@bowlerhat.dev>
>> > > wrote:
>> > >
>> > >> Thanks for the info about Object.defineProperties(). That could be a
>> way
>> > >> to provide a workaround that doesn't mess too much with other stuff.
>> > >>
>> > >> --
>> > >> Josh Tynjala
>> > >> Bowler Hat LLC 
>> > >>
>> > >>
>> > >> On Thu, Mar 26, 2020 at 12:45 PM Alex Harui > >
>> > >> wrote:
>> > >>
>> > >>>
>> > >>>
>> > >>> On 3/26/20, 12:23 PM, "Josh Tynjala" 
>> > wrote:
>> > >>>
>> > >>> We can walk the AST if we have the source code. However, if an
>> MXML
>> > >>> class
>> > >>> gets compiled into a SWC, I don't think there's a way to figure
>> out
>> > >>> which
>> > >>> properties are being set in MXML from the definitions alone.
>> When I
>> > >>> was
>> > >>> investigating some things, I tried the AST walk until I realized
>> > >>> that it
>> > >>> only worked in my app project, and not with the classes that I
>> was
>> > >>> using
>> > >>> from framework SWCs.
>> > >>>
>> > >>> One possibility is that the compiler scans every JS file and looks
>> for
>> > >>> the MXMLDescriptor and scans it for strings.  Also have to look for
>> the
>> > >>> properties array as well.
>> > >>>
>> > >>> I might actually end up looking at 

Re: Control over export/rename: Finally giving up

[Greg Dove]

FWIW, I have a somewhat related fix coming hopefully in the next few hours
for an issue with complex static initializers of consts or vars. The issue
is that while the declarations are working better with the getter/setters
at startup, the access to the var or const from other code was broken.

It needed an empty declaration against the class with the original approach
(without initializers, so only really as clues for GCC) against the class -
without that, the @lends directive in the Object.defineProperties
declaration for the getter/setter approach was not working because it seems
GCC needs the original empty definition of the static field to 'match' to
with the @lends directive.




On Thu, Apr 2, 2020 at 9:23 PM Carlos Rovira 
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 ( >)
> 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 
> >
> >
> > On Mon, Mar 30, 2020 at 10:48 AM Josh Tynjala  >
> > wrote:
> >
> > > I did a quick test, and I can confirm that a public variable will not
> be
> > > renamed if a public getter with the same name exists on a different
> > class.
> > >
> > > --
> > > Josh Tynjala
> > > Bowler Hat LLC 
> > >
> > >
> > > On Thu, Mar 26, 2020 at 1:03 PM Josh Tynjala <
> joshtynj...@bowlerhat.dev>
> > > wrote:
> > >
> > >> Thanks for the info about Object.defineProperties(). That could be a
> way
> > >> to provide a workaround that doesn't mess too much with other stuff.
> > >>
> > >> --
> > >> Josh Tynjala
> > >> Bowler Hat LLC 
> > >>
> > >>
> > >> On Thu, Mar 26, 2020 at 12:45 PM Alex Harui  >
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>> On 3/26/20, 12:23 PM, "Josh Tynjala" 
> > wrote:
> > >>>
> > >>> We can walk the AST if we have the source code. However, if an
> MXML
> > >>> class
> > >>> gets compiled into a SWC, I don't think there's a way to figure
> out
> > >>> which
> > >>> properties are being set in MXML from the definitions alone.
> When I
> > >>> was
> > >>> investigating some things, I tried the AST walk until I realized
> > >>> that it
> > >>> only worked in my app project, and not with the classes that I
> was
> > >>> using
> > >>> from framework SWCs.
> > >>>
> > >>> One possibility is that the compiler scans every JS file and looks
> for
> > >>> the MXMLDescriptor and scans it for strings.  Also have to look for
> the
> > >>> properties array as well.
> > >>>
> > >>> I might actually end up looking at adding an option to convert
> > >>> public vars
> > >>> into getters/setters first. Should be easier than some of the
> > >>> alternatives,
> > >>> which I can dig into more later.
> > >>>
> > >>> FWIW, AFAICT, any Object.defineProperties structure blocks renaming
> > >>> through the entire compilation, not just within the file being
> > visited.  In
> > >>> fact, I'm not even sure it has to be 

Re: Control over export/rename: Finally giving up

[Carlos Rovira]

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 ()
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 
>
>
> On Mon, Mar 30, 2020 at 10:48 AM Josh Tynjala 
> wrote:
>
> > I did a quick test, and I can confirm that a public variable will not be
> > renamed if a public getter with the same name exists on a different
> class.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC 
> >
> >
> > On Thu, Mar 26, 2020 at 1:03 PM Josh Tynjala 
> > wrote:
> >
> >> Thanks for the info about Object.defineProperties(). That could be a way
> >> to provide a workaround that doesn't mess too much with other stuff.
> >>
> >> --
> >> Josh Tynjala
> >> Bowler Hat LLC 
> >>
> >>
> >> On Thu, Mar 26, 2020 at 12:45 PM Alex Harui 
> >> wrote:
> >>
> >>>
> >>>
> >>> On 3/26/20, 12:23 PM, "Josh Tynjala" 
> wrote:
> >>>
> >>> We can walk the AST if we have the source code. However, if an MXML
> >>> class
> >>> gets compiled into a SWC, I don't think there's a way to figure out
> >>> which
> >>> properties are being set in MXML from the definitions alone. When I
> >>> was
> >>> investigating some things, I tried the AST walk until I realized
> >>> that it
> >>> only worked in my app project, and not with the classes that I was
> >>> using
> >>> from framework SWCs.
> >>>
> >>> One possibility is that the compiler scans every JS file and looks for
> >>> the MXMLDescriptor and scans it for strings.  Also have to look for the
> >>> properties array as well.
> >>>
> >>> I might actually end up looking at adding an option to convert
> >>> public vars
> >>> into getters/setters first. Should be easier than some of the
> >>> alternatives,
> >>> which I can dig into more later.
> >>>
> >>> FWIW, AFAICT, any Object.defineProperties structure blocks renaming
> >>> through the entire compilation, not just within the file being
> visited.  In
> >>> fact, I'm not even sure it has to be Object.defineProperties.  It looks
> >>> like there is some criteria for being a global structure.  So to me, it
> >>> looks like you can prevent a rename, not only by swapping in a
> legitimate
> >>> getter/setter for the public var, but also by having some global
> structure,
> >>> possibly in an Object.defineProperties attached to the app that
> defines a
> >>> bunch of empty properties on some never-to-be-used object and then
> Closure
> >>> will not rename those properties on other objects.
> >>>
> >>> Of course, I could be wrong, but that's what I think I've seen.  I
> think
> >>> I saw that including some class with a getter/setter would cause
> properties
> >>> in other classes that use the same property name to not be renamed.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>>
> >>>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Control over export/rename: Finally giving up

[Josh Tynjala]

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 


On Mon, Mar 30, 2020 at 10:48 AM Josh Tynjala 
wrote:

> I did a quick test, and I can confirm that a public variable will not be
> renamed if a public getter with the same name exists on a different class.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Thu, Mar 26, 2020 at 1:03 PM Josh Tynjala 
> wrote:
>
>> Thanks for the info about Object.defineProperties(). That could be a way
>> to provide a workaround that doesn't mess too much with other stuff.
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC 
>>
>>
>> On Thu, Mar 26, 2020 at 12:45 PM Alex Harui 
>> wrote:
>>
>>>
>>>
>>> On 3/26/20, 12:23 PM, "Josh Tynjala"  wrote:
>>>
>>> We can walk the AST if we have the source code. However, if an MXML
>>> class
>>> gets compiled into a SWC, I don't think there's a way to figure out
>>> which
>>> properties are being set in MXML from the definitions alone. When I
>>> was
>>> investigating some things, I tried the AST walk until I realized
>>> that it
>>> only worked in my app project, and not with the classes that I was
>>> using
>>> from framework SWCs.
>>>
>>> One possibility is that the compiler scans every JS file and looks for
>>> the MXMLDescriptor and scans it for strings.  Also have to look for the
>>> properties array as well.
>>>
>>> I might actually end up looking at adding an option to convert
>>> public vars
>>> into getters/setters first. Should be easier than some of the
>>> alternatives,
>>> which I can dig into more later.
>>>
>>> FWIW, AFAICT, any Object.defineProperties structure blocks renaming
>>> through the entire compilation, not just within the file being visited.  In
>>> fact, I'm not even sure it has to be Object.defineProperties.  It looks
>>> like there is some criteria for being a global structure.  So to me, it
>>> looks like you can prevent a rename, not only by swapping in a legitimate
>>> getter/setter for the public var, but also by having some global structure,
>>> possibly in an Object.defineProperties attached to the app that defines a
>>> bunch of empty properties on some never-to-be-used object and then Closure
>>> will not rename those properties on other objects.
>>>
>>> Of course, I could be wrong, but that's what I think I've seen.  I think
>>> I saw that including some class with a getter/setter would cause properties
>>> in other classes that use the same property name to not be renamed.
>>>
>>> HTH,
>>> -Alex
>>>
>>>
>>>

Re: Control over export/rename: Finally giving up

[Josh Tynjala]

I did a quick test, and I can confirm that a public variable will not be
renamed if a public getter with the same name exists on a different class.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 1:03 PM Josh Tynjala 
wrote:

> Thanks for the info about Object.defineProperties(). That could be a way
> to provide a workaround that doesn't mess too much with other stuff.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Thu, Mar 26, 2020 at 12:45 PM Alex Harui 
> wrote:
>
>>
>>
>> On 3/26/20, 12:23 PM, "Josh Tynjala"  wrote:
>>
>> We can walk the AST if we have the source code. However, if an MXML
>> class
>> gets compiled into a SWC, I don't think there's a way to figure out
>> which
>> properties are being set in MXML from the definitions alone. When I
>> was
>> investigating some things, I tried the AST walk until I realized that
>> it
>> only worked in my app project, and not with the classes that I was
>> using
>> from framework SWCs.
>>
>> One possibility is that the compiler scans every JS file and looks for
>> the MXMLDescriptor and scans it for strings.  Also have to look for the
>> properties array as well.
>>
>> I might actually end up looking at adding an option to convert public
>> vars
>> into getters/setters first. Should be easier than some of the
>> alternatives,
>> which I can dig into more later.
>>
>> FWIW, AFAICT, any Object.defineProperties structure blocks renaming
>> through the entire compilation, not just within the file being visited.  In
>> fact, I'm not even sure it has to be Object.defineProperties.  It looks
>> like there is some criteria for being a global structure.  So to me, it
>> looks like you can prevent a rename, not only by swapping in a legitimate
>> getter/setter for the public var, but also by having some global structure,
>> possibly in an Object.defineProperties attached to the app that defines a
>> bunch of empty properties on some never-to-be-used object and then Closure
>> will not rename those properties on other objects.
>>
>> Of course, I could be wrong, but that's what I think I've seen.  I think
>> I saw that including some class with a getter/setter would cause properties
>> in other classes that use the same property name to not be renamed.
>>
>> HTH,
>> -Alex
>>
>>
>>

Re: Control over export/rename: Finally giving up

[Josh Tynjala]

Thanks for the info about Object.defineProperties(). That could be a way to
provide a workaround that doesn't mess too much with other stuff.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 12:45 PM Alex Harui 
wrote:

>
>
> On 3/26/20, 12:23 PM, "Josh Tynjala"  wrote:
>
> We can walk the AST if we have the source code. However, if an MXML
> class
> gets compiled into a SWC, I don't think there's a way to figure out
> which
> properties are being set in MXML from the definitions alone. When I was
> investigating some things, I tried the AST walk until I realized that
> it
> only worked in my app project, and not with the classes that I was
> using
> from framework SWCs.
>
> One possibility is that the compiler scans every JS file and looks for the
> MXMLDescriptor and scans it for strings.  Also have to look for the
> properties array as well.
>
> I might actually end up looking at adding an option to convert public
> vars
> into getters/setters first. Should be easier than some of the
> alternatives,
> which I can dig into more later.
>
> FWIW, AFAICT, any Object.defineProperties structure blocks renaming
> through the entire compilation, not just within the file being visited.  In
> fact, I'm not even sure it has to be Object.defineProperties.  It looks
> like there is some criteria for being a global structure.  So to me, it
> looks like you can prevent a rename, not only by swapping in a legitimate
> getter/setter for the public var, but also by having some global structure,
> possibly in an Object.defineProperties attached to the app that defines a
> bunch of empty properties on some never-to-be-used object and then Closure
> will not rename those properties on other objects.
>
> Of course, I could be wrong, but that's what I think I've seen.  I think I
> saw that including some class with a getter/setter would cause properties
> in other classes that use the same property name to not be renamed.
>
> HTH,
> -Alex
>
>
>

Re: Control over export/rename: Finally giving up

[Alex Harui]

On 3/26/20, 12:23 PM, "Josh Tynjala"  wrote:

We can walk the AST if we have the source code. However, if an MXML class
gets compiled into a SWC, I don't think there's a way to figure out which
properties are being set in MXML from the definitions alone. When I was
investigating some things, I tried the AST walk until I realized that it
only worked in my app project, and not with the classes that I was using
from framework SWCs.

One possibility is that the compiler scans every JS file and looks for the 
MXMLDescriptor and scans it for strings.  Also have to look for the properties 
array as well.

I might actually end up looking at adding an option to convert public vars
into getters/setters first. Should be easier than some of the alternatives,
which I can dig into more later.

FWIW, AFAICT, any Object.defineProperties structure blocks renaming through the 
entire compilation, not just within the file being visited.  In fact, I'm not 
even sure it has to be Object.defineProperties.  It looks like there is some 
criteria for being a global structure.  So to me, it looks like you can prevent 
a rename, not only by swapping in a legitimate getter/setter for the public 
var, but also by having some global structure, possibly in an 
Object.defineProperties attached to the app that defines a bunch of empty 
properties on some never-to-be-used object and then Closure will not rename 
those properties on other objects.

Of course, I could be wrong, but that's what I think I've seen.  I think I saw 
that including some class with a getter/setter would cause properties in other 
classes that use the same property name to not be renamed.

HTH,
-Alex

Re: Control over export/rename: Finally giving up

[Josh Tynjala]

We can walk the AST if we have the source code. However, if an MXML class
gets compiled into a SWC, I don't think there's a way to figure out which
properties are being set in MXML from the definitions alone. When I was
investigating some things, I tried the AST walk until I realized that it
only worked in my app project, and not with the classes that I was using
from framework SWCs.

I might actually end up looking at adding an option to convert public vars
into getters/setters first. Should be easier than some of the alternatives,
which I can dig into more later.

I like your idea of a swappable MXMLDataInterpreter. Something for me to
consider.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 11:58 AM Alex Harui 
wrote:

>
>
> On 3/26/20, 11:14 AM, "Josh Tynjala"  wrote:
>
> Snip...
>
> I'm currently looking into a way to include a function with the MXML
> descriptor that can be used to set the property, even if it has been
> renamed. An evolution of what I proposed a couple of months ago.
> However, I
> plan to keep both the string name and the value inside the descriptor
> so
> that it does not affect your debugging approach.
>
> A single property in the MXML descriptor looks like this now:
>
> [
> "someProperty",
> true,
> 123.4
> ]
>
> It might look something like this after my change:
>
> [
> "someProperty",
> function(value) { this.someProperty = value; },
> true,
> 123.4
> ]
>
> If the function exists, it will be called like this (where host is the
> component/object being created):
>
> var func = descriptor[i];
> func.call(host, value);
>
> This will ensure that someProperty can be renamed, and all of the
> original
> data is preserved for debugging.
>
> I should be able to make the compiler smart enough to only include the
> function where necessary (public vars) and omit it when not necessary
> (public setters) to save on file size and make it PAYG. I would, of
> course,
> also add a compiler option to include no functions in the descriptor
> (in
> other words, keep the existing behavior).
>
> Please consider the PAYG aspects of this approach.  Without thinking about
> it too much, it will at minimum make the MXMLDataInterpreter have to think
> harder whether you use that capability or not.
>
> It might be that we need to make sure there is an easy way to replace
> which MXMLDataIntepreter gets used so that more sophisticated logic can be
> plugged in if the app developer asks for it.  And if we can do that, then
> it might just be easier to have a test to see if the property exists before
> setting it and if it doesn't check some sort of rename map.
>
> Or, can we know which classes are having properties set via MXML and swap
> out public vars for getter/setters?
>
> HTH,
> -Alex
>
>

Re: Control over export/rename: Finally giving up

[Alex Harui]

On 3/26/20, 11:14 AM, "Josh Tynjala"  wrote:

Snip...

I'm currently looking into a way to include a function with the MXML
descriptor that can be used to set the property, even if it has been
renamed. An evolution of what I proposed a couple of months ago. However, I
plan to keep both the string name and the value inside the descriptor so
that it does not affect your debugging approach.

A single property in the MXML descriptor looks like this now:

[
"someProperty",
true,
123.4
]

It might look something like this after my change:

[
"someProperty",
function(value) { this.someProperty = value; },
true,
123.4
]

If the function exists, it will be called like this (where host is the
component/object being created):

var func = descriptor[i];
func.call(host, value);

This will ensure that someProperty can be renamed, and all of the original
data is preserved for debugging.

I should be able to make the compiler smart enough to only include the
function where necessary (public vars) and omit it when not necessary
(public setters) to save on file size and make it PAYG. I would, of course,
also add a compiler option to include no functions in the descriptor (in
other words, keep the existing behavior).

Please consider the PAYG aspects of this approach.  Without thinking about it 
too much, it will at minimum make the MXMLDataInterpreter have to think harder 
whether you use that capability or not.

It might be that we need to make sure there is an easy way to replace which 
MXMLDataIntepreter gets used so that more sophisticated logic can be plugged in 
if the app developer asks for it.  And if we can do that, then it might just be 
easier to have a test to see if the property exists before setting it and if it 
doesn't check some sort of rename map.

Or, can we know which classes are having properties set via MXML and swap out 
public vars for getter/setters?

HTH,
-Alex 

Re: Control over export/rename: Finally giving up

[Josh Tynjala]

> I would like to know what got rolled back.  IOW, what is the status now?
Is the compiler back to where it was maybe two years ago where we warn on
public vars, but the output is not made more verbose?  Or what?

I'm not sure what "two years ago" refers to exactly. All of the commits
that I rolled back were from this year, 2020.

But to answer what I rolled back, yes, it will warn on public vars again,
and the names of properties in the MXML descriptor are back to simple
strings. No more use of goog.reflect.objectProperty() because I realized
that it would only work in some situations.

I'm currently looking into a way to include a function with the MXML
descriptor that can be used to set the property, even if it has been
renamed. An evolution of what I proposed a couple of months ago. However, I
plan to keep both the string name and the value inside the descriptor so
that it does not affect your debugging approach.

A single property in the MXML descriptor looks like this now:

[
"someProperty",
true,
123.4
]

It might look something like this after my change:

[
"someProperty",
function(value) { this.someProperty = value; },
true,
123.4
]

If the function exists, it will be called like this (where host is the
component/object being created):

var func = descriptor[i];
func.call(host, value);

This will ensure that someProperty can be renamed, and all of the original
data is preserved for debugging.

I should be able to make the compiler smart enough to only include the
function where necessary (public vars) and omit it when not necessary
(public setters) to save on file size and make it PAYG. I would, of course,
also add a compiler option to include no functions in the descriptor (in
other words, keep the existing behavior).

> Also note that module support currently allows renaming, although Josh's
original post got me wondering if I missed something along the way.  Google
Closure was taking a rename map and seemed to be using it.

I mentioned this in my original post. Closure's ability to use these rename
maps is intended specifically for compiling multiple projects together,
exactly how we are using it for modules. There are comments in the code
that explicitly say that the rename map should not be used as a way to
prevent things from being renamed, and that the rename maps are considered
by Closure to be suggestions only, and they may be ignored in some cases.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 10:47 AM Alex Harui 
wrote:

> I'm also sorry to hear.  I did not pay much attention to this effort,
> other than complaining that we should not make our debug output hard to
> work with in order to support such an effort, because it really did make
> the kind of debugging I do much more painful.
>
> I would like to know what got rolled back.  IOW, what is the status now?
> Is the compiler back to where it was maybe two years ago where we warn on
> public vars, but the output is not made more verbose?  Or what?
>
> We might be able to enumerate where the framework relies on dynamic
> access, but it will be much harder, without control-flow analysis, to know
> where the application code relies on dynamic access.
>
> Without thinking about it too much, I would think we can define some
> scenarios, represent those scenarios as compiler options, and make more
> people happy.  But it could be a lot of work and I don't have the cycles
> for it.
>
> Some examples of a scenarios that could be output options:
> 1) I am not using binding or any other dynamic access in my app.  Remove
> all exports and I'll debug the resuls and add directives to fix the few
> things that need fixing
> 2) I am not using modules, so don't worry about any other compilation
> accessing my APIs
> 3) I am using modules, and here are the classes that are referenced by the
> modules
>
> There is also another dimension of ways to prevent renaming:
> A) Please convert all public vars to getter/setter
> B) Please convert all public var access to dynamic access
> C) Please inject anti-renaming stubs for all dynamic access
>
> Also note that module support currently allows renaming, although Josh's
> original post got me wondering if I missed something along the way.  Google
> Closure was taking a rename map and seemed to be using it.
>
> HTH,
> -Alex
>
> On 3/26/20, 1:23 AM, "Harbs"  wrote:
>
> Sorry to hear. :-(
>
> I still wonder if maybe we can document all the cases where we’re
> relying on not renaming and find a way to deal with those cases. (for
> someone who wants to disable exports)
>
> I know Greg has done a significant amount of digging related to his
> reflection work. Alex, do you have any thoughts?
>
> Harbs
>
> > On Mar 25, 2020, at 9:06 PM, Josh Tynjala 
> wrote:
> >
> > (With credit to Chris for the subject name )
> >
> > Some of you may know that over the last 2-3 months I've been looking
> into
> > ways to add more control over how the 

Re: Control over export/rename: Finally giving up

[Alex Harui]

I'm also sorry to hear.  I did not pay much attention to this effort, other 
than complaining that we should not make our debug output hard to work with in 
order to support such an effort, because it really did make the kind of 
debugging I do much more painful.

I would like to know what got rolled back.  IOW, what is the status now?  Is 
the compiler back to where it was maybe two years ago where we warn on public 
vars, but the output is not made more verbose?  Or what?

We might be able to enumerate where the framework relies on dynamic access, but 
it will be much harder, without control-flow analysis, to know where the 
application code relies on dynamic access.

Without thinking about it too much, I would think we can define some scenarios, 
represent those scenarios as compiler options, and make more people happy.  But 
it could be a lot of work and I don't have the cycles for it.

Some examples of a scenarios that could be output options:
1) I am not using binding or any other dynamic access in my app.  Remove all 
exports and I'll debug the resuls and add directives to fix the few things that 
need fixing
2) I am not using modules, so don't worry about any other compilation accessing 
my APIs
3) I am using modules, and here are the classes that are referenced by the 
modules

There is also another dimension of ways to prevent renaming:
A) Please convert all public vars to getter/setter
B) Please convert all public var access to dynamic access
C) Please inject anti-renaming stubs for all dynamic access

Also note that module support currently allows renaming, although Josh's 
original post got me wondering if I missed something along the way.  Google 
Closure was taking a rename map and seemed to be using it.

HTH,
-Alex

On 3/26/20, 1:23 AM, "Harbs"  wrote:

Sorry to hear. :-(

I still wonder if maybe we can document all the cases where we’re relying 
on not renaming and find a way to deal with those cases. (for someone who wants 
to disable exports)

I know Greg has done a significant amount of digging related to his 
reflection work. Alex, do you have any thoughts?

Harbs

> On Mar 25, 2020, at 9:06 PM, Josh Tynjala  
wrote:
> 
> (With credit to Chris for the subject name )
> 
> Some of you may know that over the last 2-3 months I've been looking into
> ways to add more control over how the compiler handles renaming and
> exporting APIs in the generated JS. Ideally, my work would have culminated
> in a variety of options that would allow release builds to be much 
smaller,
> if you were willing to sacrifice certain capabilities (things along the
> lines of dynamic access of properties and reflection). Obviously, you 
would
> have been able to keep things working the same as they do today, so my
> changes would have been opt-in.
> 
> I've determined that Closure does not actually expose the ability to
> prevent renaming of JS APIs, except by exporting them. The advanced
> compiler APIs that Closure exposes to prevent renaming are specifically
> intended for compiling multiple related projects together (like we're 
doing
> with modules). Additionally, I discovered that Closure does not guarantee
> that any custom rename mappings will be respected. In fact, the
> documentation says they may be completely ignored, and there is official
> guidance that says not to do what I was originally trying to do. I could
> not find any other Closure compiler APIs accessible in Java that could do
> what we want here, so I think that our original assumption that preventing
> renaming programmatically would be possible was incorrect.
> 
> In the case of disabling exports, I found that there are parts of the
> Royale framework that rely on the fact that properties are exported.
> Bindings and setting properties in MXML are the most visible. There are
> probably more that I didn't discover yet because the first two had such a
> big impact. Honestly, I am not experienced enough in the framework side of
> Royale to know that I won't break anything if I try to start making 
changes
> to ensure that all framework code can handle property renaming. Maybe
> disabling exports is still possible, but I don't think that I'm the one 
who
> can do it.
> 
> In the end, I was left feeling extremely frustrated with Closure compiler
> once again. It's not the first time, and it's unlikely to be the last. I
> wasted two whole months trying to follow its incredibly strict rule 
system.
> In the past, I have tried to fight Closure instead, so I thought that I 
was
> doing things right this time. I really wish I would have spent that time
> doing something else that would have benefitted Royale more.
> 
> Side note: As I was reverting the rename/export changes I had made to the
> compiler, I realized that there were some 

Re: Control over export/rename: Finally giving up

[Harbs]

Sorry to hear. :-(

I still wonder if maybe we can document all the cases where we’re relying on 
not renaming and find a way to deal with those cases. (for someone who wants to 
disable exports)

I know Greg has done a significant amount of digging related to his reflection 
work. Alex, do you have any thoughts?

Harbs

> On Mar 25, 2020, at 9:06 PM, Josh Tynjala  wrote:
> 
> (With credit to Chris for the subject name )
> 
> Some of you may know that over the last 2-3 months I've been looking into
> ways to add more control over how the compiler handles renaming and
> exporting APIs in the generated JS. Ideally, my work would have culminated
> in a variety of options that would allow release builds to be much smaller,
> if you were willing to sacrifice certain capabilities (things along the
> lines of dynamic access of properties and reflection). Obviously, you would
> have been able to keep things working the same as they do today, so my
> changes would have been opt-in.
> 
> I've determined that Closure does not actually expose the ability to
> prevent renaming of JS APIs, except by exporting them. The advanced
> compiler APIs that Closure exposes to prevent renaming are specifically
> intended for compiling multiple related projects together (like we're doing
> with modules). Additionally, I discovered that Closure does not guarantee
> that any custom rename mappings will be respected. In fact, the
> documentation says they may be completely ignored, and there is official
> guidance that says not to do what I was originally trying to do. I could
> not find any other Closure compiler APIs accessible in Java that could do
> what we want here, so I think that our original assumption that preventing
> renaming programmatically would be possible was incorrect.
> 
> In the case of disabling exports, I found that there are parts of the
> Royale framework that rely on the fact that properties are exported.
> Bindings and setting properties in MXML are the most visible. There are
> probably more that I didn't discover yet because the first two had such a
> big impact. Honestly, I am not experienced enough in the framework side of
> Royale to know that I won't break anything if I try to start making changes
> to ensure that all framework code can handle property renaming. Maybe
> disabling exports is still possible, but I don't think that I'm the one who
> can do it.
> 
> In the end, I was left feeling extremely frustrated with Closure compiler
> once again. It's not the first time, and it's unlikely to be the last. I
> wasted two whole months trying to follow its incredibly strict rule system.
> In the past, I have tried to fight Closure instead, so I thought that I was
> doing things right this time. I really wish I would have spent that time
> doing something else that would have benefitted Royale more.
> 
> Side note: As I was reverting the rename/export changes I had made to the
> compiler, I realized that there were some issues with my previous attempts
> to improve the situation with warn-public-vars. With that in mind, I
> reverted those changes too (for now). I plan to look into a better solution
> for warn-public-vars soon, but I can't guarantee that anything will work
> because it's another place where Closure compiler is the cause of the issue.
> 
> --
> Josh Tynjala
> Bowler Hat LLC