Build failed in Jenkins: royale-asjs_MXTests #819

[Apache Royale CI Server]

See 


--
[...truncated 2.09 MB...]
[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

Build failed in Jenkins: royale-asjs_MXTests #818

[Apache Royale CI Server]

See 


--
[...truncated 2.16 MB...]
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/reflection/MetaDataDefinition.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/html/beads/ISpinnerView.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/html/beads/SpinnerView.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/core/IViewportModel.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/core/WrappedHTMLElement.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/spark/layouts/supportClasses/DropLocation.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/core/layout/LayoutData.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/mx/collections/errors/CursorError.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/core/TextLineMetrics.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/mx/styles/CSSStyleDeclaration.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/mx/events/utils/FocusEventConverter.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/reflection/MethodDefinition.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/mx/display/Graphics.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/mx/core/ScrollControlBase.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/mx/controls/listClasses/ListBase.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/core/IDataProviderVirtualItemRendererMapper.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/binding/WatcherBase.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/core/IImage.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/events/BrowserEvent.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/html/beads/models/PanelModel.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/mx/containers/beads/models/PanelModel.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/core/IPopUp.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/halo/scripts/ButtonTestScript.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/spark/scripts/ButtonTestScript.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/mx/controls/ComboBase.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/mx/controls/DateField.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/RoyaleContext.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/core/ContainerBaseStrandChildren.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/utils/BinaryData.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/utils/UIUtils.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/html/beads/controllers/ListSingleSelectionMouseController.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/org/apache/royale/html/beads/controllers/MenuBarMouseController.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs_MXTests/mustella/tests/mxtests/basicTests/bin/js-debug/mx/controls/beads/controllers/MenuBarMouseController.js
[mxmlc] 

Re: Language improvements

[Harbs]

The reason I mentioned my desire to have `int[]` and `MyFoo[]` in addition to 
Vector was that I thought it might be another solution to this problem.

I personally have never used length checking in Vector. Nor was runtime type 
checking on Vectors important to me.

When I was porting a javascript library for use with Royale, array 
incompatibility with Vector was a pain point.

In short, I want the ability to type check my arrays at compile time and have 
them completely compatible with generic arrays (something I’m missing currently 
with Vector). I don’t want or need the extra weight.

To me, a good solution would be to have full runtime type checking in Vector 
and be able to use “typed” arrays (not to be confused with TypedArrays) to 
avoid the runtime weight.

I discussed in the past with Josh the concept of implementing “typed arrays” in 
addition to Vectors. Maybe now would be a good time to make that happen.

I do like the concept of optimizing how certain vectors are output (such as 
TypedArrays), but that might be something that can happen later.

FWIW, most JS engines will automatically use a TypedArray under the hood if you 
use an array where all the elements are integers, so there’s not usually a 
practical advantage to writing that optimization explicitly.

My $0.02,
Harbs

> On May 27, 2019, at 9:43 PM, Alex Harui  wrote:
> 
> Hi Greg,
> 
> I live outside of Seattle.  I'm in my house right now, and my cellphone says 
> I have a 4G connection.  Many times a month, I take a ferry boat to Seattle.  
> There is a point during the ride where the connectivity is poor.  Yesterday, 
> I was trying to get work done on the ferry and was blocked from doing one 
> step in the release automation because it would not load in time.  Many 
> times, I'm trying to get one thing finished and get stymied by poor 
> connectivity.  I hear this complaint from plenty of other residents where I 
> live.  I want Royale to produce the app that loads when other apps don't.  
> Forcing everyone to take on another 2000+ bytes is not going to help.
> 
> The argument of "it is only another 1K" is what eventually caused UIComponent 
> to grow to 13,000 lines and 128K Hello World.  That's history.  I do not want 
> to repeat it.
> 
> I still haven't had time to look at your changes or read and respond to all 
> of the words you've written.  Mostly for others who haven't been following 
> the discussion, my reasoning is as follows:
> 
> -Vector and XML and any other built-in for SWF that isn't in JS are not free. 
>  We have to write some amount of code to get them to work.  
> -Vector provides runtime type checking.  Not everybody needs runtime type 
> checking in production.  
> -Vector provides length checking.  Not everybody needs length checking in 
> production.  
> -We've already proven that by having at least two projects get into 
> production without your implementation of Vector.  
> -The current compiler output for Vector for folks who don't need runtime 
> checking just uses Array.
> -Your implementation adds 2990 bytes.
> 
> For sure, we need an implementation that does runtime type-checking and 
> length checking.  So, as long as folks can choose to save the 2990 bytes and 
> just use the current compiler output for Array in production, then we have 
> given folks the right choices.  Bonus if we can let folks choose other Vector 
> implementations just like they can choose other XML implementations.  My 
> understanding from the words you've written is that you want everyone to use 
> your Vector implementation and have options on what code paths that 
> implementation actually takes, but I don't understand why from a technical 
> perspective.
> 
> In fact, I was reading up on Javascript TypedArrays (because that did load 
> while on the ferry) and it looks like some folks might want Vector. to 
> map to the appropriate TypedArray.  It actually got me wondering if folks 
> should be able to dictate how any particular instance of a Vector "optimizes".
> 
> In sum, the download size still matters.  I see it quite frequently.  
> Technically, why shouldn't folks have a choice of implementations?
> 
> -Alex
> 
> On 5/27/19, 2:46 AM, "Greg Dove"  > wrote:
> 
>Hi Alex, sorry it can take a while for me to reply at the moment... some
>comments inline below...
> 
>On Sun, May 26, 2019 at 11:10 AM Alex Harui 
>wrote:
> 
>> Hi Greg,
>> 
>> Thanks for working through all of this.  Better Vector handling is
>> definitely a good thing for Royale.
>> 
> 
>I also believe so. In terms of my motivation for doing this work... I
>actually have no imminent need for Vector, but I wanted to do something
>concrete which I think is essential for 1.0.
>I do have my own libraries and past client work from that use Vector, so I
>see benefit in knowing that it will be easy to port to Royale and work
>without any issues if I need to do that at any point (hopefully I 

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

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.

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

Re: Language improvements

[Alex Harui]

Hi Greg,

I live outside of Seattle.  I'm in my house right now, and my cellphone says I 
have a 4G connection.  Many times a month, I take a ferry boat to Seattle.  
There is a point during the ride where the connectivity is poor.  Yesterday, I 
was trying to get work done on the ferry and was blocked from doing one step in 
the release automation because it would not load in time.  Many times, I'm 
trying to get one thing finished and get stymied by poor connectivity.  I hear 
this complaint from plenty of other residents where I live.  I want Royale to 
produce the app that loads when other apps don't.  Forcing everyone to take on 
another 2000+ bytes is not going to help.

The argument of "it is only another 1K" is what eventually caused UIComponent 
to grow to 13,000 lines and 128K Hello World.  That's history.  I do not want 
to repeat it.

I still haven't had time to look at your changes or read and respond to all of 
the words you've written.  Mostly for others who haven't been following the 
discussion, my reasoning is as follows:

-Vector and XML and any other built-in for SWF that isn't in JS are not free.  
We have to write some amount of code to get them to work.  
-Vector provides runtime type checking.  Not everybody needs runtime type 
checking in production.  
-Vector provides length checking.  Not everybody needs length checking in 
production.  
-We've already proven that by having at least two projects get into production 
without your implementation of Vector.  
-The current compiler output for Vector for folks who don't need runtime 
checking just uses Array.
-Your implementation adds 2990 bytes.

For sure, we need an implementation that does runtime type-checking and length 
checking.  So, as long as folks can choose to save the 2990 bytes and just use 
the current compiler output for Array in production, then we have given folks 
the right choices.  Bonus if we can let folks choose other Vector 
implementations just like they can choose other XML implementations.  My 
understanding from the words you've written is that you want everyone to use 
your Vector implementation and have options on what code paths that 
implementation actually takes, but I don't understand why from a technical 
perspective.

In fact, I was reading up on Javascript TypedArrays (because that did load 
while on the ferry) and it looks like some folks might want Vector. to map 
to the appropriate TypedArray.  It actually got me wondering if folks should be 
able to dictate how any particular instance of a Vector "optimizes".

In sum, the download size still matters.  I see it quite frequently.  
Technically, why shouldn't folks have a choice of implementations?

-Alex

On 5/27/19, 2:46 AM, "Greg Dove"  wrote:

Hi Alex, sorry it can take a while for me to reply at the moment... some
comments inline below...

On Sun, May 26, 2019 at 11:10 AM Alex Harui 
wrote:

> Hi Greg,
>
> Thanks for working through all of this.  Better Vector handling is
> definitely a good thing for Royale.
>

I also believe so. In terms of my motivation for doing this work... I
actually have no imminent need for Vector, but I wanted to do something
concrete which I think is essential for 1.0.
I do have my own libraries and past client work from that use Vector, so I
see benefit in knowing that it will be easy to port to Royale and work
without any issues if I need to do that at any point (hopefully I will). I
also got to see how Vector was treated differently/specially when working
on AMF, and realized that we had no way to support it there correctly
because it is 'special' also in amf, so that was another motivation (again,
not for anything I actually need at the moment for myself or anyone else,
but because it is something else that is lacking for 1.0).

However, IMO, PAYG is more important and 3KB can be a full second or more
> on busy/slow/poor networks.  As such, folks need to have choices.  So as
> long as folks can choose Vector implementations we should be good.
>
> A couple of things here. Firstly, I really did not think I would need to
be this specific... but iirc it was actually 2990 bytes.
My first reaction to your scenario above would be: that network connection
speed is really *unusable* for anything on today's internet... and that is
a problem that should be addressed first, otherwise it does not matter
which development tech you plan to use, it will be a common problem,
royale, react... whatever.
I can't recall something from my last 10 years where 3KB would be
considered a driving force for an intervention that would (presumably) only
save a portion of that (and introduce future potential maintainability
risks). 3KB was less than a second on dialup over 20 years ago. Things have
changed dramatically in the last 5 years in particular. We are in a HD
streaming 

Re: New article on how to create a desktop app with Apache Royale and ElectronJS

[Antonis Kalodimos]

Yes i didn't send you the whole file i was the end part only
The whole part is from this page
https://royale.codeoscopic.com/how-to-create-a-desktop-application-with-royale-and-electron/
 the same as in this page the HelloWorld.mxml and above
thetag im inserted the script showed in the same page.

The first error i found during truing to compile is from this line showed
in the example

http://ns.adobe.com/mxml/2009;

after the build task know with  apache-royale-0.9.4-bin-js  usedfor
building i am receiving this in log  shoewd in terminal vscode window

last lines
using source file:
c:\Works\NodeWorks\myElectron02\bin\js-debug\HelloWorld.js
The project 'HelloWorld' has been successfully compiled and optimized.
Error: File not found: org.apache.royale.events.utils.MouseEventConverter

90.8037847 seconds
The terminal process terminated with exit code: 3

Terminal will be reused by tasks, press any key to close it.


Στις Δευ, 27 Μαΐ 2019 στις 9:08 μ.μ., ο/η Harbs 
έγραψε:

> The XML is likely not well formed.
>
> Is the opening tag  or  ?
>
> > On May 27, 2019, at 8:47 PM, Antonis Kalodimos <
> antonis.kalodi...@gmail.com> wrote:
> >
> > Yes i had this tag
> > .
> > .
> > .
> >
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > I found that i was trying to compile it with
> apache-royale-0.9.6-bin-js-swf
> > when i changed that with apache-royale-0.9.4-bin-js
> > problem resolved but nothing showed (with apache-royale-0.9.6-bin-js-swf
> > the button and the text was showed.)
> >
> >
> >
> > Στις Δευ, 27 Μαΐ 2019 στις 8:39 μ.μ., ο/η Carlos Rovira <
> > carlosrov...@apache.org> έγραψε:
> >
> >> Hi Antonis,
> >>
> >> are you adding it in the HelloWorld.mxml file
> >> before ?
> >> The error seems like you are trying to add it in other part of the file
> or
> >> in other different file.
> >>
> >> Thanks
> >>
> >>
> >>
> >> El lun., 27 may. 2019 a las 18:21, Antonis Kalodimos (<
> >> antonis.kalodi...@gmail.com>) escribió:
> >>
> >>> Trying to folow this tutorial have these compile errors after putting
> the
> >>>  tag
> >>> col: 1 Error: This tag is unexpected. It will be ignored.
> >>>
> >>> 
> >>> ^
> >>>
> >>> My code is the same as in the tutorial and it worked as expected until
> >> the
> >>> step i n which fx:script tag need to be added
> >>>
> >>>
> >>>
> >>> Στις Δευ, 27 Μαΐ 2019 στις 6:39 μ.μ., ο/η Carlos Rovira <
> >>> carlosrov...@apache.org> έγραψε:
> >>>
>  Hi,
> 
>  new arcticle from Judah Frangipane is up!
> 
>  https://twitter.com/ApacheRoyale/status/1133025119075479552
> 
>  don't forget to share the new tweet please! :)
> 
>  and enjoy!!
> 
>  --
>  Carlos Rovira
>  http://about.me/carlosrovira
> 
> >>>
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
>
>

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.

Re: New article on how to create a desktop app with Apache Royale and ElectronJS

[Harbs]

The XML is likely not well formed.

Is the opening tag  or  ?

> On May 27, 2019, at 8:47 PM, Antonis Kalodimos  
> wrote:
> 
> Yes i had this tag
> .
> .
> .
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I found that i was trying to compile it with apache-royale-0.9.6-bin-js-swf
> when i changed that with apache-royale-0.9.4-bin-js
> problem resolved but nothing showed (with apache-royale-0.9.6-bin-js-swf
> the button and the text was showed.)
> 
> 
> 
> Στις Δευ, 27 Μαΐ 2019 στις 8:39 μ.μ., ο/η Carlos Rovira <
> carlosrov...@apache.org> έγραψε:
> 
>> Hi Antonis,
>> 
>> are you adding it in the HelloWorld.mxml file
>> before ?
>> The error seems like you are trying to add it in other part of the file or
>> in other different file.
>> 
>> Thanks
>> 
>> 
>> 
>> El lun., 27 may. 2019 a las 18:21, Antonis Kalodimos (<
>> antonis.kalodi...@gmail.com>) escribió:
>> 
>>> Trying to folow this tutorial have these compile errors after putting the
>>>  tag
>>> col: 1 Error: This tag is unexpected. It will be ignored.
>>> 
>>> 
>>> ^
>>> 
>>> My code is the same as in the tutorial and it worked as expected until
>> the
>>> step i n which fx:script tag need to be added
>>> 
>>> 
>>> 
>>> Στις Δευ, 27 Μαΐ 2019 στις 6:39 μ.μ., ο/η Carlos Rovira <
>>> carlosrov...@apache.org> έγραψε:
>>> 
 Hi,
 
 new arcticle from Judah Frangipane is up!
 
 https://twitter.com/ApacheRoyale/status/1133025119075479552
 
 don't forget to share the new tweet please! :)
 
 and enjoy!!
 
 --
 Carlos Rovira
 http://about.me/carlosrovira
 
>>> 
>> 
>> 
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>> 

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.

Re: New article on how to create a desktop app with Apache Royale and ElectronJS

[Antonis Kalodimos]

Yes i had this tag
.
.
.










I found that i was trying to compile it with apache-royale-0.9.6-bin-js-swf
when i changed that with apache-royale-0.9.4-bin-js
problem resolved but nothing showed (with apache-royale-0.9.6-bin-js-swf
the button and the text was showed.)



Στις Δευ, 27 Μαΐ 2019 στις 8:39 μ.μ., ο/η Carlos Rovira <
carlosrov...@apache.org> έγραψε:

> Hi Antonis,
>
> are you adding it in the HelloWorld.mxml file
> before ?
> The error seems like you are trying to add it in other part of the file or
> in other different file.
>
> Thanks
>
>
>
> El lun., 27 may. 2019 a las 18:21, Antonis Kalodimos (<
> antonis.kalodi...@gmail.com>) escribió:
>
> > Trying to folow this tutorial have these compile errors after putting the
> >  tag
> > col: 1 Error: This tag is unexpected. It will be ignored.
> >
> > 
> > ^
> >
> > My code is the same as in the tutorial and it worked as expected until
> the
> > step i n which fx:script tag need to be added
> >
> >
> >
> > Στις Δευ, 27 Μαΐ 2019 στις 6:39 μ.μ., ο/η Carlos Rovira <
> > carlosrov...@apache.org> έγραψε:
> >
> > > Hi,
> > >
> > > new arcticle from Judah Frangipane is up!
> > >
> > > https://twitter.com/ApacheRoyale/status/1133025119075479552
> > >
> > > don't forget to share the new tweet please! :)
> > >
> > > and enjoy!!
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Re: New article on how to create a desktop app with Apache Royale and ElectronJS

[Carlos Rovira]

Hi Antonis,

are you adding it in the HelloWorld.mxml file
before ?
The error seems like you are trying to add it in other part of the file or
in other different file.

Thanks



El lun., 27 may. 2019 a las 18:21, Antonis Kalodimos (<
antonis.kalodi...@gmail.com>) escribió:

> Trying to folow this tutorial have these compile errors after putting the
>  tag
> col: 1 Error: This tag is unexpected. It will be ignored.
>
> 
> ^
>
> My code is the same as in the tutorial and it worked as expected until the
> step i n which fx:script tag need to be added
>
>
>
> Στις Δευ, 27 Μαΐ 2019 στις 6:39 μ.μ., ο/η Carlos Rovira <
> carlosrov...@apache.org> έγραψε:
>
> > Hi,
> >
> > new arcticle from Judah Frangipane is up!
> >
> > https://twitter.com/ApacheRoyale/status/1133025119075479552
> >
> > don't forget to share the new tweet please! :)
> >
> > and enjoy!!
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>


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

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.

Re: New article on how to create a desktop app with Apache Royale and ElectronJS

[Antonis Kalodimos]

Trying to folow this tutorial have these compile errors after putting the
 tag
col: 1 Error: This tag is unexpected. It will be ignored.


^

My code is the same as in the tutorial and it worked as expected until the
step i n which fx:script tag need to be added



Στις Δευ, 27 Μαΐ 2019 στις 6:39 μ.μ., ο/η Carlos Rovira <
carlosrov...@apache.org> έγραψε:

> Hi,
>
> new arcticle from Judah Frangipane is up!
>
> https://twitter.com/ApacheRoyale/status/1133025119075479552
>
> don't forget to share the new tweet please! :)
>
> and enjoy!!
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

New article on how to create a desktop app with Apache Royale and ElectronJS

[Carlos Rovira]

Hi,

new arcticle from Judah Frangipane is up!

https://twitter.com/ApacheRoyale/status/1133025119075479552

don't forget to share the new tweet please! :)

and enjoy!!

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

Build failed in Jenkins: royale-asjs_MXTests #817

[Apache Royale CI Server]

See 


--
[...truncated 2.11 MB...]
[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

Re: Post on how to create a desktop app with Apache Royale

[Carlos Rovira]

Hi!

Thanks to Judah for making the effort of trying Royale with Electron and
making this great tutorial.
I'll be publishing in next hours r.a.o as soon as I have some time to do
the process.

Thanks!

Carlos

El lun., 27 may. 2019 a las 0:16, Harbs () escribió:

> Wow.
>
> Jude that’s really nice! Thanks for the effort putting that together!
>
> Harbs
>
> > On May 27, 2019, at 12:34 AM, QA  wrote:
> >
> > Hi guys,
> >
> > I've compiled a guide for creating a desktop app with Electron and
> Apache Royale on the blog here <
> https://royale.codeoscopic.com/how-to-create-a-desktop-application-with-royale-and-electron/>.
> Please check it out and let me or Carlos know of any improvements or typos.
> Also, if there's anything else you'd like to see along these lines let me
> know. I've left out a few sections so there might be a part two. Thanks to
> everyone working on Apache Royale :)
> >
> > Jude
> >
>
>

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

Build failed in Jenkins: royale-asjs_MXTests #816

[Apache Royale CI Server]

See 


Changes:

[yishayjobs] Align combo view with its popup

--
[...truncated 2.09 MB...]
[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

Release Step 002a Succeeded

[Apache Royale CI Server]

Continue on to Release Step 003

Re: Language improvements

[Greg Dove]

Hi Alex, sorry it can take a while for me to reply at the moment... some
comments inline below...

On Sun, May 26, 2019 at 11:10 AM Alex Harui 
wrote:

> Hi Greg,
>
> Thanks for working through all of this.  Better Vector handling is
> definitely a good thing for Royale.
>

I also believe so. In terms of my motivation for doing this work... I
actually have no imminent need for Vector, but I wanted to do something
concrete which I think is essential for 1.0.
I do have my own libraries and past client work from that use Vector, so I
see benefit in knowing that it will be easy to port to Royale and work
without any issues if I need to do that at any point (hopefully I will). I
also got to see how Vector was treated differently/specially when working
on AMF, and realized that we had no way to support it there correctly
because it is 'special' also in amf, so that was another motivation (again,
not for anything I actually need at the moment for myself or anyone else,
but because it is something else that is lacking for 1.0).

However, IMO, PAYG is more important and 3KB can be a full second or more
> on busy/slow/poor networks.  As such, folks need to have choices.  So as
> long as folks can choose Vector implementations we should be good.
>
> A couple of things here. Firstly, I really did not think I would need to
be this specific... but iirc it was actually 2990 bytes.
My first reaction to your scenario above would be: that network connection
speed is really *unusable* for anything on today's internet... and that is
a problem that should be addressed first, otherwise it does not matter
which development tech you plan to use, it will be a common problem,
royale, react... whatever.
I can't recall something from my last 10 years where 3KB would be
considered a driving force for an intervention that would (presumably) only
save a portion of that (and introduce future potential maintainability
risks). 3KB was less than a second on dialup over 20 years ago. Things have
changed dramatically in the last 5 years in particular. We are in a HD
streaming world now, with many countries supporting 4K streaming connection
speeds. And average speeds continue to grow globally at solid rates
year-on-year. 4G has impressive global coverage, and 5G is on the horizon.
I did mention this generally my earlier comments about bandwidth growth
outpacing growth in the size of apps. With your example are you
hypothesizing or do you have a real recent example in mind where this type
of thing was happening? If I was asked to classify the likelihood of the
scenario you described I would describe it as a few standard deviations
away from the center of the bell curve based on my own experience.

However I absolutely do agree with you that choice is important, I just
believe that performance most often will be more of a reason for the
decision to choose alternates (and it may mean adding 'size', not reducing
it).
And I think the choice should be explicit/obvious rather than having
something that is a lesser implementation of what it is actually supposed
to be. By this, I mean more application framework alternatives, instead of
supporting variations that represent non-conforming language classes. If
that approach is used, I think it will result in clearer, better quality,
more maintainable code. This is also a general approachI have observed
elsewhere.

Choosing Array is always an option in javascript and provides a zero
byte-weight option. I also plan to introduce some options for the numeric
types that represent best performance across both targets... but not as
'Vector' numeric types. The aim here would be to get faster than 'Vector as
Array' in javascript and it will be just a convenience approach to avoid
writing your own COMPILE::JS blocks with the native TypedArrays.

In terms of tweaking this Vector implementation's performance as further
options, I already explained I am happy to work on that based on actual
feedback for need. But I still think it requires caution and consideration
in terms of potential risks for people releasing libraries that could
expose non-conforming instances of Vectors (something that can never happen
in swf).
There are perhaps some possibilities for enhancing [ArrayElementType] with
a compiletime=true argument to get something more like what Harbs is after,
but that would only work for class members, not local vars. Perhaps there
are other simple ways to add 'compiletime' safety without going to full
blown generics support yet.


> Flex failed in some major vendors' customer-facing apps because of
> download times.  I have spent the past years trying to make sure Royale
> does not repeat those mistakes.
>
>
I do want you to understand that I'm on the same team. And like you, I
don't want to repeat old mistakes too. But I also would like to see us
avoid possible new ones.
In the last 5 years or so, I have never really had a client spend much time
focusing on the size. Before that I think I was more aware of 

Re: Language improvements

[Greg Dove]

Harbs, thanks for your interest.

I'd echo Carlos' comments about there being more details in the earlier
stuff. I know its long, but parts of it are an information dump of
learnings, and other parts are why I did things the way I did.

Some other quick comments:

"The goal of these changes are to enforce *runtime* Vector type safety? As
far as I understood, *compile time* safety was already being enforced."

Yes. But compiletime safety is only available on parts of the Vector api
because of the method signatures, in fact the as3 docs specify this
explicitly for some methods. Those methods (like push for example) only
have runtime safety.

If you use index level assignments you should get compile time safety for
complex types.
And because Josh added primitive type coercions that part is good if you
assign a string value to an int Vector for example.
This branch also has support for implicit complex type coercions as well -
which is not specific to Vectors -  but which will in javascript throw an
error just like in flash if there is something wrong. (easily switchable
off, and is off in the framework projects)

And of course you also have things like IDE driven completion for pop()
method etc

"You say there shouldn’t be runtime performance hits? How did you manage
that?"

It is still an Array, but just one that is 'enhanced', so whereever
possible it can still fall back to native speed.
Construction will be slower than array, but I don't expect it will be much
different to construction of a regular class. And I think most Vector code
is about loops and content rather than making lots of Vectors.

They following should be able to work at 100% speed or very close to it:

pop()
shift()
index access
index assignment (with @suppressvectorindexcheck

Most other methods will be slower, but they do now have conforming runtime
type safety. This includes Vector-of-Vector types etc.

"Is this going to be a compiler option? Most of my use of Vector in Flash
was to speed up arrays. Second to that was compile time type safety.
Runtime type safety was much less important to me"

Outputting as Array was a non-implementation/placeholder. If we get
comfortable with a non-implementation then I think that is a reluctance to
do the right thing.
The problem with it is that it is not what the actionscript language
specifies, but the compiler always thinks it is. If someone released
library code which had some Array only implementation, it would still say
it was a Vector in terms of type but it would not behave like one if passed
around to other parts of code that may want to use it. And as/is type
checks are all messed up.
However I do want to work on a separate cross-target solution which focuses
on the fastest implementations for the 3 numeric types which is where the
Vector speed up is in flash - and is also how and why I mostly used them in
flash too.
My intention with that will be essentially expose the functionality of
javascript TypeArrays to both targets via a common class, and this
therefore ought to be faster than 'Array' in javascript too (I fully expect
it to be, but I have not specifically tested it).  And no, it would not use
getItemAt/setItemAt - if I can implement how I plan to, it would be regular
full speed index access. I think I can work with that approach for high
speed numeric collections - do you think that would meet most of your own
needs if it only worked with pre-allocated sizes and only via index access?
(i.e. no push/pop etc) - essentially like the fastest flash Vector
configuration, a fixed=true Vector ? I think making it more Vector like in
terms of api would be possible, but it will be heavier and also slower
(because fixed length is the faster configuration).


"Personally, I’d like to be able to use `int[]` and `MyFoo[]` for typed
arrays instead of Vectors for the vast majority of my Vector uses."

I am not proposing new syntax or anything like that. I think that is
something for the future :)









On Sun, May 26, 2019 at 10:53 PM Carlos Rovira 
wrote:

> Hi Harbs,
>
> for performance explanation I think there's all explained in his long email
> in this thread.
> I think you should read that since there's many info, included new compiler
> options and more.
> It takes a bit of time, but I think it's worth it.
>
> thanks
>
> El dom., 26 may. 2019 a las 12:47, Harbs ()
> escribió:
>
> > Let me know if I understand correctly.
> >
> > The goal of these changes are to enforce *runtime* Vector type safety? As
> > far as I understood, *compile time* safety was already being enforced.
> >
> > You say there shouldn’t be runtime performance hits? How did you manage
> > that?
> >
> > Is this going to be a compiler option? Most of my use of Vector in Flash
> > was to speed up arrays. Second to that was compile time type safety.
> > Runtime type safety was much less important to me.
> >
> > Personally, I’d like to be able to use `int[]` and `MyFoo[]` for typed
> > arrays instead of Vectors for the vast 

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.

Build failed in Jenkins: royale-asjs_MXTests #815

[Apache Royale CI Server]

See 


Changes:

[yishayjobs] Make color in color picker bindable and save strand for popup.

[harbs] For scrolling the content area should always be 100%

--
[...truncated 2.09 MB...]
[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: