Re: Language improvements

[Greg Dove]

Harbs some quick comments inline...

On Thu, May 30, 2019 at 4:27 PM Harbs  wrote:

> The only niggle I have with my approach is that Vector in Flash is more
> performant than array, while in JS, it’s going to be the other way around.
> So if someone has a performance-sensitive piece of code, how should they
> write it so it outputs as performant as possible on both platforms?
>
> Vector in flash is only substantially faster for its 3 numeric types which
are optimized. It is (slightly) slower than Array in other cases - I think
it is normal that the extra type checking takes time even in native code.
I remember seeing some data which said it was 30% slower for some methods
with the non-primitive types, but that may be old.

In terms of the emulation version, you can get javascript Array speed with
the index access and assignment, which should be a direct copy of the same
parts of code that are heavily optimized in flash I think.

I was running performance tests on the non-debug flash player alongside
javascript. I actually see the regular native javascript Array beating
flash numeric Vectors in Chrome on windows, for the same tasks. Perhaps the
pepper plugin is getting less cpu resource than the browser or something
like that, not sure. I had assumed TypedArrays would be faster, but
recently you said you weren't sure because of js engine smarts. I will
still check that.



> I have not spent the time looking into the implementation, but I think
> there might be some cross-communication. My understanding from what Greg
> wrote is that if Vector is not used in an application, there will be no
> extra code due to dead code removal. If that’s correct, I think we’re in
> agreement that the implementation is fine. Do I understand correctly?
>

That is correct.


>
> Harbs
>
> > On May 30, 2019, at 1:26 AM, Josh Tynjala 
> wrote:
> >
> > I definitely want the default choice to have as few surprises as
> possible when it comes to how ActionScript behaves in Royale. We'll never
> have a perfect emulation, of course, but there are things that I think can
> still be improved. At the same time, I think it's perfectly valid for
> someone to want to opt into a typed Array that doesn't have the runtime
> overhead of Vector and isn't as heavy in file size. I'm wary of the
> solution being a custom implementation of Vector with missing features,
> though. It will lead to confusion, even if it's opt-in.
> >
> > What Harbs suggested seems like a smart way to go. Rather than having a
> separate Vector implementation that doesn't work as developers are used to,
> a new variation of Array that has compile-time type checks but no runtime
> checks sounds like a more elegant solution. Like Vector works in Royale
> today, it can compile down to a regular JS Array, but at compile-time, we'd
> have some extra safety and could even possibly cast back and forth with
> untyped Arrays (which we can't do with Vector).
> >
> > - Josh
> >
> > On 2019/05/29 18:07:31, Alex Harui  wrote:
> >> We must not eliminate choices.
> >>
> >> I still haven't had time to look at the branch.
> >>
> >> There must be away to avoid even a 1K cost to those who don't need it.
> >>
> >> If there is such a way, then it is fine to merge.  Otherwise, everyone
> is going to pay 2K to use a Vector when we know at least two apps are in
> production without needing that 2k.
> >>
> >> There are too many words being written and no technical points being
> made.  I will try to resummarize.
> >>
> >> 1) It does not matter how fast your network is.  Every other app will
> use more bandwidth and when the network gets busy or connectivity gets poor
> (something I see quite frequently where I live) either you get your app to
> run or you run out of time.
> >>
> >> 2) If you are not using some feature of our code, you should not have
> to pay for it in download cost.  That's PAYG.  That would be true for
> Vector, XML and even if we had to write a Date implementation.  It is not
> an issue of non-conforming.  It is an issue of optimization.  If you aren't
> going to use some feature of E4x you should have the option of using code
> that doesn't have those code paths.  Same for if we had to do Date.
> >>
> >> We know that if you don't need runtime-type checking and fixed-length
> checking that a plain Array is just fine and 2K cheaper.  Let's give folks
> the option to do that.
> >>
> >> I will repeat that I do not have any objection to having a full Vector
> implementation with runtime type-checking and fixed length checking be the
> default choice as long as folks can optimize back to using the plain Array
> code we use now.
> >>
> >> For the one Vector we currently have in all apps for the Strand, it
> might be time to change that to an array and check the type (in debug-only
> code) on addBead.  Either that or we add compiler options so that one
> Vector gets optimized to the current plain Array code.
> >>
> >> It is not a technical argument to classify Vector as 

Re: Error on mailing list page

[Piotr Zarzycki]

Hi Guys,

-1 for removing babble from the list.

+1 For switching to http.

Thanks,
Piotr

On Thu, May 30, 2019, 6:10 AM Harbs  wrote:

> More details in this link:
> http://support.nabble.com/HTTPS-SSL-urgent-td7594627.html#a7594635 <
> http://support.nabble.com/HTTPS-SSL-urgent-td7594627.html#a7594635>
>
> Simply put: Nabble does not support https.
>
> We can either keep those links as http, or get rid of Nabble…
>
> Harbs
>
> > On May 30, 2019, at 6:26 AM, Harbs  wrote:
> >
> > Looks like a problem with https on Nabble:
> >
> http://support.nabble.com/problem-with-security-certificate-with-nabble-forum-td7597896.html
> <
> http://support.nabble.com/problem-with-security-certificate-with-nabble-forum-td7597896.html
> >
> >
> >> On May 29, 2019, at 10:42 PM, QA  flexcapaci...@gmail.com>> wrote:
> >>
> >> Is anyone else getting errors when viewing the mailing list from the
> web page?
> >>
> >> https://royale.apache.org/mailing-lists/ <
> https://royale.apache.org/mailing-lists/>
> >>
> >> This server could not prove that it is*
> apache-royale-development.20373.n8.nabble.com*;
> >>
> >
>
>

Re: Language improvements

[Greg Dove]

The only 'safe' (for the community at large) way that I can see to do what
Alex wants is to make sure nothing of these alternate emulation classes is
*ever* baked into a swc and that the emulation variation can only be
specified for the whole build and be driven from the main application build
level.

I can think of one almost universal option for XML, which is a little more
straightforward, using dead code elimination. It might have drawbacks, but
would probably be the easiest option to implement and maintain, and I can
probably test that tomorrow with a local monkey patch.

The Vector 'emulation class' setup at the moment (which, to my knowledge,
has not been used by anyone yet) is problematic because it would end up
with the constructor variation baked into the swcs. I also think it is
cleaner and less confusing for 'alternate options' to be 'something else'
instead.

So I also agree that it would be best to add a dedicated compile-time typed
Array that is a 'new language feature' and represents something that makes
sense cross platform, something that we can specify to meet common needs.
I also think this makes sense longer term with the possible introduction of
other targets.



On Thu, May 30, 2019 at 10:26 AM Josh Tynjala 
wrote:

> I definitely want the default choice to have as few surprises as possible
> when it comes to how ActionScript behaves in Royale. We'll never have a
> perfect emulation, of course, but there are things that I think can still
> be improved. At the same time, I think it's perfectly valid for someone to
> want to opt into a typed Array that doesn't have the runtime overhead of
> Vector and isn't as heavy in file size. I'm wary of the solution being a
> custom implementation of Vector with missing features, though. It will lead
> to confusion, even if it's opt-in.
>
> What Harbs suggested seems like a smart way to go. Rather than having a
> separate Vector implementation that doesn't work as developers are used to,
> a new variation of Array that has compile-time type checks but no runtime
> checks sounds like a more elegant solution. Like Vector works in Royale
> today, it can compile down to a regular JS Array, but at compile-time, we'd
> have some extra safety and could even possibly cast back and forth with
> untyped Arrays (which we can't do with Vector).
>
> - Josh
>
> On 2019/05/29 18:07:31, Alex Harui  wrote:
> > We must not eliminate choices.
> >
> > I still haven't had time to look at the branch.
> >
> > There must be away to avoid even a 1K cost to those who don't need it.
> >
> > If there is such a way, then it is fine to merge.  Otherwise, everyone
> is going to pay 2K to use a Vector when we know at least two apps are in
> production without needing that 2k.
> >
> > There are too many words being written and no technical points being
> made.  I will try to resummarize.
> >
> > 1) It does not matter how fast your network is.  Every other app will
> use more bandwidth and when the network gets busy or connectivity gets poor
> (something I see quite frequently where I live) either you get your app to
> run or you run out of time.
> >
> > 2) If you are not using some feature of our code, you should not have to
> pay for it in download cost.  That's PAYG.  That would be true for Vector,
> XML and even if we had to write a Date implementation.  It is not an issue
> of non-conforming.  It is an issue of optimization.  If you aren't going to
> use some feature of E4x you should have the option of using code that
> doesn't have those code paths.  Same for if we had to do Date.
> >
> > We know that if you don't need runtime-type checking and fixed-length
> checking that a plain Array is just fine and 2K cheaper.  Let's give folks
> the option to do that.
> >
> > I will repeat that I do not have any objection to having a full Vector
> implementation with runtime type-checking and fixed length checking be the
> default choice as long as folks can optimize back to using the plain Array
> code we use now.
> >
> > For the one Vector we currently have in all apps for the Strand, it
> might be time to change that to an array and check the type (in debug-only
> code) on addBead.  Either that or we add compiler options so that one
> Vector gets optimized to the current plain Array code.
> >
> > It is not a technical argument to classify Vector as "Language" and
> therefore somehow an exception to being optimizable.
> >
> > My 2 cents,
> > -Alex
> >
> >
> > On 5/28/19, 2:59 AM, "Carlos Rovira"  wrote:
> >
> > Hi,
> >
> > I think that we all agree in most of the things, and although we're
> > discussing some particularities on how to solve, my opinion is that
> those
> > particularities can be solved after merging Language improvements
> branch.
> > We all agree we need this Vector (and other improvements in this
> branch)?.
> > So, after that merge folks wanting to improve, let's say, Vector(for
> > example) even more with new choices can do that 

