Re: Could @nocollapse be a solution to the -warn-public-vars issue?

2019-09-16 Thread Alex Harui
Some folks want us to get smarter and not automatically export all public 
methods and getter/setters.  There are a lot of just-in-case strings in Royale 
apps.  That's not good.  So better control over things even after compiling 
without being painful to use is the goal.

My 2 cents,
-Alex

On 9/16/19, 12:39 PM, "Josh Tynjala"  wrote:

I was thinking about this some more, and is there anything else that's
public that also we allow to be renamed? I'm not aware of anything, but
maybe I've missed something. If it's true, it seems inconsistent to allow
public variables to be the one exception that should be renamed. If public
methods, properties, and other things can't be renamed, public variables
shouldn't be either.

Looking into the configuration classes, I see that we have the
export-public-symbols compiler option. That seems like it's the one that is
meant to control whether public things should be renamed or not. It's true
by default. I have no issue with public variables being renamed when it's
false. Again, that would be consistent with how the compiler handles other
public things.

--
Josh Tynjala
Bowler Hat LLC 



On Mon, Sep 16, 2019 at 11:13 AM Josh Tynjala 
wrote:

> Unfortunately, people actively avoid using public vars because we warn
> about them. Our warnings are too aggressive if it doesn't actually matter
> most of the time. Plus, this warning leaves a bad impression because it's
> such a basic feature of the language that pretty much everyone uses.
>
> What can we do to provide a more sensible default behavior, while also
> giving someone the ability to tell the compiler that everything can be
> renamed (or selective renaming)?
>
> We could add an option that doesn't rename public things by default, but
> can also be toggled to rename everything. I guess we could have some
> @royalewhatever annotations to give someone selective control over which
> things are renamed or not, if someone needs that. Thoughts?
>
> --
> Josh Tynjala
> Bowler Hat LLC 

>
>
> On Mon, Sep 16, 2019 at 10:50 AM Alex Harui 
> wrote:
>
>> I'm not sure I understand your proposal.  Are you proposing that all
>> public variables will be quoted and thus not renamed so we never warn
>> again?  I am not in favor of that.  IMO, the vast majority of public vars
>> can be renamed without penalty.  It is only certain classes that will be
>> mapped to external code that matter.
>>
>> My 2 cents,
>> -Alex
>>
>> On 9/16/19, 10:46 AM, "Josh Tynjala"  wrote:
>>
>> You're right. After a number of tests, I cannot find any annotation
>> (or
>> combination of them) that will prevent the renaming of variables
>> defined on
>> a prototype. All of the official advice that I see from Google
>> suggests
>> quoting the properties (or using externs). So, from a Royale
>> perspective,
>> it looks like quoting the public variable's name is our best option.
>>
>> Similar to how we handle js-dynamic-access-unknown-members, we can
>> quote
>> the public variable's name when getting or setting it in JS:
>>
>> var foo = new Foo();
>> foo["bar"] = 2;
>> var baz = foo["bar"];
>>
>> In this case, we also need to quote the public variable's name when
>> declaring it on the prototype:
>>
>> Foo.prototype["bar"] = 3;
>>
>> I did some tests, and I can confirm that Closure will preserve the
>> public
>> variable's name, similar to how it preserves the names when we 
declare
>> public getters and setters. I'm going to make this change and turn 
off
>> warn-public-vars.
>>
>> (To be clear, I'm only going to change how the emitter handles public
>> variables specifically. Behavior for other types of property access
>> will
>> remain the same.)
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC <
>> 

Build failed in Jenkins: royale-asjs_MXTests #1160

2019-09-16 Thread Apache Royale CI Server
See 


--
[...truncated 1000.82 KB...]
[mxmlc] scanning for overrides: ObjectUtil
[mxmlc] scanning for overrides: SolidBorderUtil
[mxmlc] scanning for overrides: StringTrimmer
[mxmlc] scanning for overrides: StringUtil
[mxmlc] scanning for overrides: Timer
[mxmlc] scanning for overrides: UIUtils
[mxmlc] scanning for overrides: Effect
[mxmlc] scanning for overrides: Transition
[mxmlc] scanning for overrides: IFill
[mxmlc] scanning for overrides: SolidColor
[mxmlc] scanning for overrides: IExternalizable
[mxmlc] scanning for overrides: Proxy
[mxmlc] scanning for overrides: CursorBookmark
[mxmlc] scanning for overrides: ICollectionView
[mxmlc] scanning for overrides: IList
[mxmlc] scanning for overrides: IViewCursor
[mxmlc] scanning for overrides: ListCollectionView
[mxmlc] scanning for overrides: ListCollectionViewCursor
[mxmlc] scanning for overrides: ListCollectionViewBookmark
[mxmlc] scanning for overrides: ArrayCollection
[mxmlc] scanning for overrides: ArrayList
[mxmlc] scanning for overrides: XMLListCollection
[mxmlc] scanning for overrides: CanvasLayout
[mxmlc] scanning for overrides: Flex
[mxmlc] scanning for overrides: BoxDirection
[mxmlc] scanning for overrides: HBox
[mxmlc] scanning for overrides: PanelTitleBar
[mxmlc] scanning for overrides: DataGridColumn
[mxmlc] scanning for overrides: Button
[mxmlc] scanning for overrides: ISelectable
[mxmlc] scanning for overrides: CheckBox
[mxmlc] scanning for overrides: IFocusManagerComponent
[mxmlc] scanning for overrides: ComboBase
[mxmlc] scanning for overrides: ComboBox
[mxmlc] scanning for overrides: ScrollControlBase
[mxmlc] scanning for overrides: ListBase
[mxmlc] scanning for overrides: DataGrid
[mxmlc] scanning for overrides: DateField
[mxmlc] scanning for overrides: Label
[mxmlc] scanning for overrides: List
[mxmlc] scanning for overrides: MenuBar
[mxmlc] scanning for overrides: NumericStepper
[mxmlc] scanning for overrides: RadioButton
[mxmlc] scanning for overrides: RadioButtonGroup
[mxmlc] scanning for overrides: TextArea
[mxmlc] scanning for overrides: ITextInput
[mxmlc] scanning for overrides: TextInput
[mxmlc] scanning for overrides: ITextFieldFactory
[mxmlc] scanning for overrides: Singleton
[mxmlc] scanning for overrides: ItemClickEvent
[mxmlc] scanning for overrides: ListEvent
[mxmlc] scanning for overrides: MenuEvent
[mxmlc] scanning for overrides: MouseEvent
[mxmlc] scanning for overrides: PropertyChangeEventKind
[mxmlc] scanning for overrides: Matrix
[mxmlc] scanning for overrides: Matrix
[mxmlc] scanning for overrides: IFocusManagerComplexComponent
[mxmlc] scanning for overrides: IFocusManagerGroup
[mxmlc] scanning for overrides: IResourceBundle
[mxmlc] scanning for overrides: ResourceManagerImpl
[mxmlc] scanning for overrides: ResourceModuleInfo
[mxmlc] scanning for overrides: ResourceEventDispatcher
[mxmlc] scanning for overrides: ResourceBundleProxy
[mxmlc] scanning for overrides: GroupBase
[mxmlc] scanning for overrides: SkinnableComponent
[mxmlc] scanning for overrides: ButtonBase
[mxmlc] scanning for overrides: Button
[mxmlc] scanning for overrides: ErrorArray
[mxmlc] scanning for overrides: RunCodeEvent
[mxmlc] scanning for overrides: PasswordInputBead
[mxmlc] scanning for overrides: ITileLayout
[mxmlc] scanning for overrides: TileLayout
[mxmlc] scanning for overrides: LocaleUtils
[mxmlc] scanning for overrides: StringPadder
[mxmlc] scanning for overrides: UIDUtil
[mxmlc] scanning for overrides: IStroke
[mxmlc] scanning for overrides: CursorError
[mxmlc] scanning for overrides: SortError
[mxmlc] scanning for overrides: ISort
[mxmlc] scanning for overrides: Sort
[mxmlc] scanning for overrides: IXMLNotifiable
[mxmlc] scanning for overrides: XMLListAdapter
[mxmlc] scanning for overrides: FlexChildInfo
[mxmlc] scanning for overrides: BaseListData
[mxmlc] scanning for overrides: IFactory
[mxmlc] scanning for overrides: IUITextField
[mxmlc] scanning for overrides: UITextField
[mxmlc] scanning for overrides: CollectionEvent
[mxmlc] scanning for overrides: CollectionEventKind
[mxmlc] scanning for overrides: LocaleSorter
[mxmlc] scanning for overrides: LocaleID
[mxmlc] scanning for overrides: LocaleRegistry
[mxmlc] scanning for overrides: ResourceBundle
[mxmlc] scanning for overrides: ArrayUtil
[mxmlc] scanning for overrides: StringUtil
[mxmlc] scanning for overrides: UIDUtil
[mxmlc] scanning for overrides: DataGroup
[mxmlc] scanning for overrides: LayoutBase
[mxmlc] scanning for overrides: BasicLayout

