Build failed in Jenkins: royale-asjs_MXTests #814

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

Release Step 001a Succeeded

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

Build failed in Jenkins: royale-asjs_MXTests #813

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

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.

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

[Apache Royale CI Server]

See 

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

[Harbs]

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

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

[Alex Harui]

Sweet!  Thanks!

-Alex

On 5/26/19, 2:34 PM, "QA"  wrote:

Hi guys,

I've compiled a guide for creating a desktop app with Electron and 
Apache Royale on the blog here 

.
 
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

Post on how to create a desktop app with Apache Royale

[QA]

Hi guys,

I've compiled a guide for creating a desktop app with Electron and 
Apache Royale on the blog here 
. 
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

Re: SourceMaps in SWCs

[Carlos Rovira]

Hi Alex,

ok, this is something we can look into it later. Is more important to get
release process success without this

thanks!

El dom., 26 may. 2019 a las 21:04, Alex Harui ()
escribió:

> In my testing, sourcemaps built on other machines do not work on my local
> machine, so I am going to skip generating them in our release artifacts.
>
> -Alex
>
> On 5/26/19, 10:03 AM, "Alex Harui"  wrote:
>
> I’m trying to understand whether SourceMaps built on another computer
> actually work or not because the sourceRoot entry is different on each
> machine.  This is a problem for the release automation because we'd like
> the SWCs to binary match regardless of which machine a SWC is built on.
> Some possibilities:
>
> 1) They don't work if the sourceRoot does not match your file system.
> 2) The browser will ask for a valid sourceRoot if the one supplied is
> invalid
> 3) We should be hosting sourcemaps on a server.
>
> In searching the internet, it appears that sourceRoot is optional and
> can be null, so I might try that first, but other articles are about
> incorrect sourceRoot paths.  Yet other articles mention using URLs instead
> of local relative paths.
>
> So, it could turn out that sourcemaps in SWCs are only useful when you
> build from sources on your machine so all of the paths are correct.  If
> that's true, then when building release artifacts I'm going to turn off
> source map generation.  If sourceRoot can be null, then we will add
> sourcemaps to the Ant build.  Separately, if someone wants to take on using
> URLs and figuring out a scheme for us to host them, that's fine as well.
>
> I was hoping someone had already tried it and knew the answer, but
> apparently I will have to take the time to do the investigation myself.
>
> Thanks,
> -Alex
>
> On 5/26/19, 7:04 AM, "Piotr Zarzycki" 
> wrote:
>
> Carlos,
>
> Alex in his original email is saying: "it appears that the
> Maven build
> puts source maps in the SWC for every JS file but the Ant build
> does not."
> - How are you understand that ?
>
> niedz., 26 maj 2019 o 15:50 Carlos Rovira  >
> napisał(a):
>
> > Hi Piotr,
> >
> > don't understand what you say.
> > *.js files has a separate *.map.js
> > but IDES use to folder this file as part of the .js
> >
> > El dom., 26 may. 2019 a las 14:07, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>) escribió:
> >
> > > Now you confuses me - I understand that both build system
> produce source
> > > map. However in case of Maven source map is not an separate
> file, but it
> > is
> > > part of SWC. - Do you understand it the same ?
> > >
> > > On Sun, May 26, 2019, 1:42 PM Carlos Rovira <
> carlosrov...@apache.org>
> > > wrote:
> > >
> > > > Right, I think Alex found that source maps are on maven but
> not in ant
> > > and
> > > > just was asking if add to ant or not. But don't think is
> blocking him
> > > >
> > > > El dom., 26 may. 2019 a las 13:17, Piotr Zarzycki (<
> > > > piotrzarzyck...@gmail.com>) escribió:
> > > >
> > > > > If there is no difference for IDE where source map is
> placed - Let's
> > do
> > > > > what is easier to do. It seems to be not a high priority
> stuff -
> > unless
> > > > it
> > > > > is blocking Alex from moving forward.
> > > > >
> > > > > On Sun, May 26, 2019, 12:11 PM Carlos Rovira <
> > carlosrov...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi Piotr,
> > > > > >
> > > > > > yes, you can debug in IDE or Browser and reach to
> framework classes
> > > > what
> > > > > is
> > > > > > great and very convenient.
> > > > > > I think having both options would be best too, but as
> always
> > someone
> > > > > should
> > > > > > add the switcher to do that.
> > > > > > We always can do that at some time, but If there's no
> time at this
> > > > > moment,
> > > > > > I'll prefer source maps included by default and then
> > > > > > wait for someone that want to add the switch. IOW, I
> prefer it as
> > an
> > > > > > "opt-out", since asume users will want this by default.
> > > > > >
> > > > > > El dom., 26 may. 2019 a las 10:04, Piotr Zarzycki (<
> > > > > > piotrzarzyck...@gmail.com>) escribió:
> > > > > >
> > > > > > > Hi Carlos,
> > > > > > >
> > > > > > > When you build application by Maven - did you try it
> run by
> > VSCode
> > > -
> > > > > does
> > > > > > > debugging working with build in source map?
> > > > > > > I'm wondering how IDE would be influenced by having
> source 

Re: SourceMaps in SWCs

[Alex Harui]

In my testing, sourcemaps built on other machines do not work on my local 
machine, so I am going to skip generating them in our release artifacts.

-Alex

On 5/26/19, 10:03 AM, "Alex Harui"  wrote:

I’m trying to understand whether SourceMaps built on another computer 
actually work or not because the sourceRoot entry is different on each machine. 
 This is a problem for the release automation because we'd like the SWCs to 
binary match regardless of which machine a SWC is built on.  Some possibilities:

1) They don't work if the sourceRoot does not match your file system.
2) The browser will ask for a valid sourceRoot if the one supplied is 
invalid
3) We should be hosting sourcemaps on a server.

In searching the internet, it appears that sourceRoot is optional and can 
be null, so I might try that first, but other articles are about incorrect 
sourceRoot paths.  Yet other articles mention using URLs instead of local 
relative paths.

So, it could turn out that sourcemaps in SWCs are only useful when you 
build from sources on your machine so all of the paths are correct.  If that's 
true, then when building release artifacts I'm going to turn off source map 
generation.  If sourceRoot can be null, then we will add sourcemaps to the Ant 
build.  Separately, if someone wants to take on using URLs and figuring out a 
scheme for us to host them, that's fine as well.

I was hoping someone had already tried it and knew the answer, but 
apparently I will have to take the time to do the investigation myself.

Thanks,
-Alex

On 5/26/19, 7:04 AM, "Piotr Zarzycki"  wrote:

Carlos,

Alex in his original email is saying: "it appears that the Maven 
build
puts source maps in the SWC for every JS file but the Ant build does 
not."
- How are you understand that ?

niedz., 26 maj 2019 o 15:50 Carlos Rovira 
napisał(a):

> Hi Piotr,
>
> don't understand what you say.
> *.js files has a separate *.map.js
> but IDES use to folder this file as part of the .js
>
> El dom., 26 may. 2019 a las 14:07, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > Now you confuses me - I understand that both build system produce 
source
> > map. However in case of Maven source map is not an separate file, 
but it
> is
> > part of SWC. - Do you understand it the same ?
> >
> > On Sun, May 26, 2019, 1:42 PM Carlos Rovira 

> > wrote:
> >
> > > Right, I think Alex found that source maps are on maven but not 
in ant
> > and
> > > just was asking if add to ant or not. But don't think is blocking 
him
> > >
> > > El dom., 26 may. 2019 a las 13:17, Piotr Zarzycki (<
> > > piotrzarzyck...@gmail.com>) escribió:
> > >
> > > > If there is no difference for IDE where source map is placed - 
Let's
> do
> > > > what is easier to do. It seems to be not a high priority stuff -
> unless
> > > it
> > > > is blocking Alex from moving forward.
> > > >
> > > > On Sun, May 26, 2019, 12:11 PM Carlos Rovira <
> carlosrov...@apache.org>
> > > > wrote:
> > > >
> > > > > Hi Piotr,
> > > > >
> > > > > yes, you can debug in IDE or Browser and reach to framework 
classes
> > > what
> > > > is
> > > > > great and very convenient.
> > > > > I think having both options would be best too, but as always
> someone
> > > > should
> > > > > add the switcher to do that.
> > > > > We always can do that at some time, but If there's no time at 
this
> > > > moment,
> > > > > I'll prefer source maps included by default and then
> > > > > wait for someone that want to add the switch. IOW, I prefer 
it as
> an
> > > > > "opt-out", since asume users will want this by default.
> > > > >
> > > > > El dom., 26 may. 2019 a las 10:04, Piotr Zarzycki (<
> > > > > piotrzarzyck...@gmail.com>) escribió:
> > > > >
> > > > > > Hi Carlos,
> > > > > >
> > > > > > When you build application by Maven - did you try it run by
> VSCode
> > -
> > > > does
> > > > > > debugging working with build in source map?
> > > > > > I'm wondering how IDE would be influenced by having source 
map
> > in/out
> > > > of
> > > > > > SWC.
> > > > > >
> > > > > > I think having both possibilities would be the best.
> > > > > >
> > > > > > Thanks,
> > > > > > Piotr
> > > > > >
> > > > > > On Sun, May 26, 2019, 8:26 AM Carlos Rovira <
> > carlosrov...@apache.org
> > > >

Re: SourceMaps in SWCs

[Alex Harui]

I’m trying to understand whether SourceMaps built on another computer actually 
work or not because the sourceRoot entry is different on each machine.  This is 
a problem for the release automation because we'd like the SWCs to binary match 
regardless of which machine a SWC is built on.  Some possibilities:

1) They don't work if the sourceRoot does not match your file system.
2) The browser will ask for a valid sourceRoot if the one supplied is invalid
3) We should be hosting sourcemaps on a server.

In searching the internet, it appears that sourceRoot is optional and can be 
null, so I might try that first, but other articles are about incorrect 
sourceRoot paths.  Yet other articles mention using URLs instead of local 
relative paths.

So, it could turn out that sourcemaps in SWCs are only useful when you build 
from sources on your machine so all of the paths are correct.  If that's true, 
then when building release artifacts I'm going to turn off source map 
generation.  If sourceRoot can be null, then we will add sourcemaps to the Ant 
build.  Separately, if someone wants to take on using URLs and figuring out a 
scheme for us to host them, that's fine as well.

I was hoping someone had already tried it and knew the answer, but apparently I 
will have to take the time to do the investigation myself.

Thanks,
-Alex

On 5/26/19, 7:04 AM, "Piotr Zarzycki"  wrote:

Carlos,

Alex in his original email is saying: "it appears that the Maven build
puts source maps in the SWC for every JS file but the Ant build does not."
- How are you understand that ?

niedz., 26 maj 2019 o 15:50 Carlos Rovira 
napisał(a):

> Hi Piotr,
>
> don't understand what you say.
> *.js files has a separate *.map.js
> but IDES use to folder this file as part of the .js
>
> El dom., 26 may. 2019 a las 14:07, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > Now you confuses me - I understand that both build system produce source
> > map. However in case of Maven source map is not an separate file, but it
> is
> > part of SWC. - Do you understand it the same ?
> >
> > On Sun, May 26, 2019, 1:42 PM Carlos Rovira 
> > wrote:
> >
> > > Right, I think Alex found that source maps are on maven but not in ant
> > and
> > > just was asking if add to ant or not. But don't think is blocking him
> > >
> > > El dom., 26 may. 2019 a las 13:17, Piotr Zarzycki (<
> > > piotrzarzyck...@gmail.com>) escribió:
> > >
> > > > If there is no difference for IDE where source map is placed - Let's
> do
> > > > what is easier to do. It seems to be not a high priority stuff -
> unless
> > > it
> > > > is blocking Alex from moving forward.
> > > >
> > > > On Sun, May 26, 2019, 12:11 PM Carlos Rovira <
> carlosrov...@apache.org>
> > > > wrote:
> > > >
> > > > > Hi Piotr,
> > > > >
> > > > > yes, you can debug in IDE or Browser and reach to framework 
classes
> > > what
> > > > is
> > > > > great and very convenient.
> > > > > I think having both options would be best too, but as always
> someone
> > > > should
> > > > > add the switcher to do that.
> > > > > We always can do that at some time, but If there's no time at this
> > > > moment,
> > > > > I'll prefer source maps included by default and then
> > > > > wait for someone that want to add the switch. IOW, I prefer it as
> an
> > > > > "opt-out", since asume users will want this by default.
> > > > >
> > > > > El dom., 26 may. 2019 a las 10:04, Piotr Zarzycki (<
> > > > > piotrzarzyck...@gmail.com>) escribió:
> > > > >
> > > > > > Hi Carlos,
> > > > > >
> > > > > > When you build application by Maven - did you try it run by
> VSCode
> > -
> > > > does
> > > > > > debugging working with build in source map?
> > > > > > I'm wondering how IDE would be influenced by having source map
> > in/out
> > > > of
> > > > > > SWC.
> > > > > >
> > > > > > I think having both possibilities would be the best.
> > > > > >
> > > > > > Thanks,
> > > > > > Piotr
> > > > > >
> > > > > > On Sun, May 26, 2019, 8:26 AM Carlos Rovira <
> > carlosrov...@apache.org
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > my opinion on this is that users'll want the capability to
> debug
> > > > > > framework
> > > > > > > code by default and will prefer that to save bandwidth.
> > > > > > > sourceMaps is other thing that differentiate Royale over many
> JS
> > > > basic
> > > > > > > libraries that does not have this built in and put us with the
> > > group
> > > > > that
> > > > > > > have it, so more in the group of "structured programing with
> > > > debugging
> > > > > > > 

Re: system requirements for Royale

[Carlos Rovira]

Hi,

I think java 8 is now required or minimum need is 7? [1]

I know that maven required java 8 for sure due to SASS plugin generator, so
I think we should put 8 instead of 7

[1]
https://apache.github.io/royale-docs/get-started/system-requirements.html

El mar., 30 ene. 2018 a las 18:50, Alex Harui ()
escribió:

>
>
> On 1/30/18, 9:21 AM, "Andrew Wetmore"  wrote:
>
> >I went through a period when my IDE kept complaining that it could not
> >find
> >the JDK when I wanted to work with Apache Flex. I don't have a clean
> >machine on which I can install just Apache Royale and see what happens.
>
> Maybe we say JRE and wait for a bug report.
>
> >As for Unix, perhaps we just don't mention it for now??
>
> I think it is mentioned in source package README as not tested on Linux
> and no mention of Unix.
>
> HTH,
> -Alex
> >
> >On Tue, Jan 30, 2018 at 6:37 AM, Carlos Rovira 
> >wrote:
> >
> >> Hi,
> >>
> >> someone with the time and a clean virtual machine could test this to
> >>see if
> >> is or not needed
> >> thanks Andrew for pointing this
> >>
> >>
> >>
> >> 2018-01-30 7:06 GMT+01:00 Alex Harui :
> >>
> >> > Good questions.  I don't know for sure about the JDK.  Do you have a
> >>JDK
> >> > or just a JRE?  If you just have a JRE, does Royale compile your code?
> >> > I've always had JDKs on my system so it would be better if someone who
> >> > never had a JDK on their system tried it.
> >> >
> >> > I checked the Adobe docs and don't see any requirement for a JDK.  I
> >>have
> >> > seen a few Java apps require a JDK.  I doubt we require it though.
> >> >
> >> > Regarding Unix/Linux, I don't think anybody has done serious testing.
> >> >
> >> > Regarding minimum Mac or PC requirements, I think the Java 1.7
> >> requirement
> >> > will set the baseline.
> >> >
> >> > HTH,
> >> > -Alex
> >> >
> >> > On 1/29/18, 10:47 AM, "Andrew Wetmore"  wrote:
> >> >
> >> > >In the README I, um, read:
> >> > >
> >> > >Royale requires Java SDK 1.7 or greater to be installed on your
> >> computer.
> >> > >
> >> > >Is that true even if you are using the compiled binaries and not
> >> building
> >> > >Royale?
> >> > >
> >> > >For the help docs, are there any other system requirements, if we are
> >> > >presuming a modern Mac or PC machine? Does Royale run on a Unix box?
> >> > >
> >> > >--
> >> > >Andrew Wetmore
> >> > >
> >> > >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fcottage14
> >> > .
> >> > >blogspot.com%2F=02%7C01%7Caharui%40adobe.com%
> >> > 7Cc20890d0159047cda40a08
> >> > >d56748cb1b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> > 7C636528484705179817
> >> > >=pse5cGtfbH0udKRo4%2Bor6HzJytL5b04hUuLBUclT8XU%3D=0
> >> >
> >> >
> >>
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
> >>2Fcarlosrovira=02%7C01%7Caharui%40adobe.com
> %7C5cbe418f1a964fb5317508
> >>d56805f283%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63652929711421905
> >>4=VpGvt50%2FYb2NsIwx210UzKvLp0gCk8ivTTCrigsyQZw%3D=0
> >>
> >
> >
> >
> >--
> >Andrew Wetmore
> >
> >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14
> .
> >blogspot.com%2F=02%7C01%7Caharui%40adobe.com
> %7C5cbe418f1a964fb5317508
> >d56805f283%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636529297114219054
> >=AXrIinNPQk0x8uWKNrfKoBh6UIOQq8hnaSRB%2F43YMuQ%3D=0
>
>

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

Re: SourceMaps in SWCs

[Piotr Zarzycki]

Carlos,

Alex in his original email is saying: "it appears that the Maven build
puts source maps in the SWC for every JS file but the Ant build does not."
- How are you understand that ?

niedz., 26 maj 2019 o 15:50 Carlos Rovira 
napisał(a):

> Hi Piotr,
>
> don't understand what you say.
> *.js files has a separate *.map.js
> but IDES use to folder this file as part of the .js
>
> El dom., 26 may. 2019 a las 14:07, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > Now you confuses me - I understand that both build system produce source
> > map. However in case of Maven source map is not an separate file, but it
> is
> > part of SWC. - Do you understand it the same ?
> >
> > On Sun, May 26, 2019, 1:42 PM Carlos Rovira 
> > wrote:
> >
> > > Right, I think Alex found that source maps are on maven but not in ant
> > and
> > > just was asking if add to ant or not. But don't think is blocking him
> > >
> > > El dom., 26 may. 2019 a las 13:17, Piotr Zarzycki (<
> > > piotrzarzyck...@gmail.com>) escribió:
> > >
> > > > If there is no difference for IDE where source map is placed - Let's
> do
> > > > what is easier to do. It seems to be not a high priority stuff -
> unless
> > > it
> > > > is blocking Alex from moving forward.
> > > >
> > > > On Sun, May 26, 2019, 12:11 PM Carlos Rovira <
> carlosrov...@apache.org>
> > > > wrote:
> > > >
> > > > > Hi Piotr,
> > > > >
> > > > > yes, you can debug in IDE or Browser and reach to framework classes
> > > what
> > > > is
> > > > > great and very convenient.
> > > > > I think having both options would be best too, but as always
> someone
> > > > should
> > > > > add the switcher to do that.
> > > > > We always can do that at some time, but If there's no time at this
> > > > moment,
> > > > > I'll prefer source maps included by default and then
> > > > > wait for someone that want to add the switch. IOW, I prefer it as
> an
> > > > > "opt-out", since asume users will want this by default.
> > > > >
> > > > > El dom., 26 may. 2019 a las 10:04, Piotr Zarzycki (<
> > > > > piotrzarzyck...@gmail.com>) escribió:
> > > > >
> > > > > > Hi Carlos,
> > > > > >
> > > > > > When you build application by Maven - did you try it run by
> VSCode
> > -
> > > > does
> > > > > > debugging working with build in source map?
> > > > > > I'm wondering how IDE would be influenced by having source map
> > in/out
> > > > of
> > > > > > SWC.
> > > > > >
> > > > > > I think having both possibilities would be the best.
> > > > > >
> > > > > > Thanks,
> > > > > > Piotr
> > > > > >
> > > > > > On Sun, May 26, 2019, 8:26 AM Carlos Rovira <
> > carlosrov...@apache.org
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > my opinion on this is that users'll want the capability to
> debug
> > > > > > framework
> > > > > > > code by default and will prefer that to save bandwidth.
> > > > > > > sourceMaps is other thing that differentiate Royale over many
> JS
> > > > basic
> > > > > > > libraries that does not have this built in and put us with the
> > > group
> > > > > that
> > > > > > > have it, so more in the group of "structured programing with
> > > > debugging
> > > > > > > capabilities".
> > > > > > > So I think ANT should have as well sourceMaps on by default.
> Then
> > > if
> > > > we
> > > > > > can
> > > > > > > have a switch for opt-out will be great, but maybe a bit of
> work
> > > for
> > > > > > > something that probably will be low priority right now, or we
> > could
> > > > > wait
> > > > > > to
> > > > > > > someone to ask for, fill an issue and then work on it.
> > > > > > > About sourceRoot not mapping to anything, can't say since I
> > thought
> > > > > that
> > > > > > > was not possible until now, so maybe others could respond to
> that
> > > > > > > thanks
> > > > > > >
> > > > > > > El dom., 26 may. 2019 a las 5:23, Alex Harui
> > > > ( > > > > > >)
> > > > > > > escribió:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > In working through the release automation, it appears that
> the
> > > > Maven
> > > > > > > build
> > > > > > > > puts source maps in the SWC for every JS file but the Ant
> build
> > > > does
> > > > > > not.
> > > > > > > > Should there be source maps in the SWCs?  How do they work
> when
> > > the
> > > > > > > > sourceRoot doesn't map to anything?  Or should that only be
> an
> > > > option
> > > > > > > when
> > > > > > > > building everything from sources on your machine?  It would
> > save
> > > a
> > > > > lot
> > > > > > in
> > > > > > > > terms of SWC size to not have source maps in the SWCs.
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > > -Alex
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Carlos Rovira
> > > > > > > http://about.me/carlosrovira
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Carlos Rovira
> > > > > http://about.me/carlosrovira
> > > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > 

Re: SourceMaps in SWCs

[Carlos Rovira]

Hi Piotr,

don't understand what you say.
*.js files has a separate *.map.js
but IDES use to folder this file as part of the .js

El dom., 26 may. 2019 a las 14:07, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Now you confuses me - I understand that both build system produce source
> map. However in case of Maven source map is not an separate file, but it is
> part of SWC. - Do you understand it the same ?
>
> On Sun, May 26, 2019, 1:42 PM Carlos Rovira 
> wrote:
>
> > Right, I think Alex found that source maps are on maven but not in ant
> and
> > just was asking if add to ant or not. But don't think is blocking him
> >
> > El dom., 26 may. 2019 a las 13:17, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>) escribió:
> >
> > > If there is no difference for IDE where source map is placed - Let's do
> > > what is easier to do. It seems to be not a high priority stuff - unless
> > it
> > > is blocking Alex from moving forward.
> > >
> > > On Sun, May 26, 2019, 12:11 PM Carlos Rovira 
> > > wrote:
> > >
> > > > Hi Piotr,
> > > >
> > > > yes, you can debug in IDE or Browser and reach to framework classes
> > what
> > > is
> > > > great and very convenient.
> > > > I think having both options would be best too, but as always someone
> > > should
> > > > add the switcher to do that.
> > > > We always can do that at some time, but If there's no time at this
> > > moment,
> > > > I'll prefer source maps included by default and then
> > > > wait for someone that want to add the switch. IOW, I prefer it as an
> > > > "opt-out", since asume users will want this by default.
> > > >
> > > > El dom., 26 may. 2019 a las 10:04, Piotr Zarzycki (<
> > > > piotrzarzyck...@gmail.com>) escribió:
> > > >
> > > > > Hi Carlos,
> > > > >
> > > > > When you build application by Maven - did you try it run by VSCode
> -
> > > does
> > > > > debugging working with build in source map?
> > > > > I'm wondering how IDE would be influenced by having source map
> in/out
> > > of
> > > > > SWC.
> > > > >
> > > > > I think having both possibilities would be the best.
> > > > >
> > > > > Thanks,
> > > > > Piotr
> > > > >
> > > > > On Sun, May 26, 2019, 8:26 AM Carlos Rovira <
> carlosrov...@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > my opinion on this is that users'll want the capability to debug
> > > > > framework
> > > > > > code by default and will prefer that to save bandwidth.
> > > > > > sourceMaps is other thing that differentiate Royale over many JS
> > > basic
> > > > > > libraries that does not have this built in and put us with the
> > group
> > > > that
> > > > > > have it, so more in the group of "structured programing with
> > > debugging
> > > > > > capabilities".
> > > > > > So I think ANT should have as well sourceMaps on by default. Then
> > if
> > > we
> > > > > can
> > > > > > have a switch for opt-out will be great, but maybe a bit of work
> > for
> > > > > > something that probably will be low priority right now, or we
> could
> > > > wait
> > > > > to
> > > > > > someone to ask for, fill an issue and then work on it.
> > > > > > About sourceRoot not mapping to anything, can't say since I
> thought
> > > > that
> > > > > > was not possible until now, so maybe others could respond to that
> > > > > > thanks
> > > > > >
> > > > > > El dom., 26 may. 2019 a las 5:23, Alex Harui
> > > ( > > > > >)
> > > > > > escribió:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > In working through the release automation, it appears that the
> > > Maven
> > > > > > build
> > > > > > > puts source maps in the SWC for every JS file but the Ant build
> > > does
> > > > > not.
> > > > > > > Should there be source maps in the SWCs?  How do they work when
> > the
> > > > > > > sourceRoot doesn't map to anything?  Or should that only be an
> > > option
> > > > > > when
> > > > > > > building everything from sources on your machine?  It would
> save
> > a
> > > > lot
> > > > > in
> > > > > > > terms of SWC size to not have source maps in the SWCs.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > > -Alex
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Carlos Rovira
> > > > > > http://about.me/carlosrovira
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>


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

