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

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

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

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

Re: Control over export/rename: Finally giving up

' 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

Re: Control over export/rename: Finally giving up

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

Re: Control over export/rename: Finally giving up

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

Re: Control over export/rename: Finally giving up

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

Re: Control over export/rename: Finally giving up

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

Re: Control over export/rename: Finally giving up

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"

Re: Control over export/rename: Finally giving up

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

Re: Control over export/rename: Finally giving up

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

Re: Control over export/rename: Finally giving up

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

Re: Control over export/rename: Finally giving up

> 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

Re: Control over export/rename: Finally giving up

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

Re: Control over export/rename: Finally giving up

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