Re: Language improvements

[Greg Dove]

Alex, I made some comments inline below...

On Thu, May 30, 2019 at 9:47 AM Alex Harui  wrote:

> We must not eliminate choices.
>
> I still haven't had time to look at the branch.
>
> There must be away to avoid even a 1K cost to those who don't need it.
>
> If there is such a way, then it is fine to merge.  Otherwise, everyone is
> going to pay 2K to use a Vector when we know at least two apps are in
> production without needing that 2k.
>
> There are too many words being written and no technical points being
> made.  I will try to resummarize.
>

As I have said, my concerns are not technical.


>
> 1) It does not matter how fast your network is.  Every other app will use
> more bandwidth and when the network gets busy or connectivity gets poor
> (something I see quite frequently where I live) either you get your app to
> run or you run out of time.
>
>
The only thing that seems particularly relevant for this discussion is how
long it takes for the 'app' to load when it is not already in browser cache.
I wholeheartedly agree that what I think about this in terms of the general
case is irrelevant if whoever is specifying the requirements for a
particular app says that incremental gains at 2KB or 1KB is what is
important to them (for any reason).
I'm not saying this is never important, I was just trying to explain how I
think of it in terms of why I prioritize things (by default) the way I do.
If we spent too much time and effort on meeting the needs of the few we may
under-represent the needs of the many. Without independent research neither
of us can be sure what the needs of the many are, so I am not going to
pursue this point any further.

2) If you are not using some feature of our code, you should not have to
> pay for it in download cost.  That's PAYG.  That would be true for Vector,
> XML and even if we had to write a Date implementation.  It is not an issue
> of non-conforming.  It is an issue of optimization.  If you aren't going to
> use some feature of E4x you should have the option of using code that
> doesn't have those code paths.  Same for if we had to do Date.
>

The only safe way to do what you propose that I can think of is to make
sure nothing of these alternate emulation classes is *ever* baked into a
swc and that any 'lite' version specified at the main application build
level wins for everything. I can see how this could be done for XML but I
don't see that easily for the 'emulation class' approach to Vector which I
think is the wrong way to achieve this.


> We know that if you don't need runtime-type checking and fixed-length
> checking that a plain Array is just fine and 2K cheaper.  Let's give folks
> the option to do that.
>
>
I think, as with others, that a new compile-time only typed Array is the
better way to do that. We can specify it as compiletime only and it will
never break the rules that we specify.

I will repeat that I do not have any objection to having a full Vector
> implementation with runtime type-checking and fixed length checking be the
> default choice as long as folks can optimize back to using the plain Array
> code we use now.
>
> I do understand your position. I don't agree with the plain Array output
option for Vector, but as I mentioned if it is a majority decision I will
make sure it is supported.
I think the better  option for the need you describe is the new typed Array
feature discussed by others.