Build failed in Jenkins: royale-asjs_MXTests #811

[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: SourceMaps in SWCs

[Piotr Zarzycki]

Now you confuses me - I understand that both build system produce source
map. However in case of Maven source map is not an separate file, but it is
part of SWC. - Do you understand it the same ?

On Sun, May 26, 2019, 1:42 PM Carlos Rovira  wrote:

> Right, I think Alex found that source maps are on maven but not in ant and
> just was asking if add to ant or not. But don't think is blocking him
>
> El dom., 26 may. 2019 a las 13:17, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > If there is no difference for IDE where source map is placed - Let's do
> > what is easier to do. It seems to be not a high priority stuff - unless
> it
> > is blocking Alex from moving forward.
> >
> > On Sun, May 26, 2019, 12:11 PM Carlos Rovira 
> > wrote:
> >
> > > Hi Piotr,
> > >
> > > yes, you can debug in IDE or Browser and reach to framework classes
> what
> > is
> > > great and very convenient.
> > > I think having both options would be best too, but as always someone
> > should
> > > add the switcher to do that.
> > > We always can do that at some time, but If there's no time at this
> > moment,
> > > I'll prefer source maps included by default and then
> > > wait for someone that want to add the switch. IOW, I prefer it as an
> > > "opt-out", since asume users will want this by default.
> > >
> > > El dom., 26 may. 2019 a las 10:04, Piotr Zarzycki (<
> > > piotrzarzyck...@gmail.com>) escribió:
> > >
> > > > Hi Carlos,
> > > >
> > > > When you build application by Maven - did you try it run by VSCode -
> > does
> > > > debugging working with build in source map?
> > > > I'm wondering how IDE would be influenced by having source map in/out
> > of
> > > > SWC.
> > > >
> > > > I think having both possibilities would be the best.
> > > >
> > > > Thanks,
> > > > Piotr
> > > >
> > > > On Sun, May 26, 2019, 8:26 AM Carlos Rovira  >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > my opinion on this is that users'll want the capability to debug
> > > > framework
> > > > > code by default and will prefer that to save bandwidth.
> > > > > sourceMaps is other thing that differentiate Royale over many JS
> > basic
> > > > > libraries that does not have this built in and put us with the
> group
> > > that
> > > > > have it, so more in the group of "structured programing with
> > debugging
> > > > > capabilities".
> > > > > So I think ANT should have as well sourceMaps on by default. Then
> if
> > we
> > > > can
> > > > > have a switch for opt-out will be great, but maybe a bit of work
> for
> > > > > something that probably will be low priority right now, or we could
> > > wait
> > > > to
> > > > > someone to ask for, fill an issue and then work on it.
> > > > > About sourceRoot not mapping to anything, can't say since I thought
> > > that
> > > > > was not possible until now, so maybe others could respond to that
> > > > > thanks
> > > > >
> > > > > El dom., 26 may. 2019 a las 5:23, Alex Harui
> > ( > > > >)
> > > > > escribió:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > In working through the release automation, it appears that the
> > Maven
> > > > > build
> > > > > > puts source maps in the SWC for every JS file but the Ant build
> > does
> > > > not.
> > > > > > Should there be source maps in the SWCs?  How do they work when
> the
> > > > > > sourceRoot doesn't map to anything?  Or should that only be an
> > option
> > > > > when
> > > > > > building everything from sources on your machine?  It would save
> a
> > > lot
> > > > in
> > > > > > terms of SWC size to not have source maps in the SWCs.
> > > > > >
> > > > > > Thoughts?
> > > > > > -Alex
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Carlos Rovira
> > > > > http://about.me/carlosrovira
> > > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Re: SourceMaps in SWCs

[Carlos Rovira]

Right, I think Alex found that source maps are on maven but not in ant and
just was asking if add to ant or not. But don't think is blocking him

El dom., 26 may. 2019 a las 13:17, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> If there is no difference for IDE where source map is placed - Let's do
> what is easier to do. It seems to be not a high priority stuff - unless it
> is blocking Alex from moving forward.
>
> On Sun, May 26, 2019, 12:11 PM Carlos Rovira 
> wrote:
>
> > Hi Piotr,
> >
> > yes, you can debug in IDE or Browser and reach to framework classes what
> is
> > great and very convenient.
> > I think having both options would be best too, but as always someone
> should
> > add the switcher to do that.
> > We always can do that at some time, but If there's no time at this
> moment,
> > I'll prefer source maps included by default and then
> > wait for someone that want to add the switch. IOW, I prefer it as an
> > "opt-out", since asume users will want this by default.
> >
> > El dom., 26 may. 2019 a las 10:04, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>) escribió:
> >
> > > Hi Carlos,
> > >
> > > When you build application by Maven - did you try it run by VSCode -
> does
> > > debugging working with build in source map?
> > > I'm wondering how IDE would be influenced by having source map in/out
> of
> > > SWC.
> > >
> > > I think having both possibilities would be the best.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > On Sun, May 26, 2019, 8:26 AM Carlos Rovira 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > my opinion on this is that users'll want the capability to debug
> > > framework
> > > > code by default and will prefer that to save bandwidth.
> > > > sourceMaps is other thing that differentiate Royale over many JS
> basic
> > > > libraries that does not have this built in and put us with the group
> > that
> > > > have it, so more in the group of "structured programing with
> debugging
> > > > capabilities".
> > > > So I think ANT should have as well sourceMaps on by default. Then if
> we
> > > can
> > > > have a switch for opt-out will be great, but maybe a bit of work for
> > > > something that probably will be low priority right now, or we could
> > wait
> > > to
> > > > someone to ask for, fill an issue and then work on it.
> > > > About sourceRoot not mapping to anything, can't say since I thought
> > that
> > > > was not possible until now, so maybe others could respond to that
> > > > thanks
> > > >
> > > > El dom., 26 may. 2019 a las 5:23, Alex Harui
> ( > > >)
> > > > escribió:
> > > >
> > > > > Hi,
> > > > >
> > > > > In working through the release automation, it appears that the
> Maven
> > > > build
> > > > > puts source maps in the SWC for every JS file but the Ant build
> does
> > > not.
> > > > > Should there be source maps in the SWCs?  How do they work when the
> > > > > sourceRoot doesn't map to anything?  Or should that only be an
> option
> > > > when
> > > > > building everything from sources on your machine?  It would save a
> > lot
> > > in
> > > > > terms of SWC size to not have source maps in the SWCs.
> > > > >
> > > > > Thoughts?
> > > > > -Alex
> > > > >
> > > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>


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

Re: SourceMaps in SWCs

[Piotr Zarzycki]

If there is no difference for IDE where source map is placed - Let's do
what is easier to do. It seems to be not a high priority stuff - unless it
is blocking Alex from moving forward.

On Sun, May 26, 2019, 12:11 PM Carlos Rovira 
wrote:

> Hi Piotr,
>
> yes, you can debug in IDE or Browser and reach to framework classes what is
> great and very convenient.
> I think having both options would be best too, but as always someone should
> add the switcher to do that.
> We always can do that at some time, but If there's no time at this moment,
> I'll prefer source maps included by default and then
> wait for someone that want to add the switch. IOW, I prefer it as an
> "opt-out", since asume users will want this by default.
>
> El dom., 26 may. 2019 a las 10:04, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > Hi Carlos,
> >
> > When you build application by Maven - did you try it run by VSCode - does
> > debugging working with build in source map?
> > I'm wondering how IDE would be influenced by having source map in/out of
> > SWC.
> >
> > I think having both possibilities would be the best.
> >
> > Thanks,
> > Piotr
> >
> > On Sun, May 26, 2019, 8:26 AM Carlos Rovira 
> > wrote:
> >
> > > Hi,
> > >
> > > my opinion on this is that users'll want the capability to debug
> > framework
> > > code by default and will prefer that to save bandwidth.
> > > sourceMaps is other thing that differentiate Royale over many JS basic
> > > libraries that does not have this built in and put us with the group
> that
> > > have it, so more in the group of "structured programing with debugging
> > > capabilities".
> > > So I think ANT should have as well sourceMaps on by default. Then if we
> > can
> > > have a switch for opt-out will be great, but maybe a bit of work for
> > > something that probably will be low priority right now, or we could
> wait
> > to
> > > someone to ask for, fill an issue and then work on it.
> > > About sourceRoot not mapping to anything, can't say since I thought
> that
> > > was not possible until now, so maybe others could respond to that
> > > thanks
> > >
> > > El dom., 26 may. 2019 a las 5:23, Alex Harui ( > >)
> > > escribió:
> > >
> > > > Hi,
> > > >
> > > > In working through the release automation, it appears that the Maven
> > > build
> > > > puts source maps in the SWC for every JS file but the Ant build does
> > not.
> > > > Should there be source maps in the SWCs?  How do they work when the
> > > > sourceRoot doesn't map to anything?  Or should that only be an option
> > > when
> > > > building everything from sources on your machine?  It would save a
> lot
> > in
> > > > terms of SWC size to not have source maps in the SWCs.
> > > >
> > > > Thoughts?
> > > > -Alex
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Re: Language improvements