Jenkins build is back to normal : royale-asjs_jsonly #3551

2019-09-16 Thread Apache Royale CI Server
See 




Re: Could @nocollapse be a solution to the -warn-public-vars issue?

2019-09-16 Thread Josh Tynjala
I was thinking about this some more, and is there anything else that's
public that also we allow to be renamed? I'm not aware of anything, but
maybe I've missed something. If it's true, it seems inconsistent to allow
public variables to be the one exception that should be renamed. If public
methods, properties, and other things can't be renamed, public variables
shouldn't be either.

Looking into the configuration classes, I see that we have the
export-public-symbols compiler option. That seems like it's the one that is
meant to control whether public things should be renamed or not. It's true
by default. I have no issue with public variables being renamed when it's
false. Again, that would be consistent with how the compiler handles other
public things.

--
Josh Tynjala
Bowler Hat LLC 


On Mon, Sep 16, 2019 at 11:13 AM Josh Tynjala 
wrote:

> Unfortunately, people actively avoid using public vars because we warn
> about them. Our warnings are too aggressive if it doesn't actually matter
> most of the time. Plus, this warning leaves a bad impression because it's
> such a basic feature of the language that pretty much everyone uses.
>
> What can we do to provide a more sensible default behavior, while also
> giving someone the ability to tell the compiler that everything can be
> renamed (or selective renaming)?
>
> We could add an option that doesn't rename public things by default, but
> can also be toggled to rename everything. I guess we could have some
> @royalewhatever annotations to give someone selective control over which
> things are renamed or not, if someone needs that. Thoughts?
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Mon, Sep 16, 2019 at 10:50 AM Alex Harui 
> wrote:
>
>> I'm not sure I understand your proposal.  Are you proposing that all
>> public variables will be quoted and thus not renamed so we never warn
>> again?  I am not in favor of that.  IMO, the vast majority of public vars
>> can be renamed without penalty.  It is only certain classes that will be
>> mapped to external code that matter.
>>
>> My 2 cents,
>> -Alex
>>
>> On 9/16/19, 10:46 AM, "Josh Tynjala"  wrote:
>>
>> You're right. After a number of tests, I cannot find any annotation
>> (or
>> combination of them) that will prevent the renaming of variables
>> defined on
>> a prototype. All of the official advice that I see from Google
>> suggests
>> quoting the properties (or using externs). So, from a Royale
>> perspective,
>> it looks like quoting the public variable's name is our best option.
>>
>> Similar to how we handle js-dynamic-access-unknown-members, we can
>> quote
>> the public variable's name when getting or setting it in JS:
>>
>> var foo = new Foo();
>> foo["bar"] = 2;
>> var baz = foo["bar"];
>>
>> In this case, we also need to quote the public variable's name when
>> declaring it on the prototype:
>>
>> Foo.prototype["bar"] = 3;
>>
>> I did some tests, and I can confirm that Closure will preserve the
>> public
>> variable's name, similar to how it preserves the names when we declare
>> public getters and setters. I'm going to make this change and turn off
>> warn-public-vars.
>>
>> (To be clear, I'm only going to change how the emitter handles public
>> variables specifically. Behavior for other types of property access
>> will
>> remain the same.)
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC <
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741705917sdata=oIgajcsJSzyrmkeIOX%2BcuPe9lVt7iukyGAhrLdlVmvY%3Dreserved=0
>> >
>>
>>
>> On Mon, Sep 16, 2019 at 10:06 AM Alex Harui > >
>> wrote:
>>
>> > Feel free to revisit.  IIRC, the issue is that you can't @export a
>> "var".
>> > You can only @export a function because @export sets up a reference
>> to the
>> > renamed function and you can't set up a reference to simple vars.
>> >
>> > Class Josh {
>> >   Static var foo:int = 1;
>> > }
>> >
>> > Compiles to:
>> >
>> >   Josh.foo = 1;
>> >
>> > Gets renamed to:
>> >
>> >   a.b = 1;
>> >
>> > The @export will result in:
>> >
>> >   ['Josh']['foo'] = a.b;
>> >
>> > And then code that does:
>> >
>> >   Josh.foo = 2;
>> >
>> > Will not change
>> >
>> >   Console.log(a.b); // 1 (not 2)
>> >
>> > Of course, I could be wrong..
>> >
>> > -Alex
>> >
>> > On 9/16/19, 9:57 AM, "Josh Tynjala" 
>> wrote:
>> >
>> > I guess I was assuming that @nocollapse combined with @export
>> would
>> > make it
>> > also prevent renaming. I suppose I can test it and see what
>> happens.
>> >
>> > --
>> > Josh Tynjala
>> > Bowler Hat LLC <
>> >
>> 

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

2019-09-16 Thread Josh Tynjala
Unfortunately, people actively avoid using public vars because we warn
about them. Our warnings are too aggressive if it doesn't actually matter
most of the time. Plus, this warning leaves a bad impression because it's
such a basic feature of the language that pretty much everyone uses.

What can we do to provide a more sensible default behavior, while also
giving someone the ability to tell the compiler that everything can be
renamed (or selective renaming)?

We could add an option that doesn't rename public things by default, but
can also be toggled to rename everything. I guess we could have some
@royalewhatever annotations to give someone selective control over which
things are renamed or not, if someone needs that. Thoughts?

--
Josh Tynjala
Bowler Hat LLC 


On Mon, Sep 16, 2019 at 10:50 AM Alex Harui 
wrote:

> I'm not sure I understand your proposal.  Are you proposing that all
> public variables will be quoted and thus not renamed so we never warn
> again?  I am not in favor of that.  IMO, the vast majority of public vars
> can be renamed without penalty.  It is only certain classes that will be
> mapped to external code that matter.
>
> My 2 cents,
> -Alex
>
> On 9/16/19, 10:46 AM, "Josh Tynjala"  wrote:
>
> You're right. After a number of tests, I cannot find any annotation (or
> combination of them) that will prevent the renaming of variables
> defined on
> a prototype. All of the official advice that I see from Google suggests
> quoting the properties (or using externs). So, from a Royale
> perspective,
> it looks like quoting the public variable's name is our best option.
>
> Similar to how we handle js-dynamic-access-unknown-members, we can
> quote
> the public variable's name when getting or setting it in JS:
>
> var foo = new Foo();
> foo["bar"] = 2;
> var baz = foo["bar"];
>
> In this case, we also need to quote the public variable's name when
> declaring it on the prototype:
>
> Foo.prototype["bar"] = 3;
>
> I did some tests, and I can confirm that Closure will preserve the
> public
> variable's name, similar to how it preserves the names when we declare
> public getters and setters. I'm going to make this change and turn off
> warn-public-vars.
>
> (To be clear, I'm only going to change how the emitter handles public
> variables specifically. Behavior for other types of property access
> will
> remain the same.)
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741705917sdata=oIgajcsJSzyrmkeIOX%2BcuPe9lVt7iukyGAhrLdlVmvY%3Dreserved=0
> >
>
>
> On Mon, Sep 16, 2019 at 10:06 AM Alex Harui 
> wrote:
>
> > Feel free to revisit.  IIRC, the issue is that you can't @export a
> "var".
> > You can only @export a function because @export sets up a reference
> to the
> > renamed function and you can't set up a reference to simple vars.
> >
> > Class Josh {
> >   Static var foo:int = 1;
> > }
> >
> > Compiles to:
> >
> >   Josh.foo = 1;
> >
> > Gets renamed to:
> >
> >   a.b = 1;
> >
> > The @export will result in:
> >
> >   ['Josh']['foo'] = a.b;
> >
> > And then code that does:
> >
> >   Josh.foo = 2;
> >
> > Will not change
> >
> >   Console.log(a.b); // 1 (not 2)
> >
> > Of course, I could be wrong..
> >
> > -Alex
> >
> > On 9/16/19, 9:57 AM, "Josh Tynjala" 
> wrote:
> >
> > I guess I was assuming that @nocollapse combined with @export
> would
> > make it
> > also prevent renaming. I suppose I can test it and see what
> happens.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741715916sdata=RzTt0oXl8VlOFQx61iqQmpTnZjzRQ83WA0nhC14VaBU%3Dreserved=0
> > >
> >
> >
> > On Mon, Sep 16, 2019 at 9:54 AM Alex Harui
> 
> > wrote:
> >
> > > IMO, the -warn-public-vars is more about the "renaming"
> mentioned in
> > that
> > > link than the "collapse".
> > >
> > > If you have:
> > >
> > > Package {
> > > Class Josh {
> > >   Public var name:String;
> > > }
> > > Var foo:Josh = new Josh();
> > > foo.name = 'josh';
> > >
> > > I don't think @nocollapse will prevent renaming the 'name'
> property
> > to
> > > something random like 'jt':
> > >
> > > Var foo = new Josh();
> > > foo.jt = 'josh';
> > >
> > > AIUI, @nocollapse 

Build failed in Jenkins: royale-asjs_MXTests #1159

2019-09-16 Thread Apache Royale CI Server
See 


--
[...truncated 1001.78 KB...]
[mxmlc] scanning for overrides: ObjectUtil
[mxmlc] scanning for overrides: SolidBorderUtil
[mxmlc] scanning for overrides: StringTrimmer
[mxmlc] scanning for overrides: StringUtil
[mxmlc] scanning for overrides: Timer
[mxmlc] scanning for overrides: UIUtils
[mxmlc] scanning for overrides: Effect
[mxmlc] scanning for overrides: Transition
[mxmlc] scanning for overrides: IFill
[mxmlc] scanning for overrides: SolidColor
[mxmlc] scanning for overrides: IExternalizable
[mxmlc] scanning for overrides: Proxy
[mxmlc] scanning for overrides: CursorBookmark
[mxmlc] scanning for overrides: ICollectionView
[mxmlc] scanning for overrides: IList
[mxmlc] scanning for overrides: IViewCursor
[mxmlc] scanning for overrides: ListCollectionView
[mxmlc] scanning for overrides: ListCollectionViewCursor
[mxmlc] scanning for overrides: ListCollectionViewBookmark
[mxmlc] scanning for overrides: ArrayCollection
[mxmlc] scanning for overrides: ArrayList
[mxmlc] scanning for overrides: XMLListCollection
[mxmlc] scanning for overrides: CanvasLayout
[mxmlc] scanning for overrides: Flex
[mxmlc] scanning for overrides: BoxDirection
[mxmlc] scanning for overrides: HBox
[mxmlc] scanning for overrides: PanelTitleBar
[mxmlc] scanning for overrides: DataGridColumn
[mxmlc] scanning for overrides: Button
[mxmlc] scanning for overrides: ISelectable
[mxmlc] scanning for overrides: CheckBox
[mxmlc] scanning for overrides: IFocusManagerComponent
[mxmlc] scanning for overrides: ComboBase
[mxmlc] scanning for overrides: ComboBox
[mxmlc] scanning for overrides: ScrollControlBase
[mxmlc] scanning for overrides: ListBase
[mxmlc] scanning for overrides: DataGrid
[mxmlc] scanning for overrides: DateField
[mxmlc] scanning for overrides: Label
[mxmlc] scanning for overrides: List
[mxmlc] scanning for overrides: MenuBar
[mxmlc] scanning for overrides: NumericStepper
[mxmlc] scanning for overrides: RadioButton
[mxmlc] scanning for overrides: RadioButtonGroup
[mxmlc] scanning for overrides: TextArea
[mxmlc] scanning for overrides: ITextInput
[mxmlc] scanning for overrides: TextInput
[mxmlc] scanning for overrides: ITextFieldFactory
[mxmlc] scanning for overrides: Singleton
[mxmlc] scanning for overrides: ItemClickEvent
[mxmlc] scanning for overrides: ListEvent
[mxmlc] scanning for overrides: MenuEvent
[mxmlc] scanning for overrides: MouseEvent
[mxmlc] scanning for overrides: PropertyChangeEventKind
[mxmlc] scanning for overrides: Matrix
[mxmlc] scanning for overrides: Matrix
[mxmlc] scanning for overrides: IFocusManagerComplexComponent
[mxmlc] scanning for overrides: IFocusManagerGroup
[mxmlc] scanning for overrides: IResourceBundle
[mxmlc] scanning for overrides: ResourceManagerImpl
[mxmlc] scanning for overrides: ResourceModuleInfo
[mxmlc] scanning for overrides: ResourceEventDispatcher
[mxmlc] scanning for overrides: ResourceBundleProxy
[mxmlc] scanning for overrides: GroupBase
[mxmlc] scanning for overrides: SkinnableComponent
[mxmlc] scanning for overrides: ButtonBase
[mxmlc] scanning for overrides: Button
[mxmlc] scanning for overrides: ErrorArray
[mxmlc] scanning for overrides: RunCodeEvent
[mxmlc] scanning for overrides: PasswordInputBead
[mxmlc] scanning for overrides: ITileLayout
[mxmlc] scanning for overrides: TileLayout
[mxmlc] scanning for overrides: LocaleUtils
[mxmlc] scanning for overrides: StringPadder
[mxmlc] scanning for overrides: UIDUtil
[mxmlc] scanning for overrides: IStroke
[mxmlc] scanning for overrides: CursorError
[mxmlc] scanning for overrides: SortError
[mxmlc] scanning for overrides: ISort
[mxmlc] scanning for overrides: Sort
[mxmlc] scanning for overrides: IXMLNotifiable
[mxmlc] scanning for overrides: XMLListAdapter
[mxmlc] scanning for overrides: FlexChildInfo
[mxmlc] scanning for overrides: BaseListData
[mxmlc] scanning for overrides: IFactory
[mxmlc] scanning for overrides: IUITextField
[mxmlc] scanning for overrides: UITextField
[mxmlc] scanning for overrides: CollectionEvent
[mxmlc] scanning for overrides: CollectionEventKind
[mxmlc] scanning for overrides: LocaleSorter
[mxmlc] scanning for overrides: LocaleID
[mxmlc] scanning for overrides: LocaleRegistry
[mxmlc] scanning for overrides: ResourceBundle
[mxmlc] scanning for overrides: ArrayUtil
[mxmlc] scanning for overrides: StringUtil
[mxmlc] scanning for overrides: UIDUtil
[mxmlc] scanning for overrides: DataGroup
[mxmlc] scanning for overrides: LayoutBase
[mxmlc] scanning for overrides: BasicLayout

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

2019-09-16 Thread Alex Harui
I'm not sure I understand your proposal.  Are you proposing that all public 
variables will be quoted and thus not renamed so we never warn again?  I am not 
in favor of that.  IMO, the vast majority of public vars can be renamed without 
penalty.  It is only certain classes that will be mapped to external code that 
matter.

My 2 cents,
-Alex

On 9/16/19, 10:46 AM, "Josh Tynjala"  wrote:

You're right. After a number of tests, I cannot find any annotation (or
combination of them) that will prevent the renaming of variables defined on
a prototype. All of the official advice that I see from Google suggests
quoting the properties (or using externs). So, from a Royale perspective,
it looks like quoting the public variable's name is our best option.

Similar to how we handle js-dynamic-access-unknown-members, we can quote
the public variable's name when getting or setting it in JS:

var foo = new Foo();
foo["bar"] = 2;
var baz = foo["bar"];

In this case, we also need to quote the public variable's name when
declaring it on the prototype:

Foo.prototype["bar"] = 3;

I did some tests, and I can confirm that Closure will preserve the public
variable's name, similar to how it preserves the names when we declare
public getters and setters. I'm going to make this change and turn off
warn-public-vars.

(To be clear, I'm only going to change how the emitter handles public
variables specifically. Behavior for other types of property access will
remain the same.)

--
Josh Tynjala
Bowler Hat LLC 



On Mon, Sep 16, 2019 at 10:06 AM Alex Harui 
wrote:

> Feel free to revisit.  IIRC, the issue is that you can't @export a "var".
> You can only @export a function because @export sets up a reference to the
> renamed function and you can't set up a reference to simple vars.
>
> Class Josh {
>   Static var foo:int = 1;
> }
>
> Compiles to:
>
>   Josh.foo = 1;
>
> Gets renamed to:
>
>   a.b = 1;
>
> The @export will result in:
>
>   ['Josh']['foo'] = a.b;
>
> And then code that does:
>
>   Josh.foo = 2;
>
> Will not change
>
>   Console.log(a.b); // 1 (not 2)
>
> Of course, I could be wrong..
>
> -Alex
>
> On 9/16/19, 9:57 AM, "Josh Tynjala"  wrote:
>
> I guess I was assuming that @nocollapse combined with @export would
> make it
> also prevent renaming. I suppose I can test it and see what happens.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741715916sdata=RzTt0oXl8VlOFQx61iqQmpTnZjzRQ83WA0nhC14VaBU%3Dreserved=0
> >
>
>
> On Mon, Sep 16, 2019 at 9:54 AM Alex Harui 
> wrote:
>
> > IMO, the -warn-public-vars is more about the "renaming" mentioned in
> that
> > link than the "collapse".
> >
> > If you have:
> >
> > Package {
> > Class Josh {
> >   Public var name:String;
> > }
> > Var foo:Josh = new Josh();
> > foo.name = 'josh';
> >
> > I don't think @nocollapse will prevent renaming the 'name' property
> to
> > something random like 'jt':
> >
> > Var foo = new Josh();
> > foo.jt = 'josh';
> >
> > AIUI, @nocollapse is used for things that are not obviously
> mutable.  If
> > you look in the globals in the browser debugger for any js-debug
> version of
> > a Royale app, you can see the structure:
> >
> >org.apache.royale.core
> >
> > It was created by code similar to:
> >
> > window.org = {};
> > window.org.apache = {};
> > window.org.apache.royale = {};
> > window.org.apache.royale.core = {};
> >
> > Then some class gets added:
> >
> > window.org.apache.royale.core.UIBase = function ()...
> >
> > And some static might get added to that:
> >
> > window.org.apache.royale.core.UIBase.FOO = "BAR";
> >
> > Closure will collapse org.apache.royale.core to just something like
> "bb"
> > in the js-release output.  And that means that code that sets
> UIBase.FOO
> > will break because there won't be an org.apache.royale.core
> structure.
> > AIUI, 

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

2019-09-16 Thread Josh Tynjala
You're right. After a number of tests, I cannot find any annotation (or
combination of them) that will prevent the renaming of variables defined on
a prototype. All of the official advice that I see from Google suggests
quoting the properties (or using externs). So, from a Royale perspective,
it looks like quoting the public variable's name is our best option.

Similar to how we handle js-dynamic-access-unknown-members, we can quote
the public variable's name when getting or setting it in JS:

var foo = new Foo();
foo["bar"] = 2;
var baz = foo["bar"];

In this case, we also need to quote the public variable's name when
declaring it on the prototype:

Foo.prototype["bar"] = 3;

I did some tests, and I can confirm that Closure will preserve the public
variable's name, similar to how it preserves the names when we declare
public getters and setters. I'm going to make this change and turn off
warn-public-vars.

(To be clear, I'm only going to change how the emitter handles public
variables specifically. Behavior for other types of property access will
remain the same.)

--
Josh Tynjala
Bowler Hat LLC 


On Mon, Sep 16, 2019 at 10:06 AM Alex Harui 
wrote:

> Feel free to revisit.  IIRC, the issue is that you can't @export a "var".
> You can only @export a function because @export sets up a reference to the
> renamed function and you can't set up a reference to simple vars.
>
> Class Josh {
>   Static var foo:int = 1;
> }
>
> Compiles to:
>
>   Josh.foo = 1;
>
> Gets renamed to:
>
>   a.b = 1;
>
> The @export will result in:
>
>   ['Josh']['foo'] = a.b;
>
> And then code that does:
>
>   Josh.foo = 2;
>
> Will not change
>
>   Console.log(a.b); // 1 (not 2)
>
> Of course, I could be wrong..
>
> -Alex
>
> On 9/16/19, 9:57 AM, "Josh Tynjala"  wrote:
>
> I guess I was assuming that @nocollapse combined with @export would
> make it
> also prevent renaming. I suppose I can test it and see what happens.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cd0c7fd54329c4f08a85708d73ac6ea33%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042498316114014sdata=N30d559D3wJpJJ5%2BPNSp%2BLR5jg64caj3rCByjf41iyk%3Dreserved=0
> >
>
>
> On Mon, Sep 16, 2019 at 9:54 AM Alex Harui 
> wrote:
>
> > IMO, the -warn-public-vars is more about the "renaming" mentioned in
> that
> > link than the "collapse".
> >
> > If you have:
> >
> > Package {
> > Class Josh {
> >   Public var name:String;
> > }
> > Var foo:Josh = new Josh();
> > foo.name = 'josh';
> >
> > I don't think @nocollapse will prevent renaming the 'name' property
> to
> > something random like 'jt':
> >
> > Var foo = new Josh();
> > foo.jt = 'josh';
> >
> > AIUI, @nocollapse is used for things that are not obviously
> mutable.  If
> > you look in the globals in the browser debugger for any js-debug
> version of
> > a Royale app, you can see the structure:
> >
> >org.apache.royale.core
> >
> > It was created by code similar to:
> >
> > window.org = {};
> > window.org.apache = {};
> > window.org.apache.royale = {};
> > window.org.apache.royale.core = {};
> >
> > Then some class gets added:
> >
> > window.org.apache.royale.core.UIBase = function ()...
> >
> > And some static might get added to that:
> >
> > window.org.apache.royale.core.UIBase.FOO = "BAR";
> >
> > Closure will collapse org.apache.royale.core to just something like
> "bb"
> > in the js-release output.  And that means that code that sets
> UIBase.FOO
> > will break because there won't be an org.apache.royale.core
> structure.
> > AIUI, nocollapse would prevent collapsing that structure, but won't
> prevent
> > UIBase and FOO from being renamed.  And the renaming mainly causes
> problems
> > when deserializing data structures coming from a server or other
> external
> > source.
> >
> > Of course, I could be wrong...
> > -Alex
> >
> > On 9/16/19, 9:07 AM, "Josh Tynjala" 
> wrote:
> >
> > I was looking through the Closure compiler annotations, and I
> noticed
> > @nocollapse:
> >
> > Denotes a property that should not be collapsed by the compiler
> into a
> > > variable. The primary use for @nocollapse is to allow
> exporting of
> > mutable
> > > properties.
> > >
> >
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23nocollapsedata=02%7C01%7Caharui%40adobe.com%7Cd0c7fd54329c4f08a85708d73ac6ea33%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042498316114014sdata=EyhgKMiOJL%2B7svlJUvqEb%2BWCC5J8ac5R2xPw2chkR3U%3Dreserved=0
> >
> > Isn't this collapsing behavior 

Re: [royale-asjs] branch release/0.9.6 updated: Update RELEASE_NOTES.md

2019-09-16 Thread OmPrakash Muppirala
This can always go in the next release :-)

Thanks,
Om

On Mon, Sep 16, 2019 at 4:32 AM Piotr Zarzycki 
wrote:

> I know Andrew. No problem ! :)
>
> pon., 16 wrz 2019 o 12:39 Andrew Wetmore  napisał(a):
>
> > The hurricane and is aftermath slowed me down. Anyhow all my edits were
> > minor.
> >
> > On Mon, Sep 16, 2019, 7:01 AM Piotr Zarzycki,  >
> > wrote:
> >
> > > Hi Andrew,
> > >
> > > I'm sorry but I already started preparing artifacts, so this probably
> > won't
> > > go to 0.9.6.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > pon., 16 wrz 2019 o 11:55  napisał(a):
> > >
> > > > This is an automated email from the ASF dual-hosted git repository.
> > > >
> > > > andreww pushed a commit to branch release/0.9.6
> > > > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> > > >
> > > >
> > > > The following commit(s) were added to refs/heads/release/0.9.6 by
> this
> > > > push:
> > > >  new 4136e54  Update RELEASE_NOTES.md
> > > > 4136e54 is described below
> > > >
> > > > commit 4136e543b3dba11bfadb08d9ce357cbb36d7b9a4
> > > > Author: Andrew Wetmore 
> > > > AuthorDate: Mon Sep 16 06:55:05 2019 -0300
> > > >
> > > > Update RELEASE_NOTES.md
> > > >
> > > > Many small text edits.
> > > > ---
> > > >  RELEASE_NOTES.md | 62
> > > > 
> > > >  1 file changed, 31 insertions(+), 31 deletions(-)
> > > >
> > > > diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md
> > > > index a4a4bb0..9e8ec3c 100644
> > > > --- a/RELEASE_NOTES.md
> > > > +++ b/RELEASE_NOTES.md
> > > > @@ -1,38 +1,38 @@
> > > >  Apache Royale 0.9.6
> > > >  ===
> > > >
> > > > -- Compiles faster
> > > > -- For applications targeting JavaScript, you can now incorporate the
> > > vast
> > > > resources available in existing, free, JavaScript libraries.
> > > > -- Many additional components available:
> > > > -  - for Jewel: Wizard, PopUp, TabBar, Module, ModuleLoader,
> FooterBar,
> > > > Badge, ScrollableSectionContent, HorizontalListScroll
> > > > -- Emulations of many other components available
> > > > -- Many improvements and fixes in Jewel UI Set:
> > > > -  - DateField/DateChooser full implememtation.
> > > > -  - Fixes to make components work right on IE11 and Android/iOS
> mobile
> > > > devices.
> > > > -  - Many improvements to all themes included (styles for new
> > components,
> > > > added more styles like disabled missing in some components,...)
> > > > -  - Many beads included for Jewel set:
> > > > -- Added search filter bead on Jewel ComboBox
> > > > -- Added SearchFilterForList bead to use with Jewel List and
> > > TextInput.
> > > > +- Compiles faster.
> > > > +- For applications targeting JavaScript, you can now incorporate the
> > > vast
> > > > resources available in existing, free JavaScript libraries.
> > > > +- Many additional components are available:
> > > > +  - for the Jewel component set, Wizard, PopUp, TabBar, Module,
> > > > ModuleLoader, FooterBar, Badge, ScrollableSectionContent, and
> > > > HorizontalListScroll are now available.
> > > > +- Emulations of many other components are available.
> > > > +- Many improvements and fixes in the Jewel component set:
> > > > +  - Full implementation of DateField/DateChooser.
> > > > +  - Components now work correctly on IE11 and on Android/iOS mobile
> > > > devices.
> > > > +  - Many improvements to all themes, such as styles for new
> components
> > > > and a disabled style that was missing in some components.
> > > > +  - Many beads have been added for Jewel components:
> > > > +- Search filter bead on Jewel ComboBox
> > > > +- SearchFilterForList bead to use with Jewel List and TextInput
> > > >  - RequiredSelection for DropDownList
> > > > -  - Improvements on focus handling
> > > > -  - Button now extends from new BasicButton
> > > > -- Many improvements on Tour De Jewel demo app to show all new
> > components
> > > > and beads developed in this version.
> > > > -- Added BrowserOrientation bead
> > > > -- Added loadCSS, to load external CSS dinamically.
> > > > -- Added generation of source-maps to all Royale libs for better
> > > debugging
> > > > framework code.
> > > > +  - Improvements to focus handling.
> > > > +  - Button now extends from new BasicButton.
> > > > +- Many improvements on Tour De Jewel demo app to show components and
> > > > beads introduced in this version.
> > > > +- Added BrowserOrientation bead.
> > > > +- Added loadCSS, to load external CSS dynamically.
> > > > +- Added generation of source-maps to all Royale libs for better
> > > debugging
> > > > of framework code.
> > > >  - Added new [RoyaleUnit](
> > > > https://apache.github.io/royale-docs/testing/royaleunit.html)
> library
> > > for
> > > > unit testing.
> > > > -- Improvements to AMF / RemoteObject Support
> > > > +- Improvements to AMF / RemoteObject Support.
> > > >  - AMFBinaryData api now matches flash.utils.ByteArray, (the missing
> > > > feature is non-UTF String 

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

2019-09-16 Thread Alex Harui
Feel free to revisit.  IIRC, the issue is that you can't @export a "var".  You 
can only @export a function because @export sets up a reference to the renamed 
function and you can't set up a reference to simple vars.

Class Josh {
  Static var foo:int = 1;
}

Compiles to:

  Josh.foo = 1;

Gets renamed to:

  a.b = 1;

The @export will result in:

  ['Josh']['foo'] = a.b;

And then code that does:

  Josh.foo = 2;

Will not change

  Console.log(a.b); // 1 (not 2)

Of course, I could be wrong..

-Alex

On 9/16/19, 9:57 AM, "Josh Tynjala"  wrote:

I guess I was assuming that @nocollapse combined with @export would make it
also prevent renaming. I suppose I can test it and see what happens.

--
Josh Tynjala
Bowler Hat LLC 



On Mon, Sep 16, 2019 at 9:54 AM Alex Harui  wrote:

> IMO, the -warn-public-vars is more about the "renaming" mentioned in that
> link than the "collapse".
>
> If you have:
>
> Package {
> Class Josh {
>   Public var name:String;
> }
> Var foo:Josh = new Josh();
> foo.name = 'josh';
>
> I don't think @nocollapse will prevent renaming the 'name' property to
> something random like 'jt':
>
> Var foo = new Josh();
> foo.jt = 'josh';
>
> AIUI, @nocollapse is used for things that are not obviously mutable.  If
> you look in the globals in the browser debugger for any js-debug version 
of
> a Royale app, you can see the structure:
>
>org.apache.royale.core
>
> It was created by code similar to:
>
> window.org = {};
> window.org.apache = {};
> window.org.apache.royale = {};
> window.org.apache.royale.core = {};
>
> Then some class gets added:
>
> window.org.apache.royale.core.UIBase = function ()...
>
> And some static might get added to that:
>
> window.org.apache.royale.core.UIBase.FOO = "BAR";
>
> Closure will collapse org.apache.royale.core to just something like "bb"
> in the js-release output.  And that means that code that sets UIBase.FOO
> will break because there won't be an org.apache.royale.core structure.
> AIUI, nocollapse would prevent collapsing that structure, but won't 
prevent
> UIBase and FOO from being renamed.  And the renaming mainly causes 
problems
> when deserializing data structures coming from a server or other external
> source.
>
> Of course, I could be wrong...
> -Alex
>
> On 9/16/19, 9:07 AM, "Josh Tynjala"  wrote:
>
> I was looking through the Closure compiler annotations, and I noticed
> @nocollapse:
>
> Denotes a property that should not be collapsed by the compiler into a
> > variable. The primary use for @nocollapse is to allow exporting of
> mutable
> > properties.
> >
>
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23nocollapsedata=02%7C01%7Caharui%40adobe.com%7Cd0c7fd54329c4f08a85708d73ac6ea33%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042498316114014sdata=EyhgKMiOJL%2B7svlJUvqEb%2BWCC5J8ac5R2xPw2chkR3U%3Dreserved=0
>
> Isn't this collapsing behavior the reason why we needed to add
> -warn-public-vars?
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cd0c7fd54329c4f08a85708d73ac6ea33%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042498316114014sdata=N30d559D3wJpJJ5%2BPNSp%2BLR5jg64caj3rCByjf41iyk%3Dreserved=0
> >
>
>
>




Re: Could @nocollapse be a solution to the -warn-public-vars issue?

2019-09-16 Thread Josh Tynjala
I guess I was assuming that @nocollapse combined with @export would make it
also prevent renaming. I suppose I can test it and see what happens.

--
Josh Tynjala
Bowler Hat LLC 


On Mon, Sep 16, 2019 at 9:54 AM Alex Harui  wrote:

> IMO, the -warn-public-vars is more about the "renaming" mentioned in that
> link than the "collapse".
>
> If you have:
>
> Package {
> Class Josh {
>   Public var name:String;
> }
> Var foo:Josh = new Josh();
> foo.name = 'josh';
>
> I don't think @nocollapse will prevent renaming the 'name' property to
> something random like 'jt':
>
> Var foo = new Josh();
> foo.jt = 'josh';
>
> AIUI, @nocollapse is used for things that are not obviously mutable.  If
> you look in the globals in the browser debugger for any js-debug version of
> a Royale app, you can see the structure:
>
>org.apache.royale.core
>
> It was created by code similar to:
>
> window.org = {};
> window.org.apache = {};
> window.org.apache.royale = {};
> window.org.apache.royale.core = {};
>
> Then some class gets added:
>
> window.org.apache.royale.core.UIBase = function ()...
>
> And some static might get added to that:
>
> window.org.apache.royale.core.UIBase.FOO = "BAR";
>
> Closure will collapse org.apache.royale.core to just something like "bb"
> in the js-release output.  And that means that code that sets UIBase.FOO
> will break because there won't be an org.apache.royale.core structure.
> AIUI, nocollapse would prevent collapsing that structure, but won't prevent
> UIBase and FOO from being renamed.  And the renaming mainly causes problems
> when deserializing data structures coming from a server or other external
> source.
>
> Of course, I could be wrong...
> -Alex
>
> On 9/16/19, 9:07 AM, "Josh Tynjala"  wrote:
>
> I was looking through the Closure compiler annotations, and I noticed
> @nocollapse:
>
> Denotes a property that should not be collapsed by the compiler into a
> > variable. The primary use for @nocollapse is to allow exporting of
> mutable
> > properties.
> >
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23nocollapsedata=02%7C01%7Caharui%40adobe.com%7C0444699041f3402d06c908d73abff16c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637042468374325733sdata=P%2FqQl7pq69YhAYtZQdKEHKnbgPuGDuD%2BikOca3aTOGY%3Dreserved=0
>
> Isn't this collapsing behavior the reason why we needed to add
> -warn-public-vars?
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C0444699041f3402d06c908d73abff16c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637042468374335722sdata=%2BwzLkQRXkpBeaII1wYWrT1z4fb%2FqKt3Qn2O7q1K1j3w%3Dreserved=0
> >
>
>
>


Re: Could @nocollapse be a solution to the -warn-public-vars issue?

2019-09-16 Thread Alex Harui
IMO, the -warn-public-vars is more about the "renaming" mentioned in that link 
than the "collapse".

If you have:

Package {
Class Josh {
  Public var name:String;
}
Var foo:Josh = new Josh();
foo.name = 'josh';

I don't think @nocollapse will prevent renaming the 'name' property to 
something random like 'jt':

Var foo = new Josh();
foo.jt = 'josh';

AIUI, @nocollapse is used for things that are not obviously mutable.  If you 
look in the globals in the browser debugger for any js-debug version of a 
Royale app, you can see the structure:

   org.apache.royale.core

It was created by code similar to:

window.org = {};
window.org.apache = {};
window.org.apache.royale = {};
window.org.apache.royale.core = {};

Then some class gets added:

window.org.apache.royale.core.UIBase = function ()...

And some static might get added to that:

window.org.apache.royale.core.UIBase.FOO = "BAR";

Closure will collapse org.apache.royale.core to just something like "bb" in the 
js-release output.  And that means that code that sets UIBase.FOO will break 
because there won't be an org.apache.royale.core structure.  AIUI, nocollapse 
would prevent collapsing that structure, but won't prevent UIBase and FOO from 
being renamed.  And the renaming mainly causes problems when deserializing data 
structures coming from a server or other external source.

Of course, I could be wrong...
-Alex

On 9/16/19, 9:07 AM, "Josh Tynjala"  wrote:

I was looking through the Closure compiler annotations, and I noticed
@nocollapse:

Denotes a property that should not be collapsed by the compiler into a
> variable. The primary use for @nocollapse is to allow exporting of mutable
> properties.
>


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23nocollapsedata=02%7C01%7Caharui%40adobe.com%7C0444699041f3402d06c908d73abff16c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637042468374325733sdata=P%2FqQl7pq69YhAYtZQdKEHKnbgPuGDuD%2BikOca3aTOGY%3Dreserved=0

Isn't this collapsing behavior the reason why we needed to add
-warn-public-vars?

--
Josh Tynjala
Bowler Hat LLC 





Jenkins build is back to normal : royale-asjs_jsonly #3549

2019-09-16 Thread Apache Royale CI Server
See 




Could @nocollapse be a solution to the -warn-public-vars issue?

2019-09-16 Thread Josh Tynjala
I was looking through the Closure compiler annotations, and I noticed
@nocollapse:

Denotes a property that should not be collapsed by the compiler into a
> variable. The primary use for @nocollapse is to allow exporting of mutable
> properties.
>

https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#nocollapse

Isn't this collapsing behavior the reason why we needed to add
-warn-public-vars?

--
Josh Tynjala
Bowler Hat LLC 


Jenkins build is back to normal : royale-typedefs #1621

2019-09-16 Thread Apache Royale CI Server
See 




Re: [royale-asjs] branch release/0.9.6 updated: Update RELEASE_NOTES.md

2019-09-16 Thread Piotr Zarzycki
I know Andrew. No problem ! :)

pon., 16 wrz 2019 o 12:39 Andrew Wetmore  napisał(a):

> The hurricane and is aftermath slowed me down. Anyhow all my edits were
> minor.
>
> On Mon, Sep 16, 2019, 7:01 AM Piotr Zarzycki, 
> wrote:
>
> > Hi Andrew,
> >
> > I'm sorry but I already started preparing artifacts, so this probably
> won't
> > go to 0.9.6.
> >
> > Thanks,
> > Piotr
> >
> > pon., 16 wrz 2019 o 11:55  napisał(a):
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > andreww pushed a commit to branch release/0.9.6
> > > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/release/0.9.6 by this
> > > push:
> > >  new 4136e54  Update RELEASE_NOTES.md
> > > 4136e54 is described below
> > >
> > > commit 4136e543b3dba11bfadb08d9ce357cbb36d7b9a4
> > > Author: Andrew Wetmore 
> > > AuthorDate: Mon Sep 16 06:55:05 2019 -0300
> > >
> > > Update RELEASE_NOTES.md
> > >
> > > Many small text edits.
> > > ---
> > >  RELEASE_NOTES.md | 62
> > > 
> > >  1 file changed, 31 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md
> > > index a4a4bb0..9e8ec3c 100644
> > > --- a/RELEASE_NOTES.md
> > > +++ b/RELEASE_NOTES.md
> > > @@ -1,38 +1,38 @@
> > >  Apache Royale 0.9.6
> > >  ===
> > >
> > > -- Compiles faster
> > > -- For applications targeting JavaScript, you can now incorporate the
> > vast
> > > resources available in existing, free, JavaScript libraries.
> > > -- Many additional components available:
> > > -  - for Jewel: Wizard, PopUp, TabBar, Module, ModuleLoader, FooterBar,
> > > Badge, ScrollableSectionContent, HorizontalListScroll
> > > -- Emulations of many other components available
> > > -- Many improvements and fixes in Jewel UI Set:
> > > -  - DateField/DateChooser full implememtation.
> > > -  - Fixes to make components work right on IE11 and Android/iOS mobile
> > > devices.
> > > -  - Many improvements to all themes included (styles for new
> components,
> > > added more styles like disabled missing in some components,...)
> > > -  - Many beads included for Jewel set:
> > > -- Added search filter bead on Jewel ComboBox
> > > -- Added SearchFilterForList bead to use with Jewel List and
> > TextInput.
> > > +- Compiles faster.
> > > +- For applications targeting JavaScript, you can now incorporate the
> > vast
> > > resources available in existing, free JavaScript libraries.
> > > +- Many additional components are available:
> > > +  - for the Jewel component set, Wizard, PopUp, TabBar, Module,
> > > ModuleLoader, FooterBar, Badge, ScrollableSectionContent, and
> > > HorizontalListScroll are now available.
> > > +- Emulations of many other components are available.
> > > +- Many improvements and fixes in the Jewel component set:
> > > +  - Full implementation of DateField/DateChooser.
> > > +  - Components now work correctly on IE11 and on Android/iOS mobile
> > > devices.
> > > +  - Many improvements to all themes, such as styles for new components
> > > and a disabled style that was missing in some components.
> > > +  - Many beads have been added for Jewel components:
> > > +- Search filter bead on Jewel ComboBox
> > > +- SearchFilterForList bead to use with Jewel List and TextInput
> > >  - RequiredSelection for DropDownList
> > > -  - Improvements on focus handling
> > > -  - Button now extends from new BasicButton
> > > -- Many improvements on Tour De Jewel demo app to show all new
> components
> > > and beads developed in this version.
> > > -- Added BrowserOrientation bead
> > > -- Added loadCSS, to load external CSS dinamically.
> > > -- Added generation of source-maps to all Royale libs for better
> > debugging
> > > framework code.
> > > +  - Improvements to focus handling.
> > > +  - Button now extends from new BasicButton.
> > > +- Many improvements on Tour De Jewel demo app to show components and
> > > beads introduced in this version.
> > > +- Added BrowserOrientation bead.
> > > +- Added loadCSS, to load external CSS dynamically.
> > > +- Added generation of source-maps to all Royale libs for better
> > debugging
> > > of framework code.
> > >  - Added new [RoyaleUnit](
> > > https://apache.github.io/royale-docs/testing/royaleunit.html) library
> > for
> > > unit testing.
> > > -- Improvements to AMF / RemoteObject Support
> > > +- Improvements to AMF / RemoteObject Support.
> > >  - AMFBinaryData api now matches flash.utils.ByteArray, (the missing
> > > feature is non-UTF String encoding support). It therefore now works for
> > > deep cloning via readObject/writeObject and registerClassAlias.
> > > -- Updates to Royale collections library with support for sorting and
> > > filtering via ArrayListView. Simple example added to Tour de Jewel
> > > -- A conforming runtime implementation of AS3 Vector (typed Arrays) was
> > > added for 

Re: [royale-asjs] branch release/0.9.6 updated: Update RELEASE_NOTES.md

2019-09-16 Thread Andrew Wetmore
The hurricane and is aftermath slowed me down. Anyhow all my edits were
minor.

On Mon, Sep 16, 2019, 7:01 AM Piotr Zarzycki, 
wrote:

> Hi Andrew,
>
> I'm sorry but I already started preparing artifacts, so this probably won't
> go to 0.9.6.
>
> Thanks,
> Piotr
>
> pon., 16 wrz 2019 o 11:55  napisał(a):
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > andreww pushed a commit to branch release/0.9.6
> > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> >
> >
> > The following commit(s) were added to refs/heads/release/0.9.6 by this
> > push:
> >  new 4136e54  Update RELEASE_NOTES.md
> > 4136e54 is described below
> >
> > commit 4136e543b3dba11bfadb08d9ce357cbb36d7b9a4
> > Author: Andrew Wetmore 
> > AuthorDate: Mon Sep 16 06:55:05 2019 -0300
> >
> > Update RELEASE_NOTES.md
> >
> > Many small text edits.
> > ---
> >  RELEASE_NOTES.md | 62
> > 
> >  1 file changed, 31 insertions(+), 31 deletions(-)
> >
> > diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md
> > index a4a4bb0..9e8ec3c 100644
> > --- a/RELEASE_NOTES.md
> > +++ b/RELEASE_NOTES.md
> > @@ -1,38 +1,38 @@
> >  Apache Royale 0.9.6
> >  ===
> >
> > -- Compiles faster
> > -- For applications targeting JavaScript, you can now incorporate the
> vast
> > resources available in existing, free, JavaScript libraries.
> > -- Many additional components available:
> > -  - for Jewel: Wizard, PopUp, TabBar, Module, ModuleLoader, FooterBar,
> > Badge, ScrollableSectionContent, HorizontalListScroll
> > -- Emulations of many other components available
> > -- Many improvements and fixes in Jewel UI Set:
> > -  - DateField/DateChooser full implememtation.
> > -  - Fixes to make components work right on IE11 and Android/iOS mobile
> > devices.
> > -  - Many improvements to all themes included (styles for new components,
> > added more styles like disabled missing in some components,...)
> > -  - Many beads included for Jewel set:
> > -- Added search filter bead on Jewel ComboBox
> > -- Added SearchFilterForList bead to use with Jewel List and
> TextInput.
> > +- Compiles faster.
> > +- For applications targeting JavaScript, you can now incorporate the
> vast
> > resources available in existing, free JavaScript libraries.
> > +- Many additional components are available:
> > +  - for the Jewel component set, Wizard, PopUp, TabBar, Module,
> > ModuleLoader, FooterBar, Badge, ScrollableSectionContent, and
> > HorizontalListScroll are now available.
> > +- Emulations of many other components are available.
> > +- Many improvements and fixes in the Jewel component set:
> > +  - Full implementation of DateField/DateChooser.
> > +  - Components now work correctly on IE11 and on Android/iOS mobile
> > devices.
> > +  - Many improvements to all themes, such as styles for new components
> > and a disabled style that was missing in some components.
> > +  - Many beads have been added for Jewel components:
> > +- Search filter bead on Jewel ComboBox
> > +- SearchFilterForList bead to use with Jewel List and TextInput
> >  - RequiredSelection for DropDownList
> > -  - Improvements on focus handling
> > -  - Button now extends from new BasicButton
> > -- Many improvements on Tour De Jewel demo app to show all new components
> > and beads developed in this version.
> > -- Added BrowserOrientation bead
> > -- Added loadCSS, to load external CSS dinamically.
> > -- Added generation of source-maps to all Royale libs for better
> debugging
> > framework code.
> > +  - Improvements to focus handling.
> > +  - Button now extends from new BasicButton.
> > +- Many improvements on Tour De Jewel demo app to show components and
> > beads introduced in this version.
> > +- Added BrowserOrientation bead.
> > +- Added loadCSS, to load external CSS dynamically.
> > +- Added generation of source-maps to all Royale libs for better
> debugging
> > of framework code.
> >  - Added new [RoyaleUnit](
> > https://apache.github.io/royale-docs/testing/royaleunit.html) library
> for
> > unit testing.
> > -- Improvements to AMF / RemoteObject Support
> > +- Improvements to AMF / RemoteObject Support.
> >  - AMFBinaryData api now matches flash.utils.ByteArray, (the missing
> > feature is non-UTF String encoding support). It therefore now works for
> > deep cloning via readObject/writeObject and registerClassAlias.
> > -- Updates to Royale collections library with support for sorting and
> > filtering via ArrayListView. Simple example added to Tour de Jewel
> > -- A conforming runtime implementation of AS3 Vector (typed Arrays) was
> > added for javascript output, with options for avoiding certain runtime
> > checks.
> > -- int, uint, Class are now represented as simple, distinct types (Class
> > is now not 'Object', int is now not 'Number' for example), and these
> > support indirect 'as' or 'is' type checking and instantiation, matching
> swf
> > behavior.
> 

Re: [royale-asjs] branch release/0.9.6 updated: Update RELEASE_NOTES.md

2019-09-16 Thread Piotr Zarzycki
Hi Andrew,

I'm sorry but I already started preparing artifacts, so this probably won't
go to 0.9.6.

Thanks,
Piotr

pon., 16 wrz 2019 o 11:55  napisał(a):

> This is an automated email from the ASF dual-hosted git repository.
>
> andreww pushed a commit to branch release/0.9.6
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>
>
> The following commit(s) were added to refs/heads/release/0.9.6 by this
> push:
>  new 4136e54  Update RELEASE_NOTES.md
> 4136e54 is described below
>
> commit 4136e543b3dba11bfadb08d9ce357cbb36d7b9a4
> Author: Andrew Wetmore 
> AuthorDate: Mon Sep 16 06:55:05 2019 -0300
>
> Update RELEASE_NOTES.md
>
> Many small text edits.
> ---
>  RELEASE_NOTES.md | 62
> 
>  1 file changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md
> index a4a4bb0..9e8ec3c 100644
> --- a/RELEASE_NOTES.md
> +++ b/RELEASE_NOTES.md
> @@ -1,38 +1,38 @@
>  Apache Royale 0.9.6
>  ===
>
> -- Compiles faster
> -- For applications targeting JavaScript, you can now incorporate the vast
> resources available in existing, free, JavaScript libraries.
> -- Many additional components available:
> -  - for Jewel: Wizard, PopUp, TabBar, Module, ModuleLoader, FooterBar,
> Badge, ScrollableSectionContent, HorizontalListScroll
> -- Emulations of many other components available
> -- Many improvements and fixes in Jewel UI Set:
> -  - DateField/DateChooser full implememtation.
> -  - Fixes to make components work right on IE11 and Android/iOS mobile
> devices.
> -  - Many improvements to all themes included (styles for new components,
> added more styles like disabled missing in some components,...)
> -  - Many beads included for Jewel set:
> -- Added search filter bead on Jewel ComboBox
> -- Added SearchFilterForList bead to use with Jewel List and TextInput.
> +- Compiles faster.
> +- For applications targeting JavaScript, you can now incorporate the vast
> resources available in existing, free JavaScript libraries.
> +- Many additional components are available:
> +  - for the Jewel component set, Wizard, PopUp, TabBar, Module,
> ModuleLoader, FooterBar, Badge, ScrollableSectionContent, and
> HorizontalListScroll are now available.
> +- Emulations of many other components are available.
> +- Many improvements and fixes in the Jewel component set:
> +  - Full implementation of DateField/DateChooser.
> +  - Components now work correctly on IE11 and on Android/iOS mobile
> devices.
> +  - Many improvements to all themes, such as styles for new components
> and a disabled style that was missing in some components.
> +  - Many beads have been added for Jewel components:
> +- Search filter bead on Jewel ComboBox
> +- SearchFilterForList bead to use with Jewel List and TextInput
>  - RequiredSelection for DropDownList
> -  - Improvements on focus handling
> -  - Button now extends from new BasicButton
> -- Many improvements on Tour De Jewel demo app to show all new components
> and beads developed in this version.
> -- Added BrowserOrientation bead
> -- Added loadCSS, to load external CSS dinamically.
> -- Added generation of source-maps to all Royale libs for better debugging
> framework code.
> +  - Improvements to focus handling.
> +  - Button now extends from new BasicButton.
> +- Many improvements on Tour De Jewel demo app to show components and
> beads introduced in this version.
> +- Added BrowserOrientation bead.
> +- Added loadCSS, to load external CSS dynamically.
> +- Added generation of source-maps to all Royale libs for better debugging
> of framework code.
>  - Added new [RoyaleUnit](
> https://apache.github.io/royale-docs/testing/royaleunit.html) library for
> unit testing.
> -- Improvements to AMF / RemoteObject Support
> +- Improvements to AMF / RemoteObject Support.
>  - AMFBinaryData api now matches flash.utils.ByteArray, (the missing
> feature is non-UTF String encoding support). It therefore now works for
> deep cloning via readObject/writeObject and registerClassAlias.
> -- Updates to Royale collections library with support for sorting and
> filtering via ArrayListView. Simple example added to Tour de Jewel
> -- A conforming runtime implementation of AS3 Vector (typed Arrays) was
> added for javascript output, with options for avoiding certain runtime
> checks.
> -- int, uint, Class are now represented as simple, distinct types (Class
> is now not 'Object', int is now not 'Number' for example), and these
> support indirect 'as' or 'is' type checking and instantiation, matching swf
> behavior.
> -- General Improvements and additions in Reflection library
> -- New Apache Royale Crux MVC/DI/IOC application architecture library
> (based on Swiz Framework) was added, with some simple examples
> -- Added many new or missing libs to [ASDocs reference](
> https://royale.apache.org/asdoc/)
> +- Updates to Royale collections library with support for sorting 

Release Step 011 Succeeded

2019-09-16 Thread Apache Royale CI Server
>From the royale-asjs repo:
1. Run ant -f releasesteps.xml Release_Step_011 -Drelease.version=0.9.6 
-DskipTests=true
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_011_Sign 
-Drelease.version=0.9.6
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_011_Upload 
-Drelease.version=0.9.6
This will upload the signed artifacts to Maven Release Staging.  Verify that 
the compiler and typedefs artifacts are there along with the asjs artifacts, 
then hit the close to close the staging repo. (https://repository.apache.org)

Release Step 010 Succeeded

2019-09-16 Thread Apache Royale CI Server
Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_010 and run the following commands:
git push
git push origin org.apache.royale.framework-0.9.6-rc1

You will need your Apache/Github username and 2FA token.

Release Step 009 Succeeded

2019-09-16 Thread Apache Royale CI Server
Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_009 and run the following commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 008 Succeeded

2019-09-16 Thread Apache Royale CI Server
Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_008 and run the following commands:
git push
git checkout release/0.9.6
git push -u origin release/0.9.6

You will need your Apache/Github username and 2FA token.

Release Step 008 Succeeded

2019-09-16 Thread Apache Royale CI Server
Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_008 and run the following commands:
git push
git checkout release/0.9.6
git push -u origin release/0.9.6

You will need your Apache/Github username and 2FA token.

Release Step 007 Succeeded

2019-09-16 Thread Apache Royale CI Server
>From the royale-typedefs repo:
1. Run ant -f releasesteps.xml Release_Step_007 -Drelease.version=0.9.6 
-DskipTests=true
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign 
-Drelease.version=0.9.6
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_007_Upload 
-Drelease.version=0.9.6
This will upload the signed artifacts to Maven Release Staging.  Do not "Close" 
the staging repository until the other repos have been added.

Release Step 006 Succeeded

2019-09-16 Thread Apache Royale CI Server
Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_006 and run the following commands:
git push
git push origin org.apache.royale.typedefs-0.9.6-rc1

You will need your Apache/Github username and 2FA token.

Release Step 005a Succeeded

2019-09-16 Thread Apache Royale CI Server
Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_005a_If_Utils and run the following 
commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 005 Succeeded

2019-09-16 Thread Apache Royale CI Server
Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_005 and run the following commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 004 Succeeded

2019-09-16 Thread Apache Royale CI Server
Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_004 and run the following commands:
git push
git checkout release/0.9.6
git push -u origin release/0.9.6

You will need your Apache/Github username and 2FA token.

Release Step 003 Succeeded

2019-09-16 Thread Apache Royale CI Server
>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools) - you have set in previous step for mentioned projects 
version ex. 1.1.0 not snapshot, Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_003_Sign 
-Drelease.version=0.9.6
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_003_Upload 
-Drelease.version=0.9.6
This will upload the signed artifacts to Maven Release Staging.  Do not "Close" 
the staging repository until the other repos have been added.

Release Step 002a Succeeded

2019-09-16 Thread Apache Royale CI Server
Continue on to Release Step 003

Release Step 002 Succeeded

2019-09-16 Thread Apache Royale CI Server
Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_002 and run the following commands:
git push
git push origin org.apache.royale.compiler-0.9.6-rc1

You will need your Apache/Github username and 2FA token.

Release Step 001a Succeeded

2019-09-16 Thread Apache Royale CI Server
Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_001a_If_Utils and run the following 
commands:
git push

You will need your Apache/Github username and 2FA token.

Re: Release notes files

2019-09-16 Thread Alex Harui
We've never put headers on these kinds of files.  Not sure what other projects 
do.  I'm not sure there is any IP in that file.

-Alex

On 9/15/19, 4:07 AM, "Andrew Wetmore"  wrote:

Should not the release notes files have the same headers that the code and
documentation files have?

a

-- 
Andrew Wetmore


https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2Fdata=02%7C01%7Caharui%40adobe.com%7Cddd10ad4bd704921681808d739ccd5e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637041424288616864sdata=X%2BNtmnPgAFRBz3DFBdcasvOvmzodXqIXPp2BXwbOyv8%3Dreserved=0