For the one Vector we currently have in all apps for the Strand, it might
> be time to change that to an array and check the type (in debug-only code)
> on addBead.  Either that or we add compiler options so that one Vector gets
> optimized to the current plain Array code.
>
>
I already did exactly that in the branch. Vector has zero weight in
helloworld because it is not used in javascript.
I kept swf as it was, but I don't think there is any real value in keeping
that as vector in swf either, tbh. The addBead method is the only way to
put things into that as far as I can see, and the function signature
already gives you runtime type safety in that case in swf. Vector provides
no performance advantage over Array in swf in this case, and there is no
compiletime typesafety advantage. It might make sense to migrate both to a
common implementation as Array instead of having split code (which I can
look at later).


> It is not a technical argument to classify Vector as "Language" and
> therefore somehow an exception to being optimizable.
>
>
I have never intended to imply that. If "Language" is optimizable without
the risk of bad consequences, that is fine by me.
But "Language" must work as advertised when exposed to anyone who has no
reason to think otherwise, and an 'optimized' version which does not do so
in that case is 'dangerous', and will tarnish royale's reputation in my
view. The biggest risks I see are if something non-conforming is exposed in
a public swc library either directly via api, or via access through
inheritance, but there could be other 

Re: Language improvements

[Harbs]

The only niggle I have with my approach is that Vector in Flash is more 
performant than array, while in JS, it’s going to be the other way around. So 
if someone has a performance-sensitive piece of code, how should they write it 
so it outputs as performant as possible on both platforms?

I have not spent the time looking into the implementation, but I think there 
might be some cross-communication. My understanding from what Greg wrote is 
that if Vector is not used in an application, there will be no extra code due 
to dead code removal. If that’s correct, I think we’re in agreement that the 
implementation is fine. Do I understand correctly?

Harbs

> On May 30, 2019, at 1:26 AM, Josh Tynjala  wrote:
> 
> I definitely want the default choice to have as few surprises as possible 
> when it comes to how ActionScript behaves in Royale. We'll never have a 
> perfect emulation, of course, but there are things that I think can still be 
> improved. At the same time, I think it's perfectly valid for someone to want 
> to opt into a typed Array that doesn't have the runtime overhead of Vector 
> and isn't as heavy in file size. I'm wary of the solution being a custom 
> implementation of Vector with missing features, though. It will lead to 
> confusion, even if it's opt-in.
> 
> What Harbs suggested seems like a smart way to go. Rather than having a 
> separate Vector implementation that doesn't work as developers are used to, a 
> new variation of Array that has compile-time type checks but no runtime 
> checks sounds like a more elegant solution. Like Vector works in Royale 
> today, it can compile down to a regular JS Array, but at compile-time, we'd 
> have some extra safety and could even possibly cast back and forth with 
> untyped Arrays (which we can't do with Vector).
> 
> - Josh
> 
> On 2019/05/29 18:07:31, Alex Harui  wrote: 
>> We must not eliminate choices.
>> 
>> I still haven't had time to look at the branch.
>> 
>> There must be away to avoid even a 1K cost to those who don't need it.
>> 
>> If there is such a way, then it is fine to merge.  Otherwise, everyone is 
>> going to pay 2K to use a Vector when we know at least two apps are in 
>> production without needing that 2k.
>> 
>> There are too many words being written and no technical points being made.  
>> I will try to resummarize.
>> 
>> 1) It does not matter how fast your network is.  Every other app will use 
>> more bandwidth and when the network gets busy or connectivity gets poor 
>> (something I see quite frequently where I live) either you get your app to 
>> run or you run out of time.  
>> 
>> 2) If you are not using some feature of our code, you should not have to pay 
>> for it in download cost.  That's PAYG.  That would be true for Vector, XML 
>> and even if we had to write a Date implementation.  It is not an issue of 
>> non-conforming.  It is an issue of optimization.  If you aren't going to use 
>> some feature of E4x you should have the option of using code that doesn't 
>> have those code paths.  Same for if we had to do Date.
>> 
>> We know that if you don't need runtime-type checking and fixed-length 
>> checking that a plain Array is just fine and 2K cheaper.  Let's give folks 
>> the option to do that.
>> 
>> I will repeat that I do not have any objection to having a full Vector 
>> implementation with runtime type-checking and fixed length checking be the 
>> default choice as long as folks can optimize back to using the plain Array 
>> code we use now.
>> 
>> For the one Vector we currently have in all apps for the Strand, it might be 
>> time to change that to an array and check the type (in debug-only code) on 
>> addBead.  Either that or we add compiler options so that one Vector gets 
>> optimized to the current plain Array code.
>> 
>> It is not a technical argument to classify Vector as "Language" and 
>> therefore somehow an exception to being optimizable.
>> 
>> My 2 cents,
>> -Alex
>> 
>> 
>> On 5/28/19, 2:59 AM, "Carlos Rovira"  wrote:
>> 
>>Hi,
>> 
>>I think that we all agree in most of the things, and although we're
>>discussing some particularities on how to solve, my opinion is that those
>>particularities can be solved after merging Language improvements branch.
>>We all agree we need this Vector (and other improvements in this branch)?.
>>So, after that merge folks wanting to improve, let's say, Vector(for
>>example) even more with new choices can do that without problem and will
>>make it even better.
>> 
>>Are we ok with that?
>> 
>> 
>> 
>> 
>> 
>>El mar., 28 may. 2019 a las 11:07, Harbs () 
>> escribió:
>> 
>>> 
 On May 28, 2019, at 11:12 AM, Greg Dove  wrote:
 