[Carlos Rovira]

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 majority of my Vector uses.
>
> Thanks,
> Harbs
>
> > On May 26, 2019, at 12:59 PM, Greg Dove  wrote:
> >
> > Hi Harbs, a real quick answer inline below.
> >
> >
> > On Sun, 26 May 2019, 20:39 Harbs,  wrote:
> >
> >> I read through this, but I might be missing the background. I’ve missed
> >> quite a few discussions on the list lately. (Life has been busy…)
> >>
> >> Can you summarize what you were working on fixing in Vector?
> >>
> >
> > In a word: parity. Vector did not have an actual real implementation. The
> > compiler is essentially outputting a normal regular Array in develop. So
> > distinctive Vector type safety features do not work in develop and
> runtime
> > is/as type checks and coercions etc don't behave the same in js as swf.
> All
> > that is addressed in the branch.
> >
> >
> >
> >> Thanks,
> >> Harbs
> >>
> >>
> >>> On May 5, 2019, at 11:00 AM, Greg Dove  wrote:
> >>>
> >>> So...  just an overview of recent work I have been doing. Summery up
> >> front,
> >>> some extra detail further down... please try things with the branch if
> >> you
> >>> have time.
> >>>
> >>> In the *improvements/Language* branch there are many updates inside
> >>> Language and related updates inside the compiler to address these main
> >>> areas:
> >>> -Fixes/better support for int and uint types at runtime
> >>> -Fixes for strict equality comparisons when instantiated types are
> >>> uncertain, or known to be problematic in these cases for specific types
> >>> that are known.
> >>> -Complex implicit coercions (throws errors if assigned type is
> incorrect)
> >>> -Vectors - test-driven development of a conforming implementation.
> >>>
> >>> The new features are supported by almost 350 new assertion tests (in
> the
> >>> UnitTests manualtests project). This was not a trivial amount of work
> :)
> >>>
> >>> I still have a few things to work on in the branch, including some
> tuning
> >>> for the new configuration settings and adding tests to the compiler for
> >>> those, but I would be keen for others to test the branch and try it
> with
> >>> real projects, and provide feedback. So this is 'improvements/Language'
> >> for
> >>> both royale-asjs and royale-compiler.
> >>> In particular, please take Vector for a spin and see if you can break
> >>> anything and let me know!
> >>> Note the new configuration settings a bit further down (and see
> examples
> >>> here for how to switch them off globally:
> >>> mvn:
> >>>
> >>
> https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/projects/pom.xml#L88
> >>> ant:
> >>>
> >>
> https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/js/projects/BasicJS/src/main/config/compile-js-config.xml#L106
> >>> )
> >>>
> >>>
> >>> A couple of examples:
> >>> I tried compiling Tour de Jewel with the new features switched on, it
> it
> >>> immediately highlighted a runtime error where a 'bead' was being added
> >>> which was not actually an IBead. This was detected in a Vector push
> >>> operation. Although it was not causing problems, it is a good example
> of
> >>> something that would have failed at runtime in the flash player, making
> >> it
> >>> much easier to identify and fix.
> >>>
> >>> I have switched the extra outputs off for all the framework code in the
> >>> branch. But I did try a couple of projects with them on. As an example,
> >>> after building XML with them on it throws a runtime error when calling
> >> one
> >>> of the methods in XML.
> >>> The method has the wrong argument type (Element type when it should
> >> -iirc-
> >>> be Node). So these can catch errors in your code that are silent
> because
> >>> there is no strong typechecking at runtime.
> >>> The above is the implicit complex coercion in action. it is like if you
> >> did
> >>> in flash player :
> >>> var myArray:Array = [new ByteArray()];
> >>> var sprite:Sprite = myArray[0]; //runtime error here
> >>> This does not happen currently in Royale javascript, but is now
> supported
> >>> in the branch (and you can switch it off). This is an expansion of some
> >> of
> >>> Josh's 

Re: Language improvements

[Harbs]

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 majority of my Vector uses.

Thanks,
Harbs

> On May 26, 2019, at 12:59 PM, Greg Dove  wrote:
> 
> Hi Harbs, a real quick answer inline below.
> 
> 
> On Sun, 26 May 2019, 20:39 Harbs,  wrote:
> 
>> I read through this, but I might be missing the background. I’ve missed
>> quite a few discussions on the list lately. (Life has been busy…)
>> 
>> Can you summarize what you were working on fixing in Vector?
>> 
> 
> In a word: parity. Vector did not have an actual real implementation. The
> compiler is essentially outputting a normal regular Array in develop. So
> distinctive Vector type safety features do not work in develop and runtime
> is/as type checks and coercions etc don't behave the same in js as swf. All
> that is addressed in the branch.
> 
> 
> 
>> Thanks,
>> Harbs
>> 
>> 
>>> On May 5, 2019, at 11:00 AM, Greg Dove  wrote:
>>> 
>>> So...  just an overview of recent work I have been doing. Summery up
>> front,
>>> some extra detail further down... please try things with the branch if
>> you
>>> have time.
>>> 
>>> In the *improvements/Language* branch there are many updates inside
>>> Language and related updates inside the compiler to address these main
>>> areas:
>>> -Fixes/better support for int and uint types at runtime
>>> -Fixes for strict equality comparisons when instantiated types are
>>> uncertain, or known to be problematic in these cases for specific types
>>> that are known.
>>> -Complex implicit coercions (throws errors if assigned type is incorrect)
>>> -Vectors - test-driven development of a conforming implementation.
>>> 
>>> The new features are supported by almost 350 new assertion tests (in the
>>> UnitTests manualtests project). This was not a trivial amount of work :)
>>> 
>>> I still have a few things to work on in the branch, including some tuning
>>> for the new configuration settings and adding tests to the compiler for
>>> those, but I would be keen for others to test the branch and try it with
>>> real projects, and provide feedback. So this is 'improvements/Language'
>> for
>>> both royale-asjs and royale-compiler.
>>> In particular, please take Vector for a spin and see if you can break
>>> anything and let me know!
>>> Note the new configuration settings a bit further down (and see examples
>>> here for how to switch them off globally:
>>> mvn:
>>> 
>> https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/projects/pom.xml#L88
>>> ant:
>>> 
>> https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/js/projects/BasicJS/src/main/config/compile-js-config.xml#L106
>>> )
>>> 
>>> 
>>> A couple of examples:
>>> I tried compiling Tour de Jewel with the new features switched on, it it
>>> immediately highlighted a runtime error where a 'bead' was being added
>>> which was not actually an IBead. This was detected in a Vector push
>>> operation. Although it was not causing problems, it is a good example of
>>> something that would have failed at runtime in the flash player, making
>> it
>>> much easier to identify and fix.
>>> 
>>> I have switched the extra outputs off for all the framework code in the
>>> branch. But I did try a couple of projects with them on. As an example,
>>> after building XML with them on it throws a runtime error when calling
>> one
>>> of the methods in XML.
>>> The method has the wrong argument type (Element type when it should
>> -iirc-
>>> be Node). So these can catch errors in your code that are silent because
>>> there is no strong typechecking at runtime.
>>> The above is the implicit complex coercion in action. it is like if you
>> did
>>> in flash player :
>>> var myArray:Array = [new ByteArray()];
>>> var sprite:Sprite = myArray[0]; //runtime error here
>>> This does not happen currently in Royale javascript, but is now supported
>>> in the branch (and you can switch it off). This is an expansion of some
>> of
>>> Josh's great work in the past with implicit primitive coercions (which
>>> don't throw errors but coerce to the correct type).
>>> 
>>> *New configuration settings*
>>> js-no-complex-implicit-coercions
>>> default: false (i.e. ensures runtime safety when assigning an unknown
>> type
>>> to a known type )
>>> local doc comment directive
>>> switching: @royalesuppresscompleximplicitcoercion
>>> 
>>> js-no-resolve-uncertain
>>> default: false (i.e. ensures instances that are safe in certain
>>> comparisons  )
>>> local doc comment 

Re: SourceMaps in SWCs

[Carlos Rovira]

Hi Piotr,

yes, you can debug in IDE or Browser and reach to framework classes what is
great and very convenient.
I think having both options would be best too, but as always someone should
add the switcher to do that.
We always can do that at some time, but If there's no time at this moment,
I'll prefer source maps included by default and then
wait for someone that want to add the switch. IOW, I prefer it as an
"opt-out", since asume users will want this by default.

El dom., 26 may. 2019 a las 10:04, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Hi Carlos,
>
> When you build application by Maven - did you try it run by VSCode - does
> debugging working with build in source map?
> I'm wondering how IDE would be influenced by having source map in/out of
> SWC.
>
> I think having both possibilities would be the best.
>
> Thanks,
> Piotr
>
> On Sun, May 26, 2019, 8:26 AM Carlos Rovira 
> wrote:
>
> > Hi,
> >
> > my opinion on this is that users'll want the capability to debug
> framework
> > code by default and will prefer that to save bandwidth.
> > sourceMaps is other thing that differentiate Royale over many JS basic
> > libraries that does not have this built in and put us with the group that
> > have it, so more in the group of "structured programing with debugging
> > capabilities".
> > So I think ANT should have as well sourceMaps on by default. Then if we
> can
> > have a switch for opt-out will be great, but maybe a bit of work for
> > something that probably will be low priority right now, or we could wait
> to
> > someone to ask for, fill an issue and then work on it.
> > About sourceRoot not mapping to anything, can't say since I thought that
> > was not possible until now, so maybe others could respond to that
> > thanks
> >
> > El dom., 26 may. 2019 a las 5:23, Alex Harui ( >)
> > escribió:
> >
> > > Hi,
> > >
> > > In working through the release automation, it appears that the Maven
> > build
> > > puts source maps in the SWC for every JS file but the Ant build does
> not.
> > > Should there be source maps in the SWCs?  How do they work when the
> > > sourceRoot doesn't map to anything?  Or should that only be an option
> > when
> > > building everything from sources on your machine?  It would save a lot
> in
> > > terms of SWC size to not have source maps in the SWCs.
> > >
> > > Thoughts?
> > > -Alex
> > >
> > >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>


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

Re: Language improvements

[Greg Dove]

Hi Harbs, a real quick answer inline below.


On Sun, 26 May 2019, 20:39 Harbs,  wrote:

> I read through this, but I might be missing the background. I’ve missed
> quite a few discussions on the list lately. (Life has been busy…)
>
> Can you summarize what you were working on fixing in Vector?
>

In a word: parity. Vector did not have an actual real implementation. The
compiler is essentially outputting a normal regular Array in develop. So
distinctive Vector type safety features do not work in develop and runtime
is/as type checks and coercions etc don't behave the same in js as swf. All
that is addressed in the branch.



> Thanks,
> Harbs
>
>
> > On May 5, 2019, at 11:00 AM, Greg Dove  wrote:
> >
> > So...  just an overview of recent work I have been doing. Summery up
> front,
> > some extra detail further down... please try things with the branch if
> you
> > have time.
> >
> > In the *improvements/Language* branch there are many updates inside
> > Language and related updates inside the compiler to address these main
> > areas:
> > -Fixes/better support for int and uint types at runtime
> > -Fixes for strict equality comparisons when instantiated types are
> > uncertain, or known to be problematic in these cases for specific types
> > that are known.
> > -Complex implicit coercions (throws errors if assigned type is incorrect)
> > -Vectors - test-driven development of a conforming implementation.
> >
> > The new features are supported by almost 350 new assertion tests (in the
> > UnitTests manualtests project). This was not a trivial amount of work :)
> >
> > I still have a few things to work on in the branch, including some tuning
> > for the new configuration settings and adding tests to the compiler for
> > those, but I would be keen for others to test the branch and try it with
> > real projects, and provide feedback. So this is 'improvements/Language'
> for
> > both royale-asjs and royale-compiler.
> > In particular, please take Vector for a spin and see if you can break
> > anything and let me know!
> > Note the new configuration settings a bit further down (and see examples
> > here for how to switch them off globally:
> > mvn:
> >
> https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/projects/pom.xml#L88
> > ant:
> >
> https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/js/projects/BasicJS/src/main/config/compile-js-config.xml#L106
> > )
> >
> >
> > A couple of examples:
> > I tried compiling Tour de Jewel with the new features switched on, it it
> > immediately highlighted a runtime error where a 'bead' was being added
> > which was not actually an IBead. This was detected in a Vector push
> > operation. Although it was not causing problems, it is a good example of
> > something that would have failed at runtime in the flash player, making
> it
> > much easier to identify and fix.
> >
> > I have switched the extra outputs off for all the framework code in the
> > branch. But I did try a couple of projects with them on. As an example,
> > after building XML with them on it throws a runtime error when calling
> one
> > of the methods in XML.
> > The method has the wrong argument type (Element type when it should
> -iirc-
> > be Node). So these can catch errors in your code that are silent because
> > there is no strong typechecking at runtime.
> > The above is the implicit complex coercion in action. it is like if you
> did
> > in flash player :
> > var myArray:Array = [new ByteArray()];
> > var sprite:Sprite = myArray[0]; //runtime error here
> > This does not happen currently in Royale javascript, but is now supported
> > in the branch (and you can switch it off). This is an expansion of some
> of
> > Josh's great work in the past with implicit primitive coercions (which
> > don't throw errors but coerce to the correct type).
> >
> > *New configuration settings*
> > js-no-complex-implicit-coercions
> > default: false (i.e. ensures runtime safety when assigning an unknown
> type
> > to a known type )
> > local doc comment directive
> > switching: @royalesuppresscompleximplicitcoercion
> >
> > js-no-resolve-uncertain
> > default: false (i.e. ensures instances that are safe in certain
> > comparisons  )
> > local doc comment directive switching: @royalesuppressresolveuncertain
> >
> > js-no-vector-index-checks
> > default: false (i.e. vector index checking is on)
> > local doc comment directive switching: @royalesuppressvectorindexcheck
> >
> > *-Fixes problems/provides more general support for int and uint types at
> > runtime*
> > Josh's recent assignment implicit coercions made a big difference for
> these
> > (and other primitive types), but runtime support either caused errors or
> > bad results.
> > Things like
> > var myClass = int;
> >
> > var x:* = new myClass(22.5);
> > trace( x === 22 ) //true
> >
> > The above works now in the branch. iirc I think there is more than one
> > issue with that in develop.
> > I started with this based on 

Re: Language improvements

[Carlos Rovira]

Hi Harbs,

to the risk to simplify it too much, the background is: AS3 Vector is still
missing in Royale, Greg work in an implementation. He consider AS3 Vector
an intrinsic part of the language, as String, Number, Object, Array, and
others. Alex would want Vector to be PAYG so we users can choose between
different implementations.





El dom., 26 may. 2019 a las 10:39, Harbs () escribió:

> I read through this, but I might be missing the background. I’ve missed
> quite a few discussions on the list lately. (Life has been busy…)
>
> Can you summarize what you were working on fixing in Vector?
>
> Thanks,
> Harbs
>
>
> > On May 5, 2019, at 11:00 AM, Greg Dove  wrote:
> >
> > So...  just an overview of recent work I have been doing. Summery up
> front,
> > some extra detail further down... please try things with the branch if
> you
> > have time.
> >
> > In the *improvements/Language* branch there are many updates inside
> > Language and related updates inside the compiler to address these main
> > areas:
> > -Fixes/better support for int and uint types at runtime
> > -Fixes for strict equality comparisons when instantiated types are
> > uncertain, or known to be problematic in these cases for specific types
> > that are known.
> > -Complex implicit coercions (throws errors if assigned type is incorrect)
> > -Vectors - test-driven development of a conforming implementation.
> >
> > The new features are supported by almost 350 new assertion tests (in the
> > UnitTests manualtests project). This was not a trivial amount of work :)
> >
> > I still have a few things to work on in the branch, including some tuning
> > for the new configuration settings and adding tests to the compiler for
> > those, but I would be keen for others to test the branch and try it with
> > real projects, and provide feedback. So this is 'improvements/Language'
> for
> > both royale-asjs and royale-compiler.
> > In particular, please take Vector for a spin and see if you can break
> > anything and let me know!
> > Note the new configuration settings a bit further down (and see examples
> > here for how to switch them off globally:
> > mvn:
> >
> https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/projects/pom.xml#L88
> > ant:
> >
> https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/js/projects/BasicJS/src/main/config/compile-js-config.xml#L106
> > )
> >
> >
> > A couple of examples:
> > I tried compiling Tour de Jewel with the new features switched on, it it
> > immediately highlighted a runtime error where a 'bead' was being added
> > which was not actually an IBead. This was detected in a Vector push
> > operation. Although it was not causing problems, it is a good example of
> > something that would have failed at runtime in the flash player, making
> it
> > much easier to identify and fix.
> >
> > I have switched the extra outputs off for all the framework code in the
> > branch. But I did try a couple of projects with them on. As an example,
> > after building XML with them on it throws a runtime error when calling
> one
> > of the methods in XML.
> > The method has the wrong argument type (Element type when it should
> -iirc-
> > be Node). So these can catch errors in your code that are silent because
> > there is no strong typechecking at runtime.
> > The above is the implicit complex coercion in action. it is like if you
> did
> > in flash player :
> > var myArray:Array = [new ByteArray()];
> > var sprite:Sprite = myArray[0]; //runtime error here
> > This does not happen currently in Royale javascript, but is now supported
> > in the branch (and you can switch it off). This is an expansion of some
> of
> > Josh's great work in the past with implicit primitive coercions (which
> > don't throw errors but coerce to the correct type).
> >
> > *New configuration settings*
> > js-no-complex-implicit-coercions
> > default: false (i.e. ensures runtime safety when assigning an unknown
> type
> > to a known type )
> > local doc comment directive
> > switching: @royalesuppresscompleximplicitcoercion
> >
> > js-no-resolve-uncertain
> > default: false (i.e. ensures instances that are safe in certain
> > comparisons  )
> > local doc comment directive switching: @royalesuppressresolveuncertain
> >
> > js-no-vector-index-checks
> > default: false (i.e. vector index checking is on)
> > local doc comment directive switching: @royalesuppressvectorindexcheck
> >
> > *-Fixes problems/provides more general support for int and uint types at
> > runtime*
> > Josh's recent assignment implicit coercions made a big difference for
> these
> > (and other primitive types), but runtime support either caused errors or
> > bad results.
> > Things like
> > var myClass = int;
> >
> > var x:* = new myClass(22.5);
> > trace( x === 22 ) //true
> >
> > The above works now in the branch. iirc I think there is more than one
> > issue with that in develop.
> > I started with this based on issue #273 which also now is 

Re: Language improvements

[Harbs]

I read through this, but I might be missing the background. I’ve missed quite a 
few discussions on the list lately. (Life has been busy…)

Can you summarize what you were working on fixing in Vector?

Thanks,
Harbs


> On May 5, 2019, at 11:00 AM, Greg Dove  wrote:
> 
> So...  just an overview of recent work I have been doing. Summery up front,
> some extra detail further down... please try things with the branch if you
> have time.
> 
> In the *improvements/Language* branch there are many updates inside
> Language and related updates inside the compiler to address these main
> areas:
> -Fixes/better support for int and uint types at runtime
> -Fixes for strict equality comparisons when instantiated types are
> uncertain, or known to be problematic in these cases for specific types
> that are known.
> -Complex implicit coercions (throws errors if assigned type is incorrect)
> -Vectors - test-driven development of a conforming implementation.
> 
> The new features are supported by almost 350 new assertion tests (in the
> UnitTests manualtests project). This was not a trivial amount of work :)
> 
> I still have a few things to work on in the branch, including some tuning
> for the new configuration settings and adding tests to the compiler for
> those, but I would be keen for others to test the branch and try it with
> real projects, and provide feedback. So this is 'improvements/Language' for
> both royale-asjs and royale-compiler.
> In particular, please take Vector for a spin and see if you can break
> anything and let me know!
> Note the new configuration settings a bit further down (and see examples
> here for how to switch them off globally:
> mvn:
> https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/projects/pom.xml#L88
> ant:
> https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/js/projects/BasicJS/src/main/config/compile-js-config.xml#L106
> )
> 
> 
> A couple of examples:
> I tried compiling Tour de Jewel with the new features switched on, it it
> immediately highlighted a runtime error where a 'bead' was being added
> which was not actually an IBead. This was detected in a Vector push
> operation. Although it was not causing problems, it is a good example of
> something that would have failed at runtime in the flash player, making it
> much easier to identify and fix.
> 
> I have switched the extra outputs off for all the framework code in the
> branch. But I did try a couple of projects with them on. As an example,
> after building XML with them on it throws a runtime error when calling one
> of the methods in XML.
> The method has the wrong argument type (Element type when it should -iirc-
> be Node). So these can catch errors in your code that are silent because
> there is no strong typechecking at runtime.
> The above is the implicit complex coercion in action. it is like if you did
> in flash player :
> var myArray:Array = [new ByteArray()];
> var sprite:Sprite = myArray[0]; //runtime error here
> This does not happen currently in Royale javascript, but is now supported
> in the branch (and you can switch it off). This is an expansion of some of
> Josh's great work in the past with implicit primitive coercions (which
> don't throw errors but coerce to the correct type).
> 
> *New configuration settings*
> js-no-complex-implicit-coercions
> default: false (i.e. ensures runtime safety when assigning an unknown type
> to a known type )
> local doc comment directive
> switching: @royalesuppresscompleximplicitcoercion
> 
> js-no-resolve-uncertain
> default: false (i.e. ensures instances that are safe in certain
> comparisons  )
> local doc comment directive switching: @royalesuppressresolveuncertain
> 
> js-no-vector-index-checks
> default: false (i.e. vector index checking is on)
> local doc comment directive switching: @royalesuppressvectorindexcheck
> 
> *-Fixes problems/provides more general support for int and uint types at
> runtime*
> Josh's recent assignment implicit coercions made a big difference for these
> (and other primitive types), but runtime support either caused errors or
> bad results.
> Things like
> var myClass = int;
> 
> var x:* = new myClass(22.5);
> trace( x === 22 ) //true
> 
> The above works now in the branch. iirc I think there is more than one
> issue with that in develop.
> I started with this based on issue #273 which also now is fixed in the
> branch.
> 
> int and uint are implemented are not needed like this in most cases, so the
> are not real 'classes' but very simple instances of 'synthetic Types' that
> are only 'created' if/when they are requested for the first time. Vectors
> (because they are kind of like factory-generated classes) use the same
> underlying mechanism, but are more complicated than int and uint in terms
> of their supporting implementation. uint and int are almost defined in a
> single line of code, not so for Vectors. Another candidate for a synthetic
> type might be 'Class', but I will see 

Re: Language improvements

[Piotr Zarzycki]

Alex,

I don't understand about what PAYG implementation we are talking about in
case of vector. What can be choosen and what cannot in case of that entity?
It's like Carlos said to me Vector is like another type Number, String etc.

Thanks,
Piotr

On Sun, May 26, 2019, 9:04 AM Carlos Rovira  wrote:

> Hi Alex,
>
> I think PAYG is very important to all of us. And I'm with you that PAYG is
> itself more important than the fact that a small Kbs incrementation (as a
> concept itself). We always have it in mind. But in this concrete case, I
> think Vector is part of the AS3 base and Greg have a first implementation
> for it. For me is like to have String, Number, Date...
>
> So, nothing stops Greg, you or others to continue evolving it to improve
> PAYG in this implementation, but that should happen IMHO after we have this
> one, Since that will not happen any time soon. And better to have something
> than nothing.
>
> In the other hand, maybe in this concrete case discussion over Vector and
> PAYG could derive in community be happy with current implementation or
> wanting more options.
> People will need time to work and experiment with this implementation and
> could report they are happy or they find problems.
>
> Or people can report they want other kind of implementation, in case that
> will be a great point to make it more PAYG (although always that will
> requiere the time, knowledge and effort to make it happen).
>
> What I want to expose is that we should embrace this new implementation as
> the step one, and progress from there to other status little by little
> since sometimes trying to reach to the maximum goal we have in mind could
> be very expensive in terms of time, effort and will left us with the
> possibility to have today the feature, while if we do little by little, we
> have both, the feature and the possibility to continue improving it to be
> better (in this case the possibility to be more PAYG). Perfection is enemy
> of progress.
>
> ITOH, that will be great too since the natural process could make this
> implementation will be chosen by community as something final...or
> notso for me, let's merge it, since is good and is a great step
> forward, and then continue discussing it to see next steps. The later could
> make this evolve more or not...what is clear is that will be weeks or
> months ahead. That's what we've done with many other features in Royale,
> some of them still in progress (Jewel, themes, compoenents,...)
>
> People could want choices or not, but current branch will give all of us a
> first choice since we have 0 right now. Then we can move to convert this on
> multi-choice if community want it, and chances are that people is not
> interested in that...or not...we should see.
>
>
>
>
> El dom., 26 may. 2019 a las 1:10, Alex Harui ()
> escribió:
>
> > Hi Greg,
> >
> > Thanks for working through all of this.  Better Vector handling is
> > definitely a good thing for Royale.
> >
> > 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.
> >
> > 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 have some comments on finer details, but let's see if we can agree on
> > this higher-level issue first.  We simply should offer people choices.
> >
> > Thanks,
> > -Alex
> >
> > On 5/25/19, 2:45 PM, "Greg Dove"  wrote:
> >
> > Hi Carlos, thanks for your feedback. In terms of PAYG, I just have a
> > sense
> > that at the language level, the 'default' should be that it *works*
> as
> > per
> > design.
> > If I take the example of Vector... then numeric Vector types will not
> > run
> > faster in javascript. Using all the method calls will have a
> > substantial
> > impact compared to using a normal Array. But code should 'work' the
> > same
> > across targets.
> > I do have some ideas for application framework classes outside
> > 'language'/Vector that would provide target-agnostic fast regular
> class
> > implementations for numeric typed Arrays, and I hope to work on that
> > soon
> > as well, which takes more advantage of the optimized native options
> on
> > each
> > target (Vector in swf, TypedArray in javascript). But to achieve that
> > it
> > will likely be 'always fixed length' in this case, I will see if it
> > seems
> > worth trying to be able to toggle that, or maybe it can be a bead or
> > opt-in
> > support to get that functionality. But that should provide a good
> > option
> > for developers seeking to get the best performance for numeric
> > collections.
> > I expect to work on this during June.
> > Or developers can of course always choose to implement their own
> custom
> > performance 

Re: SourceMaps in SWCs

[Piotr Zarzycki]

Hi Carlos,

When you build application by Maven - did you try it run by VSCode - does
debugging working with build in source map?
I'm wondering how IDE would be influenced by having source map in/out of
SWC.

I think having both possibilities would be the best.

Thanks,
Piotr

On Sun, May 26, 2019, 8:26 AM Carlos Rovira  wrote:

> Hi,
>
> my opinion on this is that users'll want the capability to debug framework
> code by default and will prefer that to save bandwidth.
> sourceMaps is other thing that differentiate Royale over many JS basic
> libraries that does not have this built in and put us with the group that
> have it, so more in the group of "structured programing with debugging
> capabilities".
> So I think ANT should have as well sourceMaps on by default. Then if we can
> have a switch for opt-out will be great, but maybe a bit of work for
> something that probably will be low priority right now, or we could wait to
> someone to ask for, fill an issue and then work on it.
> About sourceRoot not mapping to anything, can't say since I thought that
> was not possible until now, so maybe others could respond to that
> thanks
>
> El dom., 26 may. 2019 a las 5:23, Alex Harui ()
> escribió:
>
> > Hi,
> >
> > In working through the release automation, it appears that the Maven
> build
> > puts source maps in the SWC for every JS file but the Ant build does not.
> > Should there be source maps in the SWCs?  How do they work when the
> > sourceRoot doesn't map to anything?  Or should that only be an option
> when
> > building everything from sources on your machine?  It would save a lot in
> > terms of SWC size to not have source maps in the SWCs.
> >
> > Thoughts?
> > -Alex
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Re: Language improvements

[Carlos Rovira]

Hi Alex,

I think PAYG is very important to all of us. And I'm with you that PAYG is
itself more important than the fact that a small Kbs incrementation (as a
concept itself). We always have it in mind. But in this concrete case, I
think Vector is part of the AS3 base and Greg have a first implementation
for it. For me is like to have String, Number, Date...

So, nothing stops Greg, you or others to continue evolving it to improve
PAYG in this implementation, but that should happen IMHO after we have this
one, Since that will not happen any time soon. And better to have something
than nothing.

In the other hand, maybe in this concrete case discussion over Vector and
PAYG could derive in community be happy with current implementation or
wanting more options.
People will need time to work and experiment with this implementation and
could report they are happy or they find problems.

Or people can report they want other kind of implementation, in case that
will be a great point to make it more PAYG (although always that will
requiere the time, knowledge and effort to make it happen).

What I want to expose is that we should embrace this new implementation as
the step one, and progress from there to other status little by little
since sometimes trying to reach to the maximum goal we have in mind could
be very expensive in terms of time, effort and will left us with the
possibility to have today the feature, while if we do little by little, we
have both, the feature and the possibility to continue improving it to be
better (in this case the possibility to be more PAYG). Perfection is enemy
of progress.

ITOH, that will be great too since the natural process could make this
implementation will be chosen by community as something final...or
notso for me, let's merge it, since is good and is a great step
forward, and then continue discussing it to see next steps. The later could
make this evolve more or not...what is clear is that will be weeks or
months ahead. That's what we've done with many other features in Royale,
some of them still in progress (Jewel, themes, compoenents,...)

People could want choices or not, but current branch will give all of us a
first choice since we have 0 right now. Then we can move to convert this on
multi-choice if community want it, and chances are that people is not
interested in that...or not...we should see.




El dom., 26 may. 2019 a las 1:10, Alex Harui ()
escribió:

> Hi Greg,
>
> Thanks for working through all of this.  Better Vector handling is
> definitely a good thing for Royale.
>
> 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.
>
> 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 have some comments on finer details, but let's see if we can agree on
> this higher-level issue first.  We simply should offer people choices.
>
> Thanks,
> -Alex
>
> On 5/25/19, 2:45 PM, "Greg Dove"  wrote:
>
> Hi Carlos, thanks for your feedback. In terms of PAYG, I just have a
> sense
> that at the language level, the 'default' should be that it *works* as
> per
> design.
> If I take the example of Vector... then numeric Vector types will not
> run
> faster in javascript. Using all the method calls will have a
> substantial
> impact compared to using a normal Array. But code should 'work' the
> same
> across targets.
> I do have some ideas for application framework classes outside
> 'language'/Vector that would provide target-agnostic fast regular class
> implementations for numeric typed Arrays, and I hope to work on that
> soon
> as well, which takes more advantage of the optimized native options on
> each
> target (Vector in swf, TypedArray in javascript). But to achieve that
> it
> will likely be 'always fixed length' in this case, I will see if it
> seems
> worth trying to be able to toggle that, or maybe it can be a bead or
> opt-in
> support to get that functionality. But that should provide a good
> option
> for developers seeking to get the best performance for numeric
> collections.
> I expect to work on this during June.
> Or developers can of course always choose to implement their own custom
> performance code in COMPILE::JS / COMPILE::SWF variations, which is
> always
> an option.
>
>
> Hi Piotr, sorry about that email formatting issue. Thanks for your
> follow
> up on this.
> Here is a paste of that part, which includes the code.
>
>
> 

Re: SourceMaps in SWCs

[Carlos Rovira]

Hi,

my opinion on this is that users'll want the capability to debug framework
code by default and will prefer that to save bandwidth.
sourceMaps is other thing that differentiate Royale over many JS basic
libraries that does not have this built in and put us with the group that
have it, so more in the group of "structured programing with debugging
capabilities".
So I think ANT should have as well sourceMaps on by default. Then if we can
have a switch for opt-out will be great, but maybe a bit of work for
something that probably will be low priority right now, or we could wait to
someone to ask for, fill an issue and then work on it.
About sourceRoot not mapping to anything, can't say since I thought that
was not possible until now, so maybe others could respond to that
thanks

El dom., 26 may. 2019 a las 5:23, Alex Harui ()
escribió:

> Hi,
>
> In working through the release automation, it appears that the Maven build
> puts source maps in the SWC for every JS file but the Ant build does not.
> Should there be source maps in the SWCs?  How do they work when the
> sourceRoot doesn't map to anything?  Or should that only be an option when
> building everything from sources on your machine?  It would save a lot in
> terms of SWC size to not have source maps in the SWCs.
>
> Thoughts?
> -Alex
>
>

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