> "I personally have never used length checking in Vector. Nor was runtime
> type checking on Vectors important to me. "
 length checking is automatic in flash. I don't know that you 'use' it...
>>> it
 is just there.
>>> 
>>> True. What I meant is that I never used 

Re: Error on mailing list page

[Harbs]

More details in this link:
http://support.nabble.com/HTTPS-SSL-urgent-td7594627.html#a7594635 


Simply put: Nabble does not support https.

We can either keep those links as http, or get rid of Nabble…

Harbs

> On May 30, 2019, at 6:26 AM, Harbs  wrote:
> 
> Looks like a problem with https on Nabble:
> http://support.nabble.com/problem-with-security-certificate-with-nabble-forum-td7597896.html
>  
> 
> 
>> On May 29, 2019, at 10:42 PM, QA > > wrote:
>> 
>> Is anyone else getting errors when viewing the mailing list from the web 
>> page?
>> 
>> https://royale.apache.org/mailing-lists/ 
>> 
>> 
>> This server could not prove that it 
>> is*apache-royale-development.20373.n8.nabble.com*;
>> 
> 

Re: Error on mailing list page

[Harbs]

Looks like a problem with https on Nabble:
http://support.nabble.com/problem-with-security-certificate-with-nabble-forum-td7597896.html
 


> On May 29, 2019, at 10:42 PM, QA  wrote:
> 
> Is anyone else getting errors when viewing the mailing list from the web page?
> 
> https://royale.apache.org/mailing-lists/
> 
> This server could not prove that it 
> is*apache-royale-development.20373.n8.nabble.com*;
> 

Build failed in Jenkins: royale-asjs_jsonly #3014

[Apache Royale CI Server]

See 


--
[...truncated 602.31 KB...]
[javac]  ^
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler-jx\src\test\java\org\apache\royale\compiler\internal\codegen\js\royale\TestRoyaleProject.java:200:
 warning: [cast] redundant cast to RoyaleJSProject
[javac] project.setTargetSettings(new 
TargetSettings(((RoyaleJSProject)project).config, (RoyaleJSProject)project));
[javac]   ^
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler-jx\src\test\java\org\apache\royale\compiler\internal\codegen\js\royale\TestRoyaleProject.java:200:
 warning: [cast] redundant cast to RoyaleJSProject
[javac] project.setTargetSettings(new 
TargetSettings(((RoyaleJSProject)project).config, (RoyaleJSProject)project));
[javac] 
^
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler-jx\src\test\java\org\apache\royale\compiler\internal\codegen\js\royale\TestRoyaleProject.java:353:
 warning: [cast] redundant cast to RoyaleJSProject
[javac] ((RoyaleJSProject)project).unitTestExterns = externs;
[javac]  ^
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler-jx\src\test\java\org\apache\royale\compiler\internal\codegen\mxml\TestMXMLAttributes.java:49:
 warning: [cast] redundant cast to IMXMLInstanceNode
[javac] assertThat(((IMXMLInstanceNode) node).getID(), is("myBtn"));
[javac] ^
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler-jx\src\test\java\org\apache\royale\compiler\internal\codegen\mxml\royale\TestRoyaleMXMLApplication.java:50:
 warning: [cast] redundant cast to RoyaleJSProject
[javac] ((RoyaleJSProject)project).config = new 
JSGoogConfiguration();
[javac]  ^
[javac] 14 warnings

unit.tests:
[mkdir] Created dir: C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler-jx\target\junit-results
[mkdir] Created dir: C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler-jx\target\junit-temp
[junit] looking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\env.properties
[junit] environment property - FLEX_HOME = null
[junit] environment property - PLAYERGLOBAL_HOME = null
[junit] environment property - PLAYERGLOBAL_VERSION = 11.1
[junit] environment property - TLF_HOME = null
[junit] environment property - AIR_HOME = null
[junit] environment property - FLASHPLAYER_DEBUGGER = null
[junit] environment property - ASJS_HOME = 
c:\jenkins\workspace\royale-asjs_jsonly
[junit] environment property - GOOG_HOME = null
[junit] Running 
org.apache.royale.compiler.internal.codegen.as.TestAccessorMembers
[junit] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.276 sec
[junit] Running org.apache.royale.compiler.internal.codegen.as.TestClass
[junit] Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.626 sec
[junit] Running org.apache.royale.compiler.internal.codegen.as.TestComments
[junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.03 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.as.TestExpressions
[junit] Tests run: 86, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.96 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.as.TestFieldMembers
[junit] Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.418 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.as.TestGlobalClasses
[junit] Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.848 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.as.TestGlobalConstants
[junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.072 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.as.TestGlobalFunctions
[junit] Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.505 sec
[junit] Running org.apache.royale.compiler.internal.codegen.as.TestInterface
[junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.129 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.as.TestMethodMembers
[junit] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.241 sec
[junit] Running org.apache.royale.compiler.internal.codegen.as.TestPackage
[junit] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.141 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.as.TestParenthesis
[junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time 

Release Step 010 Succeeded

[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.

Re: Language improvements

[Josh Tynjala]

I definitely want the default choice to have as few surprises as possible when 
it comes to how ActionScript behaves in Royale. We'll never have a perfect 
emulation, of course, but there are things that I think can still be improved. 
At the same time, I think it's perfectly valid for someone to want to opt into 
a typed Array that doesn't have the runtime overhead of Vector and isn't as 
heavy in file size. I'm wary of the solution being a custom implementation of 
Vector with missing features, though. It will lead to confusion, even if it's 
opt-in.

What Harbs suggested seems like a smart way to go. Rather than having a 
separate Vector implementation that doesn't work as developers are used to, a 
new variation of Array that has compile-time type checks but no runtime checks 
sounds like a more elegant solution. Like Vector works in Royale today, it can 
compile down to a regular JS Array, but at compile-time, we'd have some extra 
safety and could even possibly cast back and forth with untyped Arrays (which 
we can't do with Vector).

- Josh

On 2019/05/29 18:07:31, Alex Harui  wrote: 
> We must not eliminate choices.
> 
> I still haven't had time to look at the branch.
> 
> There must be away to avoid even a 1K cost to those who don't need it.
> 
> If there is such a way, then it is fine to merge.  Otherwise, everyone is 
> going to pay 2K to use a Vector when we know at least two apps are in 
> production without needing that 2k.
> 
> There are too many words being written and no technical points being made.  I 
> will try to resummarize.
> 
> 1) It does not matter how fast your network is.  Every other app will use 
> more bandwidth and when the network gets busy or connectivity gets poor 
> (something I see quite frequently where I live) either you get your app to 
> run or you run out of time.  
> 
> 2) If you are not using some feature of our code, you should not have to pay 
> for it in download cost.  That's PAYG.  That would be true for Vector, XML 
> and even if we had to write a Date implementation.  It is not an issue of 
> non-conforming.  It is an issue of optimization.  If you aren't going to use 
> some feature of E4x you should have the option of using code that doesn't 
> have those code paths.  Same for if we had to do Date.
> 
> We know that if you don't need runtime-type checking and fixed-length 
> checking that a plain Array is just fine and 2K cheaper.  Let's give folks 
> the option to do that.
> 
> I will repeat that I do not have any objection to having a full Vector 
> implementation with runtime type-checking and fixed length checking be the 
> default choice as long as folks can optimize back to using the plain Array 
> code we use now.
> 
> For the one Vector we currently have in all apps for the Strand, it might be 
> time to change that to an array and check the type (in debug-only code) on 
> addBead.  Either that or we add compiler options so that one Vector gets 
> optimized to the current plain Array code.
> 
> It is not a technical argument to classify Vector as "Language" and therefore 
> somehow an exception to being optimizable.
> 
> My 2 cents,
> -Alex
> 
> 
> On 5/28/19, 2:59 AM, "Carlos Rovira"  wrote:
> 
> Hi,
> 
> I think that we all agree in most of the things, and although we're
> discussing some particularities on how to solve, my opinion is that those
> particularities can be solved after merging Language improvements branch.
> We all agree we need this Vector (and other improvements in this branch)?.
> So, after that merge folks wanting to improve, let's say, Vector(for
> example) even more with new choices can do that without problem and will
> make it even better.
> 
> Are we ok with that?
> 
> 
> 
> 
> 
> El mar., 28 may. 2019 a las 11:07, Harbs () 
> escribió:
> 
> >
> > > On May 28, 2019, at 11:12 AM, Greg Dove  wrote:
> > >
> > >> "I personally have never used length checking in Vector. Nor was 
> runtime
> > >> type checking on Vectors important to me. "
> > > length checking is automatic in flash. I don't know that you 'use' 
> it...
> > it
> > > is just there.
> >
> > True. What I meant is that I never used fixed length Vectors.
> >
> > > In javascript I expect it would most often be switched off in all 
> release
> > > builds, but having it on by default provides another check of 
> something
> > > that could provide a vital clue to help people figuring out problems 
> in
> > > code.
> > > So far each 'stronger typing' feature added in the last few months has
> > > revealed potential issues or - most often - bad code that was working
> > when
> > > it should not
> >
> > Good points, and one that argues for the ability to have these checks
> > while debugging and have the run-time code removed on release.
> >
> > > One thing about the mxml stuff is that it gets processed in 

Release Step 001 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_001 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 002 Succeeded

[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 010 Succeeded

[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 007 Succeeded

[Apache Royale CI Server]

>From the royale-typedefs repo:
1. Run ant -f releasesteps.xml Release_Step_007 -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_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

[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

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_005a and run the following commands:
git push

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

Release Step 005 Succeeded

[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

[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 008 Succeeded

[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.

Error on mailing list page

[QA]

Is anyone else getting errors when viewing the mailing list from the web 
page?


https://royale.apache.org/mailing-lists/

This server could not prove that it 
is*apache-royale-development.20373.n8.nabble.com*;

Release Step 009 Succeeded

[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.

Re: Language improvements

[Alex Harui]

We must not eliminate choices.

I still haven't had time to look at the branch.

There must be away to avoid even a 1K cost to those who don't need it.

If there is such a way, then it is fine to merge.  Otherwise, everyone is going 
to pay 2K to use a Vector when we know at least two apps are in production 
without needing that 2k.

There are too many words being written and no technical points being made.  I 
will try to resummarize.

1) It does not matter how fast your network is.  Every other app will use more 
bandwidth and when the network gets busy or connectivity gets poor (something I 
see quite frequently where I live) either you get your app to run or you run 
out of time.  

2) If you are not using some feature of our code, you should not have to pay 
for it in download cost.  That's PAYG.  That would be true for Vector, XML and 
even if we had to write a Date implementation.  It is not an issue of 
non-conforming.  It is an issue of optimization.  If you aren't going to use 
some feature of E4x you should have the option of using code that doesn't have 
those code paths.  Same for if we had to do Date.

We know that if you don't need runtime-type checking and fixed-length checking 
that a plain Array is just fine and 2K cheaper.  Let's give folks the option to 
do that.

I will repeat that I do not have any objection to having a full Vector 
implementation with runtime type-checking and fixed length checking be the 
default choice as long as folks can optimize back to using the plain Array code 
we use now.

For the one Vector we currently have in all apps for the Strand, it might be 
time to change that to an array and check the type (in debug-only code) on 
addBead.  Either that or we add compiler options so that one Vector gets 
optimized to the current plain Array code.

It is not a technical argument to classify Vector as "Language" and therefore 
somehow an exception to being optimizable.

My 2 cents,
-Alex


On 5/28/19, 2:59 AM, "Carlos Rovira"  wrote:

Hi,

I think that we all agree in most of the things, and although we're
discussing some particularities on how to solve, my opinion is that those
particularities can be solved after merging Language improvements branch.
We all agree we need this Vector (and other improvements in this branch)?.
So, after that merge folks wanting to improve, let's say, Vector(for
example) even more with new choices can do that without problem and will
make it even better.

Are we ok with that?





El mar., 28 may. 2019 a las 11:07, Harbs () escribió:

>
> > On May 28, 2019, at 11:12 AM, Greg Dove  wrote:
> >
> >> "I personally have never used length checking in Vector. Nor was 
runtime
> >> type checking on Vectors important to me. "
> > length checking is automatic in flash. I don't know that you 'use' it...
> it
> > is just there.
>
> True. What I meant is that I never used fixed length Vectors.
>
> > In javascript I expect it would most often be switched off in all 
release
> > builds, but having it on by default provides another check of something
> > that could provide a vital clue to help people figuring out problems in
> > code.
> > So far each 'stronger typing' feature added in the last few months has
> > revealed potential issues or - most often - bad code that was working
> when
> > it should not
>
> Good points, and one that argues for the ability to have these checks
> while debugging and have the run-time code removed on release.
>
> > One thing about the mxml stuff is that it gets processed in a way that 
is
> > untyped.
>
>
> Agree. I do wish there was some way for MXML to be output “better” where
> minified vars could “just work” and types could be better inferred from 
the
> MXML files.



-- 
Carlos Rovira

https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Ce8d86e6cf4aa4271e8ad08d6e35326eb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636946343611259722sdata=g8BXA5jwwT98fAbwdMR2FqmJ3CgKd01zsm1lpt5pTDg%3Dreserved=0

Release Step 011 Succeeded

[Apache Royale CI Server]

>From the royale-asjs repo:
1. Run ant -f releasesteps.xml Release_Step_011 -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_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.

Build failed in Jenkins: royale-asjs_jsonly #3013

[Apache Royale CI Server]

See 


Changes:

[carlosrovira] configs-xml: enable abstract classes and private constructors by 
default

--
[...truncated 2.10 MB...]
[mxmlc] 

 removing require: org.apache.royale.utils.Language
[mxmlc] Dependencies calculated for 'org.apache.royale.utils.StringUtil'
[mxmlc] Dependencies calculated for 'org.apache.royale.utils.StringTrimmer'
[mxmlc] 

 removing require: org.apache.royale.core.IChild
[mxmlc] 

 removing require: org.apache.royale.core.IContainer
[mxmlc] 

 removing require: org.apache.royale.core.IParent
[mxmlc] 

 removing require: org.apache.royale.core.IStatesObject
[mxmlc] 

 removing require: org.apache.royale.core.IStrand
[mxmlc] 

 removing require: org.apache.royale.events.Event
[mxmlc] 

 removing require: org.apache.royale.events.IEventDispatcher
[mxmlc] 

 removing require: org.apache.royale.events.ValueChangeEvent
[mxmlc] 

 removing require: org.apache.royale.states.AddItems
[mxmlc] 

 removing require: org.apache.royale.states.SetEventHandler
[mxmlc] 

 removing require: org.apache.royale.states.SetProperty
[mxmlc] 

 removing require: org.apache.royale.states.State
[mxmlc] 

 removing require: org.apache.royale.utils.MXMLDataInterpreter
[mxmlc] 

 removing require: org.apache.royale.utils.Language
[mxmlc] Dependencies calculated for 
'org.apache.royale.core.SimpleStatesImpl'
[mxmlc] org.apache.royale.core.SimpleStatesImpl depends on 
org.apache.royale.events.EventDispatcher
[mxmlc] org.apache.royale.core.SimpleStatesImpl depends on 
org.apache.royale.core.IStatesImpl
[mxmlc] org.apache.royale.core.SimpleStatesImpl depends on 
org.apache.royale.core.IBead
[mxmlc] Dependencies calculated for 
'org.apache.royale.states.SetEventHandler'
[mxmlc] org.apache.royale.states.SetEventHandler depends on 
org.apache.royale.core.IDocument
[mxmlc] Dependencies calculated for 'org.apache.royale.states.SetProperty'
[mxmlc] org.apache.royale.states.SetProperty depends on 
org.apache.royale.core.IDocument
[mxmlc] 

 removing require: org.apache.royale.core.IContainer
[mxmlc] 

Release Step 011 Succeeded

[Apache Royale CI Server]

>From the royale-asjs repo:
1. Run ant -f releasesteps.xml Release_Step_011 -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_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.

Release Step 003 Succeeded

[Apache Royale CI Server]

>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), 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.