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.

Build failed in Jenkins: royale-asjs_MXTests #803

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

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

[Apache Royale CI Server]

See 

Release Step 007 Succeeded

[Apache Royale CI Server]

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

Release Step 006 Succeeded

[Apache Royale CI Server]

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

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

Royale_Release_Step_006 - Build # 21 - Failure!

[Apache Royale CI Server]

Royale_Release_Step_006 - Build # 21 - Failure:

Check console output at 
http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_006/21/
 to view the results.

Release Step 005a Succeeded

[Apache Royale CI Server]

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

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

Release Step 005 Succeeded

[Apache Royale CI Server]

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

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

Release Step 004 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_004 and run the following commands:
git push
git checkout release/0.9.6
git push -u origin release/0.9.6

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

Re: RoyaleUnit Ant Task

[Alex Harui]

Also note that when I Remote Desktop into apacheroyaleci, I have seen a 
"Firefox closed unexpectedly when starting" dialog a couple of times.  I've not 
seen that before, so might be related to your changes.

-Alex

On 5/23/19, 7:47 PM, "Alex Harui"  wrote:

First off, this sounds like a great new capability for Royale, so thanks 
for working on it.

Regarding JS test issues, did you rule out using Selenium?  I haven't had 
problems with it on Mac or Win for Mustella.

HTH,
-Alex

On 5/23/19, 4:20 PM, "Josh Tynjala"  wrote:

Unfortunately, I had to disable the JS tests automatically running on 
the royale-asjs main build because they intermittently fail on macOS. It seems 
that the port that the WebSocket server uses isn't released until some time 
after the  task completes. So, after one Royale library is tested, 
the next might fail. I haven't figured out what's causing it yet. Additionally, 
this issue does not affect Windows.

The JS tests are still available, if you'd like to run them manually. 
The following commands will run tests for CoreJS:

cd frameworks/js/projects/CoreJS
ant test

We currently have JS tests for CoreJS, BasicJS, and RoyaleUnitJS.

- Josh

On 2019/05/23 19:18:21, Josh Tynjala  wrote: 
> Hey Royale team,
> 
> Over the last several days, I've been working on RoyaleUnit again, 
and I wanted to share a bit about what I've completed this week.
> 
> ## New  Ant task
> 
> Until now, we've been using the  Ant task to run RoyaleUnit 
tests on our SWF output in the Ant builds. The RoyaleUnit library is similar to 
FlexUnit, but it's a completely new implementation that works on both SWF and 
JS. When I first created RoyaleUnit, I could only get SWF output successfully 
communicating with the  Ant task. JS tests could be run manually, but 
they could not be automated in Ant yet, for technical reasons.
> 
> On the SWF side, FlexUnit uses XMLSocket to communicate with the 
 Ant task. That was easy enough to port over to RoyaleUnit. However, 
JS in the browser doesn't have a simple socket implementation that would allow 
it to speak the same protocol. The closest thing is WebSocket, but the 
 Ant task doesn't know how to talk to WebSockets. So, I created a new 
 Ant task that can still speak XMLSocket with SWF, but also 
supports WebSocket for JS.
> 
> Previously, you could specify "flash" or "air" for the player value 
in the Ant task:
> 
> 
> 
> 
> I added a new one, "html", that tells the Ant task to use WebSockets.
> 
> 
> 
> Then, you can use the swf property to specify the HTML file to launch:
> 
> 
> 
> (It was already called "swf" in , but maybe we should 
rename it or provide an alias)
> 
> By default, it should use your default web browser. However, if you'd 
prefer a different browser, you can use the command property:
> 
> 
> 
> ## Ant builds run JS tests
> 
> After I got the  Ant task work, I updated our royale-asjs 
Ant builds to run both SWF and JS tests. This was interesting because it needs 
to launch a web browser, and there are some gotchas that I discovered.
> 
> In particular, Internet Explorer always requires the user to manually 
click a button to allow JavaScript content to run in a local HTML file. 
Likewise, the first time a local file is launched in Safari, it asks to confirm 
if you want to open it or not. When you try to open the file again later, 
Safari opens it without asking, but that first time isn't ideal.
> 
> With the two default browsers not really good candidates, I decided 
to try Chrome and Firefox. I found that both will run scripts without a prompt, 
but they aren't necessarily installed on everyone's systems. So, first it looks 
for Chrome (which is the most popular browser these days), and then it falls 
back to Firefox. If it can't find either one, the build fails with an error.
> 
> In the case where a browser cannot be found automatically, there is 
the option to specify a royaleunit.browser property when running the Ant build 
script. You can either add it to your *env.properties* file in the root of 
royale-asjs, or you can specify it on the command line like this:
> 
> ant -Droyaleunit.browser=path/to/browser.exe
> 
> (On macOS, I think that you need to point to the native executable 
instead of the .app file, like /Applications/Firefox.app/Contents/MacOS/firefox)
> 
> When  finishes running JS tests in the browser, it will 
automatically close the browser — except when that browser was already open 
before you started running the tests. In that case, it will simply 

Re: RoyaleUnit Ant Task

[Alex Harui]

First off, this sounds like a great new capability for Royale, so thanks for 
working on it.

Regarding JS test issues, did you rule out using Selenium?  I haven't had 
problems with it on Mac or Win for Mustella.

HTH,
-Alex

On 5/23/19, 4:20 PM, "Josh Tynjala"  wrote:

Unfortunately, I had to disable the JS tests automatically running on the 
royale-asjs main build because they intermittently fail on macOS. It seems that 
the port that the WebSocket server uses isn't released until some time after 
the  task completes. So, after one Royale library is tested, the 
next might fail. I haven't figured out what's causing it yet. Additionally, 
this issue does not affect Windows.

The JS tests are still available, if you'd like to run them manually. The 
following commands will run tests for CoreJS:

cd frameworks/js/projects/CoreJS
ant test

We currently have JS tests for CoreJS, BasicJS, and RoyaleUnitJS.

- Josh

On 2019/05/23 19:18:21, Josh Tynjala  wrote: 
> Hey Royale team,
> 
> Over the last several days, I've been working on RoyaleUnit again, and I 
wanted to share a bit about what I've completed this week.
> 
> ## New  Ant task
> 
> Until now, we've been using the  Ant task to run RoyaleUnit 
tests on our SWF output in the Ant builds. The RoyaleUnit library is similar to 
FlexUnit, but it's a completely new implementation that works on both SWF and 
JS. When I first created RoyaleUnit, I could only get SWF output successfully 
communicating with the  Ant task. JS tests could be run manually, but 
they could not be automated in Ant yet, for technical reasons.
> 
> On the SWF side, FlexUnit uses XMLSocket to communicate with the 
 Ant task. That was easy enough to port over to RoyaleUnit. However, 
JS in the browser doesn't have a simple socket implementation that would allow 
it to speak the same protocol. The closest thing is WebSocket, but the 
 Ant task doesn't know how to talk to WebSockets. So, I created a new 
 Ant task that can still speak XMLSocket with SWF, but also 
supports WebSocket for JS.
> 
> Previously, you could specify "flash" or "air" for the player value in 
the Ant task:
> 
> 
> 
> 
> I added a new one, "html", that tells the Ant task to use WebSockets.
> 
> 
> 
> Then, you can use the swf property to specify the HTML file to launch:
> 
> 
> 
> (It was already called "swf" in , but maybe we should rename it 
or provide an alias)
> 
> By default, it should use your default web browser. However, if you'd 
prefer a different browser, you can use the command property:
> 
> 
> 
> ## Ant builds run JS tests
> 
> After I got the  Ant task work, I updated our royale-asjs Ant 
builds to run both SWF and JS tests. This was interesting because it needs to 
launch a web browser, and there are some gotchas that I discovered.
> 
> In particular, Internet Explorer always requires the user to manually 
click a button to allow JavaScript content to run in a local HTML file. 
Likewise, the first time a local file is launched in Safari, it asks to confirm 
if you want to open it or not. When you try to open the file again later, 
Safari opens it without asking, but that first time isn't ideal.
> 
> With the two default browsers not really good candidates, I decided to 
try Chrome and Firefox. I found that both will run scripts without a prompt, 
but they aren't necessarily installed on everyone's systems. So, first it looks 
for Chrome (which is the most popular browser these days), and then it falls 
back to Firefox. If it can't find either one, the build fails with an error.
> 
> In the case where a browser cannot be found automatically, there is the 
option to specify a royaleunit.browser property when running the Ant build 
script. You can either add it to your *env.properties* file in the root of 
royale-asjs, or you can specify it on the command line like this:
> 
> ant -Droyaleunit.browser=path/to/browser.exe
> 
> (On macOS, I think that you need to point to the native executable 
instead of the .app file, like /Applications/Firefox.app/Contents/MacOS/firefox)
> 
> When  finishes running JS tests in the browser, it will 
automatically close the browser — except when that browser was already open 
before you started running the tests. In that case, it will simply open a new 
tab, which will remain open after the tests complete. So, it won't make you 
lose all of your existing tabs or anything. However, it may be annoying to have 
a bunch of extra tabs that you need to manually close every time that you run 
the build script. In that case, just like I explained above, you can use the 
royaleunit.browser property in env.properties or via the command line to tell 
the build to run JS tests in a different browser that you prefer. As I 
mentioned, if that browser isn't already 

Re: Problems building with Maven from scratch

[Alex Harui]

Over in Ant, there are some rules (at least for now).  I don't remember 
exactly, but I think it is:

  Either define all 3 variables (PLAYERGLOBAL_HOME, AIR_HOME, 
FLASHPLAYER_DEBUGGER) or don't define any of them.

Nobody has had the time to make the other combinations work.  The rationale is 
that either someone took the time to set up the Adobe stuff or they didn't.  
And so, when long-time committers like yourself and Carlos are testing, you may 
not be testing in a true newbie's configuration as we wouldn't expect them to 
have any environment variables set, while you and Carlos probably have at least 
some of them set since that used to be the requirement.

The same may be true for Maven.  I still haven't found time to look, hoping one 
of you will eventually understand the logic behind this stuff and figure it out 
so I can keep making progress on the release automation.

In the TestAdapters, IIRC, some of the compiler tests can run without Adobe 
artifacts and/or Flash Player Debugger.  A SWF is built, then SWFDump'd (but 
never launched in a Flash Player) and the dump is compared against a reference 
dump.  I know AntTestAdapter does this, I don't remember if MavenTestAdapter 
does, hence what I wrote about no point in running tests in JS-Only if there 
are no SWF artifacts and/or no Adobe artifacts.

So, IMO, either define all 3 environment variables for Ant or don't define any. 
 And for Maven, the same might be true.  If you want to spend the time getting 
other combinations to work, fine, but IMO the two main scenarios are 1) You 
have the Adobe stuff and want SWF artifacts, or 2) You don't have the Adobe 
stuff nor any environment variables and don’t want SWF artifacts.  Maybe we 
don't have to skip tests in those setups.  I don't know.

HTH,
-Alex

On 5/23/19, 3:36 PM, "Greg Dove"  wrote:

'If our tests require Flash, then there is no point in running them if
there are no SWF artifacts.'

This is just an info dump, in case the following is useful:
(short version) My failing combination is a) FLASHPLAYER_DEBUGGER is
defined and b) PLAYERGLOBAL_HOME is not defined and/or local m2 does not
contain playerglobal swc
But this is just with standard maven build, not with profiles or anything
specified.  Also on windows, in case that matters in any way.

(Details)
I am still getting to grips with 'profiles' in maven. I probably read about
that at one point and have used them, but will go back to refresh my
knowledge (now that I understand more of the basics).
I did observe that the MavenTestAdapter has a getPlayerGlobal method which
looks for the swc in the tests for compiler (not compiler-jx), this still
tries to run the tests if playerglobal is missing (and assuming the debug
player is available), but the player has bad bytecode (e.g. error dialogs
like TypeError: Error #2023: Class ASDateTests1933741105634631672$ must
inherit from Sprite to link to the root.)

When I look at getPlayerglobal() inside MavenTestAdapter I do see something
a little confusing (to me).

It checks to see if PLAYERGLOBAL_HOME is defined. If it is not, it bails
and returns null. This will cause an error later in testing
But PLAYERGLOBAL_HOME does not appear to be used to find the playerglobal
swc anywhere else, so this check may not even be relevant.
if PLAYERGLOBAL_HOME is defined, then it ignores it and looks for the swc
in System.getProperty("mavenLocalRepoDir"). This is why I think it finds it
after it has been cached in local m2 and perhaps why things continue to
work when it is removed from the pom dependencies.

However, if I unset FLASHPLAYER_DEBUGGER env var then the tests phase
passes and the build continues on to completion.
So my failing combination is a) FLASHPLAYER_DEBUGGER is defined and b)
PLAYERGLOBAL_HOME is not defined and/or local m2 does not contain
playerglobal swc



On Fri, May 24, 2019 at 7:33 AM Alex Harui  wrote:

> I guess I am not making a clear statement.  I understand you are trying to
> help others, but unless you have tested from scratch with both generating
> SWF artifacts and not generating SWF artifacts then you haven't actually
> helped everyone, just those who want the same set of artifacts you are
> expecting.
>
> I would not expect any solution to include an Adobe artifact without using
> a profile to include it.
>
> You might need two videos, one for generating SWF artifacts and one for
> not.
>
> If our tests require Flash, then there is no point in running them if
> there are no SWF artifacts.
>
> Thanks,
> -Alex
>
> On 5/23/19, 11:06 AM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> I'm not getting this working only for me, in fact my motivation was
> exactly
> the opposite. The final motivation is to 

Build failed in Jenkins: royale-asjs_MXTests #802

[Apache Royale CI Server]

See 


Changes:

[joshtynjala] royaleunit.browser for Linux/Unix

[joshtynjala] builds fail if tests don't pass

[joshtynjala] revert builds fail if tests don't pass

[joshtynjala] disabling haltonfailure didn't make a difference for macOS 
BindException

[joshtynjala] Frameworks: disable JS tests in main build for now

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

Jenkins build is back to normal : royale-asjs #2295

[Apache Royale CI Server]

See 

Re: RoyaleUnit Ant Task

[Josh Tynjala]

Unfortunately, I had to disable the JS tests automatically running on the 
royale-asjs main build because they intermittently fail on macOS. It seems that 
the port that the WebSocket server uses isn't released until some time after 
the  task completes. So, after one Royale library is tested, the 
next might fail. I haven't figured out what's causing it yet. Additionally, 
this issue does not affect Windows.

The JS tests are still available, if you'd like to run them manually. The 
following commands will run tests for CoreJS:

cd frameworks/js/projects/CoreJS
ant test

We currently have JS tests for CoreJS, BasicJS, and RoyaleUnitJS.

- Josh

On 2019/05/23 19:18:21, Josh Tynjala  wrote: 
> Hey Royale team,
> 
> Over the last several days, I've been working on RoyaleUnit again, and I 
> wanted to share a bit about what I've completed this week.
> 
> ## New  Ant task
> 
> Until now, we've been using the  Ant task to run RoyaleUnit tests 
> on our SWF output in the Ant builds. The RoyaleUnit library is similar to 
> FlexUnit, but it's a completely new implementation that works on both SWF and 
> JS. When I first created RoyaleUnit, I could only get SWF output successfully 
> communicating with the  Ant task. JS tests could be run manually, 
> but they could not be automated in Ant yet, for technical reasons.
> 
> On the SWF side, FlexUnit uses XMLSocket to communicate with the  
> Ant task. That was easy enough to port over to RoyaleUnit. However, JS in the 
> browser doesn't have a simple socket implementation that would allow it to 
> speak the same protocol. The closest thing is WebSocket, but the  
> Ant task doesn't know how to talk to WebSockets. So, I created a new 
>  Ant task that can still speak XMLSocket with SWF, but also 
> supports WebSocket for JS.
> 
> Previously, you could specify "flash" or "air" for the player value in the 
> Ant task:
> 
> 
> 
> 
> I added a new one, "html", that tells the Ant task to use WebSockets.
> 
> 
> 
> Then, you can use the swf property to specify the HTML file to launch:
> 
> 
> 
> (It was already called "swf" in , but maybe we should rename it or 
> provide an alias)
> 
> By default, it should use your default web browser. However, if you'd prefer 
> a different browser, you can use the command property:
> 
> 
> 
> ## Ant builds run JS tests
> 
> After I got the  Ant task work, I updated our royale-asjs Ant 
> builds to run both SWF and JS tests. This was interesting because it needs to 
> launch a web browser, and there are some gotchas that I discovered.
> 
> In particular, Internet Explorer always requires the user to manually click a 
> button to allow JavaScript content to run in a local HTML file. Likewise, the 
> first time a local file is launched in Safari, it asks to confirm if you want 
> to open it or not. When you try to open the file again later, Safari opens it 
> without asking, but that first time isn't ideal.
> 
> With the two default browsers not really good candidates, I decided to try 
> Chrome and Firefox. I found that both will run scripts without a prompt, but 
> they aren't necessarily installed on everyone's systems. So, first it looks 
> for Chrome (which is the most popular browser these days), and then it falls 
> back to Firefox. If it can't find either one, the build fails with an error.
> 
> In the case where a browser cannot be found automatically, there is the 
> option to specify a royaleunit.browser property when running the Ant build 
> script. You can either add it to your *env.properties* file in the root of 
> royale-asjs, or you can specify it on the command line like this:
> 
> ant -Droyaleunit.browser=path/to/browser.exe
> 
> (On macOS, I think that you need to point to the native executable instead of 
> the .app file, like /Applications/Firefox.app/Contents/MacOS/firefox)
> 
> When  finishes running JS tests in the browser, it will 
> automatically close the browser — except when that browser was already open 
> before you started running the tests. In that case, it will simply open a new 
> tab, which will remain open after the tests complete. So, it won't make you 
> lose all of your existing tabs or anything. However, it may be annoying to 
> have a bunch of extra tabs that you need to manually close every time that 
> you run the build script. In that case, just like I explained above, you can 
> use the royaleunit.browser property in env.properties or via the command line 
> to tell the build to run JS tests in a different browser that you prefer. As 
> I mentioned, if that browser isn't already open, the build script will exit 
> the browser automatically after running tests.
> 
> I confirmed that apacheroyaleci on Azure has Firefox installed, and at least 
> one build has completed successfully on this server.
> 
> Please let me know if this has disrupted anything. However, I think that I 
> covered the edge cases pretty well.
> 
> - Josh
> 

Build failed in Jenkins: royale-asjs #2294

[Apache Royale CI Server]

See 


Changes:

[joshtynjala] revert builds fail if tests don't pass

[joshtynjala] disabling haltonfailure didn't make a difference for macOS 
BindException

--
[...truncated 1.68 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: 

Re: Problems building with Maven from scratch

[Greg Dove]

'If our tests require Flash, then there is no point in running them if
there are no SWF artifacts.'

This is just an info dump, in case the following is useful:
(short version) My failing combination is a) FLASHPLAYER_DEBUGGER is
defined and b) PLAYERGLOBAL_HOME is not defined and/or local m2 does not
contain playerglobal swc
But this is just with standard maven build, not with profiles or anything
specified.  Also on windows, in case that matters in any way.

(Details)
I am still getting to grips with 'profiles' in maven. I probably read about
that at one point and have used them, but will go back to refresh my
knowledge (now that I understand more of the basics).
I did observe that the MavenTestAdapter has a getPlayerGlobal method which
looks for the swc in the tests for compiler (not compiler-jx), this still
tries to run the tests if playerglobal is missing (and assuming the debug
player is available), but the player has bad bytecode (e.g. error dialogs
like TypeError: Error #2023: Class ASDateTests1933741105634631672$ must
inherit from Sprite to link to the root.)

When I look at getPlayerglobal() inside MavenTestAdapter I do see something
a little confusing (to me).

It checks to see if PLAYERGLOBAL_HOME is defined. If it is not, it bails
and returns null. This will cause an error later in testing
But PLAYERGLOBAL_HOME does not appear to be used to find the playerglobal
swc anywhere else, so this check may not even be relevant.
if PLAYERGLOBAL_HOME is defined, then it ignores it and looks for the swc
in System.getProperty("mavenLocalRepoDir"). This is why I think it finds it
after it has been cached in local m2 and perhaps why things continue to
work when it is removed from the pom dependencies.

However, if I unset FLASHPLAYER_DEBUGGER env var then the tests phase
passes and the build continues on to completion.
So my failing combination is a) FLASHPLAYER_DEBUGGER is defined and b)
PLAYERGLOBAL_HOME is not defined and/or local m2 does not contain
playerglobal swc



On Fri, May 24, 2019 at 7:33 AM Alex Harui  wrote:

> I guess I am not making a clear statement.  I understand you are trying to
> help others, but unless you have tested from scratch with both generating
> SWF artifacts and not generating SWF artifacts then you haven't actually
> helped everyone, just those who want the same set of artifacts you are
> expecting.
>
> I would not expect any solution to include an Adobe artifact without using
> a profile to include it.
>
> You might need two videos, one for generating SWF artifacts and one for
> not.
>
> If our tests require Flash, then there is no point in running them if
> there are no SWF artifacts.
>
> Thanks,
> -Alex
>
> On 5/23/19, 11:06 AM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> I'm not getting this working only for me, in fact my motivation was
> exactly
> the opposite. The final motivation is to able to do a short video to
> post
> on an Apache Royale youtube channel, since is something many, many
> people
> requested. And something I think will give us more users and exposure.
>
> I was working without problem each day. I tried to remove repository
> folder
> to simulate a "day 0" like a new user to see if all was working. The
> result
> was it was failing.
>
> Now with a dependency added in compiler's pom and a profile added in
> the
> wiki instructions, I was able to build from scratch. Other's can try
> this
> to proof is a solution for anyone.
>
> IOW, If a new user tries the wiki steps some days ago he'd found royale
> didn't build, and fails with the error exposed here, and will get
> stuck.
> Now, hopefully he will get it working.
>
> For me is ok, all you say (maybe the only thing I don't agree is put
> skipTests to false as an official way to make maven build work
> officially,
> since in maven tests are mandatory, and you must opt-out, with a
> profile o
> via command line, but official build should work with normal tests in a
> first execution).
>
> About having a repository or not: This should not matter, but the fact
> is
> it currently does, independently of what any of us want. I, as you,
> would
> want the simplest way to build, that could be always the same, but
> there's
> a difference in a first maven build of royale against the subsequent
> builds, that can be simplified (removing the -s settings... and the
> -Pprofile..). I didn't design the process, but is what we have now. So
> is
> important to test against an empty repository folder, unless we change
> the
> build process and get it more simpler, what I don't expect to happen
> anytime soon, since all of us have many things on plate right now.
>
> I think we all understand the goals, and that we have two sets of
> outputs.
> Right now, I only know how to get one of them. If there's other one you
> know you can post it here and I can put on wiki, or directly modify
> wiki
> 

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

[Apache Royale CI Server]

See 

Build failed in Jenkins: royale-asjs #2293

[Apache Royale CI Server]

See 


Changes:

[joshtynjala] builds fail if tests don't pass

--
[...truncated 2.55 MB...]
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/IChild.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/IStrand.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/IUIBase.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/ILayoutChild.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/reflection/TypeDefinition.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/reflection/ParameterDefinition.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/reflection/describeType.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/test/runners/ITestRunner.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/test/runners/MetadataRunner.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/IMeasurementBead.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/IFlexInfo.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/events/IRoyaleEvent.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/events/Event.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/events/ValueChangeEvent.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/IPopUpHost.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/IPopUpHostParent.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/events/EventDispatcher.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/HTMLElementWrapper.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/ApplicationBase.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/Application.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/IValuesImpl.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/SimpleValuesImpl.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/tests/BeforeClassAndAfterClassTests.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/core/IParentIUIBase.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/utils/Language.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/reflection/VariableDefinition.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/reflection/AccessorDefinition.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/utils/Timer.js
[mxmlc] 
c:/jenkins/workspace/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target/bin/js-debug/org/apache/royale/test/runners/notification/IRunListener.js
[mxmlc] 

Release Step 003 Succeeded

[Apache Royale CI Server]

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

Release Step 002a Succeeded

[Apache Royale CI Server]

Continue on to Release Step 003

Build failed in Jenkins: royale-asjs #2292

[Apache Royale CI Server]

See 


Changes:

[joshtynjala] royaleunit.browser for Linux/Unix

--
[...truncated 2.54 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: 

Release Step 002 Succeeded

[Apache Royale CI Server]

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

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

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

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.

Re: Problems building with Maven from scratch

[Alex Harui]

I guess I am not making a clear statement.  I understand you are trying to help 
others, but unless you have tested from scratch with both generating SWF 
artifacts and not generating SWF artifacts then you haven't actually helped 
everyone, just those who want the same set of artifacts you are expecting.

I would not expect any solution to include an Adobe artifact without using a 
profile to include it.

You might need two videos, one for generating SWF artifacts and one for not.

If our tests require Flash, then there is no point in running them if there are 
no SWF artifacts.

Thanks,
-Alex

On 5/23/19, 11:06 AM, "Carlos Rovira"  wrote:

Hi Alex,

I'm not getting this working only for me, in fact my motivation was exactly
the opposite. The final motivation is to able to do a short video to post
on an Apache Royale youtube channel, since is something many, many people
requested. And something I think will give us more users and exposure.

I was working without problem each day. I tried to remove repository folder
to simulate a "day 0" like a new user to see if all was working. The result
was it was failing.

Now with a dependency added in compiler's pom and a profile added in the
wiki instructions, I was able to build from scratch. Other's can try this
to proof is a solution for anyone.

IOW, If a new user tries the wiki steps some days ago he'd found royale
didn't build, and fails with the error exposed here, and will get stuck.
Now, hopefully he will get it working.

For me is ok, all you say (maybe the only thing I don't agree is put
skipTests to false as an official way to make maven build work officially,
since in maven tests are mandatory, and you must opt-out, with a profile o
via command line, but official build should work with normal tests in a
first execution).

About having a repository or not: This should not matter, but the fact is
it currently does, independently of what any of us want. I, as you, would
want the simplest way to build, that could be always the same, but there's
a difference in a first maven build of royale against the subsequent
builds, that can be simplified (removing the -s settings... and the
-Pprofile..). I didn't design the process, but is what we have now. So is
important to test against an empty repository folder, unless we change the
build process and get it more simpler, what I don't expect to happen
anytime soon, since all of us have many things on plate right now.

I think we all understand the goals, and that we have two sets of outputs.
Right now, I only know how to get one of them. If there's other one you
know you can post it here and I can put on wiki, or directly modify wiki
page that is the official one. If you can do the second, it would be great
since it will be more accurate to what you have in mind.

If you have no time fo now what we can do is:
2
a) I can reintroduce the "-Putils" line in the wiki as something to do in a
concrete case, since right now (at the time we are writing this), as you
posted is important in a concrete situation, but not in building from
scratch (for now until your changes will be merged).

b) As soon as you get your branch working and merged in develop, you should
change the wiki to conform to the needs of the changes you will introduce
in your branch. I'll be interested in give a hand here and test it againts
an empty repo, and from a Mac, and help to refine the process and the wiki
if needed.

About the planned video, since is a time consuming work maybe better to
postpone until your work is merged so I can create one that doesn't get
obsolete in few days.

It's ok for you?

thanks



El jue., 23 may. 2019 a las 18:29, Alex Harui ()
escribió:

>
>
> On 5/23/19, 3:04 AM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> El jue., 23 may. 2019 a las 3:49, Alex Harui 
( >)
> escribió:
>
> > Before we go too far in any one direction, I may not be able to
> respond
> > fully to this thread today as there seems to be a lot to catch up
> on, but
> > let me try to summarize the goals of the Maven build.
> >
> > 1) There are some helper jars (compiler-build-tools and
> > compiler-jburg-types).  They are built by the "utils" profile.  They
> > haven't changed in develop, but they will change in 0.9.6.  They've
> been
> > changed in the release_practice branch.  So folks will need to use
> the
> > "utils" profile whenever we (rarely) change those jars.
> >
> >
> Ok, so we should put in wiki that utils profile is needed for that
> case,
> but not for "initial" build case. I'm worried to try to simplify
> 

RoyaleUnit Ant Task

[Josh Tynjala]

Hey Royale team,

Over the last several days, I've been working on RoyaleUnit again, and I wanted 
to share a bit about what I've completed this week.

## New  Ant task

Until now, we've been using the  Ant task to run RoyaleUnit tests on 
our SWF output in the Ant builds. The RoyaleUnit library is similar to 
FlexUnit, but it's a completely new implementation that works on both SWF and 
JS. When I first created RoyaleUnit, I could only get SWF output successfully 
communicating with the  Ant task. JS tests could be run manually, but 
they could not be automated in Ant yet, for technical reasons.

On the SWF side, FlexUnit uses XMLSocket to communicate with the  Ant 
task. That was easy enough to port over to RoyaleUnit. However, JS in the 
browser doesn't have a simple socket implementation that would allow it to 
speak the same protocol. The closest thing is WebSocket, but the  Ant 
task doesn't know how to talk to WebSockets. So, I created a new  
Ant task that can still speak XMLSocket with SWF, but also supports WebSocket 
for JS.

Previously, you could specify "flash" or "air" for the player value in the Ant 
task:




I added a new one, "html", that tells the Ant task to use WebSockets.



Then, you can use the swf property to specify the HTML file to launch:



(It was already called "swf" in , but maybe we should rename it or 
provide an alias)

By default, it should use your default web browser. However, if you'd prefer a 
different browser, you can use the command property:



## Ant builds run JS tests

After I got the  Ant task work, I updated our royale-asjs Ant 
builds to run both SWF and JS tests. This was interesting because it needs to 
launch a web browser, and there are some gotchas that I discovered.

In particular, Internet Explorer always requires the user to manually click a 
button to allow JavaScript content to run in a local HTML file. Likewise, the 
first time a local file is launched in Safari, it asks to confirm if you want 
to open it or not. When you try to open the file again later, Safari opens it 
without asking, but that first time isn't ideal.

With the two default browsers not really good candidates, I decided to try 
Chrome and Firefox. I found that both will run scripts without a prompt, but 
they aren't necessarily installed on everyone's systems. So, first it looks for 
Chrome (which is the most popular browser these days), and then it falls back 
to Firefox. If it can't find either one, the build fails with an error.

In the case where a browser cannot be found automatically, there is the option 
to specify a royaleunit.browser property when running the Ant build script. You 
can either add it to your *env.properties* file in the root of royale-asjs, or 
you can specify it on the command line like this:

ant -Droyaleunit.browser=path/to/browser.exe

(On macOS, I think that you need to point to the native executable instead of 
the .app file, like /Applications/Firefox.app/Contents/MacOS/firefox)

When  finishes running JS tests in the browser, it will 
automatically close the browser — except when that browser was already open 
before you started running the tests. In that case, it will simply open a new 
tab, which will remain open after the tests complete. So, it won't make you 
lose all of your existing tabs or anything. However, it may be annoying to have 
a bunch of extra tabs that you need to manually close every time that you run 
the build script. In that case, just like I explained above, you can use the 
royaleunit.browser property in env.properties or via the command line to tell 
the build to run JS tests in a different browser that you prefer. As I 
mentioned, if that browser isn't already open, the build script will exit the 
browser automatically after running tests.

I confirmed that apacheroyaleci on Azure has Firefox installed, and at least 
one build has completed successfully on this server.

Please let me know if this has disrupted anything. However, I think that I 
covered the edge cases pretty well.

- Josh

Build failed in Jenkins: royale-asjs_MXTests #801

[Apache Royale CI Server]

See 


Changes:

[joshtynjala] Basic, Core, RoyaleUnit tests: run both SWF and JS tests

--
[...truncated 604.67 KB...]
[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: Problems building with Maven from scratch

[Carlos Rovira]

Hi Alex,

I'm not getting this working only for me, in fact my motivation was exactly
the opposite. The final motivation is to able to do a short video to post
on an Apache Royale youtube channel, since is something many, many people
requested. And something I think will give us more users and exposure.

I was working without problem each day. I tried to remove repository folder
to simulate a "day 0" like a new user to see if all was working. The result
was it was failing.

Now with a dependency added in compiler's pom and a profile added in the
wiki instructions, I was able to build from scratch. Other's can try this
to proof is a solution for anyone.

IOW, If a new user tries the wiki steps some days ago he'd found royale
didn't build, and fails with the error exposed here, and will get stuck.
Now, hopefully he will get it working.

For me is ok, all you say (maybe the only thing I don't agree is put
skipTests to false as an official way to make maven build work officially,
since in maven tests are mandatory, and you must opt-out, with a profile o
via command line, but official build should work with normal tests in a
first execution).

About having a repository or not: This should not matter, but the fact is
it currently does, independently of what any of us want. I, as you, would
want the simplest way to build, that could be always the same, but there's
a difference in a first maven build of royale against the subsequent
builds, that can be simplified (removing the -s settings... and the
-Pprofile..). I didn't design the process, but is what we have now. So is
important to test against an empty repository folder, unless we change the
build process and get it more simpler, what I don't expect to happen
anytime soon, since all of us have many things on plate right now.

I think we all understand the goals, and that we have two sets of outputs.
Right now, I only know how to get one of them. If there's other one you
know you can post it here and I can put on wiki, or directly modify wiki
page that is the official one. If you can do the second, it would be great
since it will be more accurate to what you have in mind.

If you have no time fo now what we can do is:
2
a) I can reintroduce the "-Putils" line in the wiki as something to do in a
concrete case, since right now (at the time we are writing this), as you
posted is important in a concrete situation, but not in building from
scratch (for now until your changes will be merged).

b) As soon as you get your branch working and merged in develop, you should
change the wiki to conform to the needs of the changes you will introduce
in your branch. I'll be interested in give a hand here and test it againts
an empty repo, and from a Mac, and help to refine the process and the wiki
if needed.

About the planned video, since is a time consuming work maybe better to
postpone until your work is merged so I can create one that doesn't get
obsolete in few days.

It's ok for you?

thanks



El jue., 23 may. 2019 a las 18:29, Alex Harui ()
escribió:

>
>
> On 5/23/19, 3:04 AM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> El jue., 23 may. 2019 a las 3:49, Alex Harui ( >)
> escribió:
>
> > Before we go too far in any one direction, I may not be able to
> respond
> > fully to this thread today as there seems to be a lot to catch up
> on, but
> > let me try to summarize the goals of the Maven build.
> >
> > 1) There are some helper jars (compiler-build-tools and
> > compiler-jburg-types).  They are built by the "utils" profile.  They
> > haven't changed in develop, but they will change in 0.9.6.  They've
> been
> > changed in the release_practice branch.  So folks will need to use
> the
> > "utils" profile whenever we (rarely) change those jars.
> >
> >
> Ok, so we should put in wiki that utils profile is needed for that
> case,
> but not for "initial" build case. I'm worried to try to simplify
> instructions and process to minumun needs to avoid new comers
> confusion.
> So, I'll mention utils profile as a special case to execute when
> needed.
>
> As soon as I merge release_practice into develop, you will need to use the
> utils profile to build from scratch.
>
> > 2) Adobe will probably never publish official playerglobal on Maven.
> > There is a whole bunch of logic in the Mavenizer to address licensing
> > acceptance issues.
> >
>
> For what we discussed in the thread, seems playerglobal is already on
> maven
> official repos, so my guest is we are served with that and don't need
> adobe
> host it in a maven repo.
>
> Adobe has not given permission to distribute playerglobal in this way so
> we cannot use it.
>
> >
> > 3) IIRC, the most recent changes were to allow the Maven build to
> work
> > without requiring SWF versions of artifacts and probably
> > playerglobal/airglobal.  So, adding hard requirements to
> playerglobal will
> > defeat this 

Build failed in Jenkins: royale-asjs_MXTests #800

[Apache Royale CI Server]

See 


Changes:

[joshtynjala] Basic, Core, RoyaleUnit: removed browser property from test build 
script

[joshtynjala] Basic tests: fixed incorrect reference to Core

[joshtynjala] BasicJS, CoreJS, RoyaleUnitJS: changed browser property to

[joshtynjala] CoreJS, BasicJS, RoyaleUnitJS tests: checks that path to

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

Re: 0.9.6 Release

[Alex Harui]

It has turned out to be harder than expected to get the same binaries on Mac 
and Win.  I now have the identical binaries for royale-compiler and 
royale-typedefs Maven artifacts and am starting on royale-asjs.  I might get 
lucky and the changes that fixed royale-typedefs SWCs will magically get the 
royale-asjs SWCs to match.  Then we have to make the Ant artifacts match.

There have been a lot of distractions in my non-work life which has also 
impeded progress.  I hope to make much progress this coming week and if we're 
lucky, I will be asking for a volunteer (or volunteers) to test drive all of 
this stuff and be the RM for 0.9.6.  I am not going to be the RM.

-Alex

On 5/23/19, 9:39 AM, "Piotr Zarzycki"  wrote:

Hi Alex,

It's been a while since you have started effort with automating build.
Where are you with that ? Are we closer to started 0.9.6. Do you need any
help with this ?

Thanks,
Piotr

wt., 2 kwi 2019 o 19:30 Alex Harui  napisał(a):

> Update:
>
> In order to make verification of binary release packages created on the
> server easier, I have made changes to our build scripts and tools to try 
to
> generate reproducible binaries.  I've seen two different builds compare on
> my Mac.   The next challenge will be to see if the server can build a
> package on Windows that will compare on Mac.
>
> One of the changes I needed to make is to JBurg.  The version of JBurg we
> use generates method names including a hash that doesn't reproduce the 
same
> name each time.  I have changes to JBurg ready, however JBurg is currently
> under CPL which is category B.  We only need one file, we don't need or
> want all of JBurg at this time.  The one JBurg file is jointly owned by
> Adobe and Tom Harwood.  I've contact Tom and he will be filing an ICLA and
> has given me permission to commit the lines he owns in that one file.
>
> This is the revision of the file that will be donated by Tom/Adobe.
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fjburg%2Fcode%2Fci%2F66c287943376a74ac791f3d3bf969ab160bf80ff%2Ftree%2Fsrc%2Fgenerator%2Fjburg%2Fburg%2FJBurgGenerator.javadata=02%7C01%7Caharui%40adobe.com%7C74ccc0a4a31440c0651708d6df9d4326%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636942263907528095sdata=1p0EhJm%2Be7CdkNlE5MHMEJ9EoPINgBGKVU6hlE8C0kQ%3Dreserved=0
>
> Once this file goes in with the changes to keep the method names the same,
> there will be more tweaks to the release tasks and then we can try cutting
> a release.  I'm thinking we'll be at that point in early May, so now is 
the
> time to get stuff in for the 0.9.6 release.
>
> Thanks,
> -Alex
>
> On 3/8/19, 9:27 AM, "Alex Harui"  wrote:
>
> I would much rather have others find and fix issues themselves.  That
> way, more people than just me will know how to maintain the system.  It
> actually turns out that, IMO, a group of people can work on the release.
> There are 14 steps.  Literally, 14 different people could execute one step
> each.
>
> My 2 cents,
> -Alex
>
> On 3/8/19, 2:13 AM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> amazing work! congrats to reach to this point! :)
>
> I need to put my head on all of this, but count on me to be a RM.
> I think
> the best thing should be that you be the first RM to try your own
> development at least for the first time, and then the rest of us
> will
> follow you on the next releases. With all this on place we maybe
> could
> release once a month or every two months...
>
> Thanks for doing this :)
>
> Carlos
>
>
> El vie., 8 mar. 2019 a las 1:55, Alex Harui
> ()
> escribió:
>
> > OK, I've now seen Jenkins perform the steps to build the release
> > artifacts.  Folks interested in Docker-izing the steps are
> welcome to look
> > at the jobs on the "Royale Release" tab on the CI server.
> >
> 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroyaleci.westus2.cloudapp.azure.com%3A8080%2Fview%2FRoyale%2520Release%2Fdata=02%7C01%7Caharui%40adobe.com%7C74ccc0a4a31440c0651708d6df9d4326%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636942263907528095sdata=OtDqx0O91trBGYlhEimqYdhTiJXhsCw1YRe6uaV9OF8%3Dreserved=0
> >
> > These steps assume that the RM can run the basic Maven and Ant
> build on
> > the RM's computer. I think that's a fair requirement since all
> of us on the
> > PMC need to able to do that to build the RC in order to vote on
> it.
> >  Jenkins does other tasks like run the Maven release plugin
> steps.
>

Re: 0.9.6 Release

[Piotr Zarzycki]

Hi Alex,

It's been a while since you have started effort with automating build.
Where are you with that ? Are we closer to started 0.9.6. Do you need any
help with this ?

Thanks,
Piotr

wt., 2 kwi 2019 o 19:30 Alex Harui  napisał(a):

> Update:
>
> In order to make verification of binary release packages created on the
> server easier, I have made changes to our build scripts and tools to try to
> generate reproducible binaries.  I've seen two different builds compare on
> my Mac.   The next challenge will be to see if the server can build a
> package on Windows that will compare on Mac.
>
> One of the changes I needed to make is to JBurg.  The version of JBurg we
> use generates method names including a hash that doesn't reproduce the same
> name each time.  I have changes to JBurg ready, however JBurg is currently
> under CPL which is category B.  We only need one file, we don't need or
> want all of JBurg at this time.  The one JBurg file is jointly owned by
> Adobe and Tom Harwood.  I've contact Tom and he will be filing an ICLA and
> has given me permission to commit the lines he owns in that one file.
>
> This is the revision of the file that will be donated by Tom/Adobe.
>
> https://sourceforge.net/p/jburg/code/ci/66c287943376a74ac791f3d3bf969ab160bf80ff/tree/src/generator/jburg/burg/JBurgGenerator.java
>
> Once this file goes in with the changes to keep the method names the same,
> there will be more tweaks to the release tasks and then we can try cutting
> a release.  I'm thinking we'll be at that point in early May, so now is the
> time to get stuff in for the 0.9.6 release.
>
> Thanks,
> -Alex
>
> On 3/8/19, 9:27 AM, "Alex Harui"  wrote:
>
> I would much rather have others find and fix issues themselves.  That
> way, more people than just me will know how to maintain the system.  It
> actually turns out that, IMO, a group of people can work on the release.
> There are 14 steps.  Literally, 14 different people could execute one step
> each.
>
> My 2 cents,
> -Alex
>
> On 3/8/19, 2:13 AM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> amazing work! congrats to reach to this point! :)
>
> I need to put my head on all of this, but count on me to be a RM.
> I think
> the best thing should be that you be the first RM to try your own
> development at least for the first time, and then the rest of us
> will
> follow you on the next releases. With all this on place we maybe
> could
> release once a month or every two months...
>
> Thanks for doing this :)
>
> Carlos
>
>
> El vie., 8 mar. 2019 a las 1:55, Alex Harui
> ()
> escribió:
>
> > OK, I've now seen Jenkins perform the steps to build the release
> > artifacts.  Folks interested in Docker-izing the steps are
> welcome to look
> > at the jobs on the "Royale Release" tab on the CI server.
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroyaleci.westus2.cloudapp.azure.com%3A8080%2Fview%2FRoyale%2520Release%2Fdata=02%7C01%7Caharui%40adobe.com%7C46d1fe9de1214422ce9f08d6a3aec4d2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636876368352984672sdata=iVyd9X1U0qVPwCk0ZW9xa7YsPp64EgAxgIwljR7VbNs%3Dreserved=0
> >
> > These steps assume that the RM can run the basic Maven and Ant
> build on
> > the RM's computer. I think that's a fair requirement since all
> of us on the
> > PMC need to able to do that to build the RC in order to vote on
> it.
> >  Jenkins does other tasks like run the Maven release plugin
> steps.
> >
> > Currently that results in binaries on Jenkins that are
> downloaded to the
> > RM's computer.  These binaries need to be verified by the RM
> which is the
> > next phase I will be starting on now.  The RM verifies the bits
> and then
> > PGP signs them.  And then the bits are uploaded off the RM's
> computer to
> > Maven Staging or dist.a.o/dev.   If that uploading turns out to
> be a point
> > of failure, we have the option of having Jenkins upload the big
> files and
> > have the RM only upload PGP signature files.  Or finding a way
> for Jenkins
> > to get the signature files from the RM.  The uploads worked fine
> for me,
> > but then again, so did the old script's uploads.
> >
> > Therefore, once I get the binary verification phase completed, I
> think
> > someone other than me should be the RM and try to use these
> steps to
> > generate the release and help debug the process for the next
> RM.  So,
> > please try to carve out some time to be the RM.  One advantage
> of doing
> > most of the work on Jenkins is that it frees up my computer to
> do other
> > things while Jenkins is cranking away.
> >
> > I think we're at least a week away from binary verification,
> maybe two, so
> > 

Re: Problems building with Maven from scratch

[Alex Harui]

On 5/23/19, 3:04 AM, "Carlos Rovira"  wrote:

Hi Alex,

El jue., 23 may. 2019 a las 3:49, Alex Harui ()
escribió:

> Before we go too far in any one direction, I may not be able to respond
> fully to this thread today as there seems to be a lot to catch up on, but
> let me try to summarize the goals of the Maven build.
>
> 1) There are some helper jars (compiler-build-tools and
> compiler-jburg-types).  They are built by the "utils" profile.  They
> haven't changed in develop, but they will change in 0.9.6.  They've been
> changed in the release_practice branch.  So folks will need to use the
> "utils" profile whenever we (rarely) change those jars.
>
>
Ok, so we should put in wiki that utils profile is needed for that case,
but not for "initial" build case. I'm worried to try to simplify
instructions and process to minumun needs to avoid new comers confusion.
So, I'll mention utils profile as a special case to execute when needed.

As soon as I merge release_practice into develop, you will need to use the 
utils profile to build from scratch.

> 2) Adobe will probably never publish official playerglobal on Maven.
> There is a whole bunch of logic in the Mavenizer to address licensing
> acceptance issues.
>

For what we discussed in the thread, seems playerglobal is already on maven
official repos, so my guest is we are served with that and don't need adobe
host it in a maven repo.

Adobe has not given permission to distribute playerglobal in this way so we 
cannot use it.

>
> 3) IIRC, the most recent changes were to allow the Maven build to work
> without requiring SWF versions of artifacts and probably
> playerglobal/airglobal.  So, adding hard requirements to playerglobal will
> defeat this capability unless those dependencies are in the appropriate
> Maven profile.
>

Right now we need to do this:

mvn -s settings-template.xml clean install -Pgenerate-swcs-for-swf
so this means something is not working ok in a clean environment for first
build/install?
For now, the current instructions works, but if that's the case, we should
try to fix this in the future, although seems this is not urgent while
people is capable of build Royale in the current way.

The goal for Maven, like the goal for the Ant builds, is to not require Adobe 
artifacts and build JS-only versions.  Building SWF versions is opt-in.  I'm 
not surprised there are bugs after these changes, but the solutions should 
consider that there are two different sets of output.

>
> 4) The CI builds (builds.a.o and apachroyalecibuild) are good reference
> examples of Maven building things correctly on Windows.  You can compare
> your setup and console output to those builds.
>

I was building without problem and still can build without problem. My
concern was for the case people tries to build maven for the first time,
and was where I found problems. This problems are as well not reproduced in
machines that are already working, since they pass the initial setup.


>
> 5) There might be some assumption that airglobal and/or playerglobal exist
> to determine whether the build is going to try to output SWF versions of
> the artifacts or not.
>
> 6) The default, IIRC, is to not require airglobal/playerglobal and build a
> JS-Only set of artifacts similar to how it is done in the Ant builds.
>

So, this wiki walkthrough:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FBuild-Apache-Royale-with-Mavendata=02%7C01%7Caharui%40adobe.com%7Cf3c261d90f824385445a08d6df65f91c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636942026440791368sdata=wTZxsgMFU%2Fb8FSW%2BiuHCYfTk50wAIDEQBWi8yy1KjN8%3Dreserved=0
is describing whole process without differentiation.
can be updated to build with maven SWF/JS and in the other hand only JS?
I think the actual page description us for SWF/JS, and I personally never
try / or know how to build just JS, what would be very interesting since
many people will really only build for JS, and if sometime in the future we
have other interesting target like WebAsembly, will want to add it and
build JS/WEBASM

I was unaware of the page so it didn’t get updated with these changes to not 
require SWF artifacts.  So it does need updating, but it would be best to first 
make it clear that there are two sets of output.

>
> Unfortunately, that means that most of the ideas I've read while skimming
> over this thread so far may not be correct.
>

I think you have to have in mind that we all was working right with our
current environment and that the problem comes from try to start from
scratch. Subsequents builds instructions are 

Re: [royale-asjs] branch develop updated: Build files for JS libraries find the compilers....

[Josh Tynjala]

In a new, empty folder, I was able to run the following commands successfully:

git clone g...@github.com:apache/royale-asjs.git
cd royale-asjs
ant all

- Josh

On 2019/05/23 15:59:10, Josh Tynjala  wrote: 
> Hey Alex,
> 
> I'll be sure give it a try and make any necessary fixes, if it doesn't work.
> 
> - Josh
> 
> On 2019/05/23 01:22:23, Alex Harui  wrote: 
> > Please make sure "ant all" from a newly cloned royale-asjs repo is not 
> > broken by this change.
> > 
> > Thanks,
> > -Alex
> > 
> > On 5/22/19, 11:12 AM, "joshtynj...@apache.org"  
> > wrote:
> > 
> > This is an automated email from the ASF dual-hosted git repository.
> > 
> > joshtynjala pushed a commit to branch develop
> > in repository 
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git=02%7C01%7Caharui%40adobe.com%7C54fe9df3ab3848d42b6a08d6dee1081e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636941455501423441=GxfNLG%2FX%2FbcninbFt5K0XG9vxFHblQr5YMIuYtP1%2F4Y%3D=0
> > 
> > 
> > The following commit(s) were added to refs/heads/develop by this push:
> >  new e18d7d7  Build files for JS libraries find the compilers the 
> > same way as the build files for SWF libraries
> > e18d7d7 is described below
> > 
> > commit e18d7d747cd7898f04f07e91f2c71b217275340f
> > Author: Josh Tynjala 
> > AuthorDate: Wed May 22 11:11:54 2019 -0700
> > 
> > Build files for JS libraries find the compilers the same way as the 
> > build files for SWF libraries
> > 
> > Previously, the inconsistent detection could cause JS and SWF 
> > libraries to be built with different local compilers. It also caused JS 
> > builds to fail to find closure-lib in some cases.
> > ---
> >  frameworks/js/projects/AceJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/BasicJS/build.xml   | 34 
> > ++-
> >  frameworks/js/projects/BindingJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/ChartsJS/build.xml  | 34 
> > ++-
> >  frameworks/js/projects/CollectionsJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/CoreJS/build.xml| 34 
> > ++-
> >  frameworks/js/projects/CreateJSJS/build.xml| 34 
> > ++-
> >  frameworks/js/projects/DragDropJS/build.xml| 34 
> > ++-
> >  frameworks/js/projects/EffectsJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/ExpressJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/FlatJS/build.xml| 34 
> > ++-
> >  frameworks/js/projects/FontAwesomeJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/FormattersJS/build.xml  | 34 
> > ++-
> >  frameworks/js/projects/GoogleMapsJS/build.xml  | 34 
> > ++-
> >  frameworks/js/projects/GraphicsJS/build.xml| 34 
> > ++-
> >  frameworks/js/projects/HTML5JS/build.xml   | 34 
> > ++-
> >  frameworks/js/projects/HTMLJS/build.xml| 34 
> > ++-
> >  frameworks/js/projects/IconsJS/build.xml   | 34 
> > ++-
> >  frameworks/js/projects/JQueryJS/build.xml  | 34 
> > ++-
> >  frameworks/js/projects/JewelJS/build.xml   | 34 
> > ++-
> >  frameworks/js/projects/LanguageJS/build.xml| 34 
> > ++-
> >  frameworks/js/projects/MXRoyaleJS/build.xml| 34 
> > ++-
> >  .../js/projects/MaterialDesignLiteJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/MobileJS/build.xml  | 34 
> > ++-
> >  frameworks/js/projects/NetworkJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/ReflectionJS/build.xml  | 34 
> > ++-
> >  frameworks/js/projects/RoyaleSiteJS/build.xml  | 34 
> > ++-
> >  frameworks/js/projects/RoyaleUnitJS/build.xml  | 34 
> > ++-
> >  frameworks/js/projects/SparkRoyaleJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/StorageJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/TLFJS/build.xml | 34 
> > ++-
> >  frameworks/js/projects/TextJS/build.xml| 34 
> > ++-
> >  frameworks/js/projects/XMLJS/build.xml | 38 
> > +++---
> >  33 files changed, 332 insertions(+), 794 deletions(-)
> > 
> > diff --git a/frameworks/js/projects/AceJS/build.xml 
> > b/frameworks/js/projects/AceJS/build.xml
> > index 5aabe59..b1444d2 100644
> > --- 

Re: [royale-asjs] branch develop updated: Build files for JS libraries find the compilers...

[Josh Tynjala]

Hey Alex,

I'll be sure give it a try and make any necessary fixes, if it doesn't work.

- Josh

On 2019/05/23 01:22:23, Alex Harui  wrote: 
> Please make sure "ant all" from a newly cloned royale-asjs repo is not broken 
> by this change.
> 
> Thanks,
> -Alex
> 
> On 5/22/19, 11:12 AM, "joshtynj...@apache.org"  
> wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> joshtynjala pushed a commit to branch develop
> in repository 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git=02%7C01%7Caharui%40adobe.com%7C54fe9df3ab3848d42b6a08d6dee1081e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636941455501423441=GxfNLG%2FX%2FbcninbFt5K0XG9vxFHblQr5YMIuYtP1%2F4Y%3D=0
> 
> 
> The following commit(s) were added to refs/heads/develop by this push:
>  new e18d7d7  Build files for JS libraries find the compilers the 
> same way as the build files for SWF libraries
> e18d7d7 is described below
> 
> commit e18d7d747cd7898f04f07e91f2c71b217275340f
> Author: Josh Tynjala 
> AuthorDate: Wed May 22 11:11:54 2019 -0700
> 
> Build files for JS libraries find the compilers the same way as the 
> build files for SWF libraries
> 
> Previously, the inconsistent detection could cause JS and SWF 
> libraries to be built with different local compilers. It also caused JS 
> builds to fail to find closure-lib in some cases.
> ---
>  frameworks/js/projects/AceJS/build.xml | 34 
> ++-
>  frameworks/js/projects/BasicJS/build.xml   | 34 
> ++-
>  frameworks/js/projects/BindingJS/build.xml | 34 
> ++-
>  frameworks/js/projects/ChartsJS/build.xml  | 34 
> ++-
>  frameworks/js/projects/CollectionsJS/build.xml | 34 
> ++-
>  frameworks/js/projects/CoreJS/build.xml| 34 
> ++-
>  frameworks/js/projects/CreateJSJS/build.xml| 34 
> ++-
>  frameworks/js/projects/DragDropJS/build.xml| 34 
> ++-
>  frameworks/js/projects/EffectsJS/build.xml | 34 
> ++-
>  frameworks/js/projects/ExpressJS/build.xml | 34 
> ++-
>  frameworks/js/projects/FlatJS/build.xml| 34 
> ++-
>  frameworks/js/projects/FontAwesomeJS/build.xml | 34 
> ++-
>  frameworks/js/projects/FormattersJS/build.xml  | 34 
> ++-
>  frameworks/js/projects/GoogleMapsJS/build.xml  | 34 
> ++-
>  frameworks/js/projects/GraphicsJS/build.xml| 34 
> ++-
>  frameworks/js/projects/HTML5JS/build.xml   | 34 
> ++-
>  frameworks/js/projects/HTMLJS/build.xml| 34 
> ++-
>  frameworks/js/projects/IconsJS/build.xml   | 34 
> ++-
>  frameworks/js/projects/JQueryJS/build.xml  | 34 
> ++-
>  frameworks/js/projects/JewelJS/build.xml   | 34 
> ++-
>  frameworks/js/projects/LanguageJS/build.xml| 34 
> ++-
>  frameworks/js/projects/MXRoyaleJS/build.xml| 34 
> ++-
>  .../js/projects/MaterialDesignLiteJS/build.xml | 34 
> ++-
>  frameworks/js/projects/MobileJS/build.xml  | 34 
> ++-
>  frameworks/js/projects/NetworkJS/build.xml | 34 
> ++-
>  frameworks/js/projects/ReflectionJS/build.xml  | 34 
> ++-
>  frameworks/js/projects/RoyaleSiteJS/build.xml  | 34 
> ++-
>  frameworks/js/projects/RoyaleUnitJS/build.xml  | 34 
> ++-
>  frameworks/js/projects/SparkRoyaleJS/build.xml | 34 
> ++-
>  frameworks/js/projects/StorageJS/build.xml | 34 
> ++-
>  frameworks/js/projects/TLFJS/build.xml | 34 
> ++-
>  frameworks/js/projects/TextJS/build.xml| 34 
> ++-
>  frameworks/js/projects/XMLJS/build.xml | 38 
> +++---
>  33 files changed, 332 insertions(+), 794 deletions(-)
> 
> diff --git a/frameworks/js/projects/AceJS/build.xml 
> b/frameworks/js/projects/AceJS/build.xml
> index 5aabe59..b1444d2 100644
> --- a/frameworks/js/projects/AceJS/build.xml
> +++ b/frameworks/js/projects/AceJS/build.xml
> @@ -76,46 +76,32 @@
>  
>  
>  
> -
> + depends="check-compiler-home,check-transpiler-home">
>  
>   includes="compiler-royaleTasks.jar"/>
>  
>  
>  
>  
> - -description="Check 

Re: [royale-compiler] branch develop updated: PackageFooterEmitter: added missing ROYALE_...

[Josh Tynjala]

Hey Greg,

It would be great to see some more tests using RoyaleUnit get added! Since I 
gave the  Ant task the ability to communicate over WebSockets for 
JS/HTML, we'll soon be able to automatically catch any unexpected differences 
between SWF and JS versions. I haven't enabled the JS tests in the full 
royale-asjs Ant build yet, but I hope to do that later today after I make a few 
minor tweaks. (I'll post a more detailed thread about my changes too!)

Porting your tests from FlexUnit to RoyaleUnit should be straightforward, as 
long as you aren't using any of the Async stuff. I haven't had a chance to 
implement that yet. For synchronous tests, you may not need to do anything, but 
if you have references to FlexUnit's Suite class, then you should only need to 
change that to RoyaleUnit's implementation of the Suite class instead.

- Josh

On 2019/05/22 22:56:58, Greg Dove  wrote: 
> Sorry I only followed this on the email pings, and I did see the commit
> message Josh, but I was wondering how and why there was a need to reflect
> into the 'private' class in the first place. Obviously RoyaleUnit does that
> somewhere, thanks for explaining.
> 
> Perhaps it can still be possible to add an optimization because I imagine
> this is an unusual case for reflection although the optimization could be a
> little complicated I guess. For example, if there is never anything in the
> public class that publicly exposes a private class or instance of a private
> class, then I don't expect that local private class would need reflection
> data. Seems low priority, but I will keep it in mind.
> 
> btw congrats on your progress with RoyaleUnit. So pleased to see that. When
> I originally worked on reflection stuff a few years back it was with the
> goal of getting some sort of unit testing approach in place.
> I set up something very basic that I find useful for quick iterative
> comparisons between JS and SWF, based on an experience I had a number of
> years ago working with multiple (8+) Haxe targets and running those unit
> tests for all of them side by side with a browser view of all results. It
> was a very accessible way to contribute to, in many cases, multiple
> targets. I think they may have changed how that works now, not sure, I
> believe they also have more CI focus now.
> Anyhow, I should have a lot of unit tests that will hopefully be mostly
> compatible and therefore easily ported to your RoyaleUnit - they were
> originally set up to be compatible with FlexUnit and I was able to
> copy/paste into the FlexUnit setup, but some of the Test classes I am using
> do have allowances for known variance between for JS and SWF.
> I will try RoyaleUnit soon and see if can port some of the tests from
> manualtests/UnitTests
> 
> 
> 
> 
> On Thu, May 23, 2019 at 10:30 AM Josh Tynjala 
> wrote:
> 
> > Hi Greg,
> >
> > Indeed, supporting describeType() is exactly why I made this change.
> >
> > From my commit message:
> >
> > > Fixes issue where describeType() could not be used on file-internal
> > > classes because the reflection info was missing
> >
> > I discovered this issue when trying to get the framework's RoyaleUnit
> > tests to run in JS with the  Ant task. RoyaleUnit uses
> > reflection to detect metadata on classes.
> >
> > In the tests that RoyaleUnit runs on itself, I created some mock test
> > classes that are file-internal:
> >
> >
> > https://github.com/apache/royale-asjs/blob/develop/frameworks/projects/RoyaleUnit/src/test/royale/tests/BeforeAndAfterTests.as
> >
> > Without this reflection data, the app crashes in JS because
> > ROYALE_REFLECTION_DATA is missing. This code has been working fine in SWF
> > for a while now, so I had no reason to believe it would break when I
> > finally got around to building the same app for JS.
> >
> > - Josh
> >
> > On 2019/05/22 22:10:54, Greg Dove  wrote:
> > > Actually there is one exception I thought of, and verified 
> > >
> > > describeType works in avm if the private class is exposed via the public
> > > class
> > > new TestClass().getPrivateClass()
> > >
> > > But getDefinitionByName
> > > and ApplicationDomain.currentDomain.getQualifiedDefinitionNames() do not
> > > seem to know about it.
> > >
> > > Anyway, keen to hear more. If it's needed so be it (in which case my
> > > original attempt to optimize was invalid).
> > >
> > >
> > >
> > > On Thu, May 23, 2019 at 9:58 AM Greg Dove  wrote:
> > >
> > > >
> > > > I just did a quick test using Adobe animate:
> > > > trace(ApplicationDomain.currentDomain.getQualifiedDefinitionNames())
> > > >
> > > > The private internal classes are not available generally.
> > > >
> > > > If I add a public member to the public class in the file that has a
> > type
> > > > corresponding to a file private class, the string name of the private
> > class
> > > > is represented via describeType. But it throws an error if I try to use
> > > > that subsequently via getDefinitionByName. Maybe there is something
> > extra I
> > > > 

Build failed in Jenkins: royale-asjs_MXTests #799

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

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

[Apache Royale CI Server]

See 

Re: Problems building with Maven from scratch

[Carlos Rovira]

Hi Alex,

El jue., 23 may. 2019 a las 3:49, Alex Harui ()
escribió:

> Before we go too far in any one direction, I may not be able to respond
> fully to this thread today as there seems to be a lot to catch up on, but
> let me try to summarize the goals of the Maven build.
>
> 1) There are some helper jars (compiler-build-tools and
> compiler-jburg-types).  They are built by the "utils" profile.  They
> haven't changed in develop, but they will change in 0.9.6.  They've been
> changed in the release_practice branch.  So folks will need to use the
> "utils" profile whenever we (rarely) change those jars.
>
>
Ok, so we should put in wiki that utils profile is needed for that case,
but not for "initial" build case. I'm worried to try to simplify
instructions and process to minumun needs to avoid new comers confusion.
So, I'll mention utils profile as a special case to execute when needed.


> 2) Adobe will probably never publish official playerglobal on Maven.
> There is a whole bunch of logic in the Mavenizer to address licensing
> acceptance issues.
>

For what we discussed in the thread, seems playerglobal is already on maven
official repos, so my guest is we are served with that and don't need adobe
host it in a maven repo.


>
> 3) IIRC, the most recent changes were to allow the Maven build to work
> without requiring SWF versions of artifacts and probably
> playerglobal/airglobal.  So, adding hard requirements to playerglobal will
> defeat this capability unless those dependencies are in the appropriate
> Maven profile.
>

Right now we need to do this:

mvn -s settings-template.xml clean install -Pgenerate-swcs-for-swf
so this means something is not working ok in a clean environment for first
build/install?
For now, the current instructions works, but if that's the case, we should
try to fix this in the future, although seems this is not urgent while
people is capable of build Royale in the current way.


>
> 4) The CI builds (builds.a.o and apachroyalecibuild) are good reference
> examples of Maven building things correctly on Windows.  You can compare
> your setup and console output to those builds.
>

I was building without problem and still can build without problem. My
concern was for the case people tries to build maven for the first time,
and was where I found problems. This problems are as well not reproduced in
machines that are already working, since they pass the initial setup.


>
> 5) There might be some assumption that airglobal and/or playerglobal exist
> to determine whether the build is going to try to output SWF versions of
> the artifacts or not.
>
> 6) The default, IIRC, is to not require airglobal/playerglobal and build a
> JS-Only set of artifacts similar to how it is done in the Ant builds.
>

So, this wiki walkthrough:
https://github.com/apache/royale-asjs/wiki/Build-Apache-Royale-with-Maven
is describing whole process without differentiation.
can be updated to build with maven SWF/JS and in the other hand only JS?
I think the actual page description us for SWF/JS, and I personally never
try / or know how to build just JS, what would be very interesting since
many people will really only build for JS, and if sometime in the future we
have other interesting target like WebAsembly, will want to add it and
build JS/WEBASM


>
> Unfortunately, that means that most of the ideas I've read while skimming
> over this thread so far may not be correct.
>

I think you have to have in mind that we all was working right with our
current environment and that the problem comes from try to start from
scratch. Subsequents builds instructions are simpler since requires shorter
instructions.
You should try to rename your "repository" folder and create a new one and
try to build with maven to see what you find and if we can improve actual
findings.

Thanks Alex!

Carlos



>
> HTH,
> -Alex
>
> On 5/22/19, 12:17 PM, "Greg Dove"  wrote:
>
> Hi Carlos,
>
> Seems like you have made great progress - well done!
>
> re:
>
> "Seems player global is available here?
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmvnrepository.com%2Fartifact%2Fcom.adobe.flash.framework%2Fplayerglobaldata=02%7C01%7Caharui%40adobe.com%7Ca56f03d9d16e4b1511e708d6deea2df7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636941494755181756sdata=m7eGCEle51O%2BT3Yri9Ob2XWoEsLHcNNx0mVXcMyMRhI%3Dreserved=0
> Could we use this? "
>
> I used that one as well yesterday, but iiuc that is actually at:
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Frepository.jspresso.org%2Fmaven2%2Fdata=02%7C01%7Caharui%40adobe.com%7Ca56f03d9d16e4b1511e708d6deea2df7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636941494755191755sdata=%2BABLeHwUx9DEep%2B6qGDRt7oYxKAUVmSw6NZtB%2FDrqX8%3Dreserved=0
> It did not work under https and I don't know what status that has in
> terms
> of its validity etc. Maybe it's ok, but I would assume something
> official
> from Adobe would be better 

Re: Problems building with Maven from scratch

[Carlos Rovira]

Hi Greg,

El mié., 22 may. 2019 a las 21:17, Greg Dove ()
escribió:

> Hi Carlos,
>
> Seems like you have made great progress - well done!
>
> re:
>
> "Seems player global is available here?
> https://mvnrepository.com/artifact/com.adobe.flash.framework/playerglobal
> Could we use this? "
>
> I used that one as well yesterday, but iiuc that is actually at:
> http://repository.jspresso.org/maven2/
> It did not work under https and I don't know what status that has in terms
> of its validity etc. Maybe it's ok, but I would assume something official
> from Adobe would be better (if possible).
>
>
>From my experience testing all the environment seems finally that is does
not needed.
What I understand (maybe I could be wrong) the extension.xml is what does
the magic for flash player.



> For the extension.xml inside .mvn folder I did not try commenting that it
> in the compiler build. I only did that in the asjs build and it did not
> affect things. Maybe it does something, but I only saw warnings.
>
>
I only commented extension in royale-asjs repo, and my testing was on that
part not compiler.
I was not aware that the extension was as well present in compiler part.
But I assume commenting it will do the same as in ASJS repo and will make
the compiler repo fails to build,
so I think we should maintain that part





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

[GitHub] [royale-docs] piotrzarzycki21 merged pull request #23: Remove empty link from page content and toc menu

[GitBox]

piotrzarzycki21 merged pull request #23: Remove empty link from page content 
and toc menu
URL: https://github.com/apache/royale-docs/pull/23
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Language improvements

[Greg Dove]

Re XMLTest manualtest...

Yep those were the ones I ported, Harbs. I think I got them all but may
have missed some. I added a bunch more as well. Hopefully these can be
easily migrated to what Josh has been working on.


On Thu, 23 May 2019, 19:43 Harbs,  wrote:

> As far as XML unit tests go, the starting point should be XMLTest in
> manual tests. (Almost) every time I ran into an issue, I added it to that
> project.
>
> I think I might have been lax on the last few issues I fixed, so we should
> probably go through the later XML commits and make sure we have tests for
> that.
>
> As far as Node goes, I think we probably need conditional Node compilation
> to handle Node-specific (and browser specific) code in a PAYG way.
>
> To technically handle the parsing, something like
> https://github.com/isaacs/sax-js  is a
> good starting point and something like this
> https://github.com/nfarina/xmldoc 
> might be useful to either use or modify.
>
> Harbs
>
> > On May 23, 2019, at 10:18 AM, Greg Dove  wrote:
> >
> > All, I started porting some adhoc XML tests to UnitTests and eventually
> > ended up spending quite a bit of time on addressing issues that arose for
> > XML before getting back to Vector stuff.
> > I think XML probably needs many more unit tests before we get to 1.0
> > because it has an extensive api. I have not used royale with Node yet,
> but
> > XML also needs some thought about how to get it working on Node, I
> assume.
> > Because XML uses the browser's parser and Node does not have one by
> > default, then using the same code will need something to take the place
> of
> > the browser's native parser for Node. There is a lib in npm that might be
> > useful for that, but I don't know how that might work with licence etc.
> > Anyhow, that is just an observation, I will focus on Vector in this
> > thread... I will post here late tomorrow local time with more info, and
> > discussion points. I am keen to see this merged in, but also keen to get
> > buy-in first.
> >
> >
> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira 
> > wrote:
> >
> >> Hi Greg,
> >>
> >> thanks for reporting. I can share here that I was able to test your
> branch
> >> with our real project and seems all goes well.
> >> Could make a intense test, but almost app is working and we found just a
> >> few type error coercions that your code was able to catch (so great! :))
> >> and must be solved as you merge the branch in.
> >>
> >> I think that if Vector is something new and others don't have problems,
> the
> >> branch can be merged and Vector discussions can be done after that,
> since
> >> it will not break anything since there's no uses of that code since is
> new,
> >> but the other changes can be very beneficial
> >>
> >> thanks in advance for your progress in all this stuff :)
> >>
> >> Carlos
> >>
> >>
> >>
> >>
> >>
> >>
> >> El vie., 10 may. 2019 a las 8:44, Greg Dove ()
> >> escribió:
> >>
> >>> All, I am really sorry, I keep thinking I will be able to get back to
> >> this,
> >>> but I have some other personal things taking my spare time at the
> moment.
> >>> These will be done in 2 days, and I then will update the branch with
> some
> >>> extra stuff, and continue this discussion with a focus on Vector
> >> (bringing
> >>> some other relevant discussion on the same topic from Alex as well) at
> >> that
> >>> time. Sorry to set the wrong expectations earlier.
> >>>
> >>>
> >>> On Tue, May 7, 2019 at 9:01 AM Greg Dove  wrote:
> >>>
>  Thanks for the feedback, Josh, Carlos, Alex.
> 
>  js-complex-implicit-coercions
>  js-resolve-uncertain
>  js-vector-index-checks
> 
>  I will make those changes for compiler settings at some point in the
>  branch later today, invert the config default values to match, and
> swap
> >>> all
>  'off' settings in the framework builds (ant and maven) from true to
> >>> false.
>  I will also add compiler tests for these settings (either today or
>  tomorrow). At the moment I only tested the new settings in the code
> >>> result
>  tests in javascript.
> 
>  In another day or two I will post a call to discuss the Vector
>  implementation in more detail. For Vectors, the js-vector-index-checks
> >>> was
>  the obvious first candidate for dialing back on the impact of runtime
>  type-checking, but there are a number of options for 'dialing' other
>  aspects back (or even forward) and choosing the scope of their effect
>  (local code, local project, or entire codebase code including external
>  swcs). I already had stub code for the start of something else to
> >> remove
>  typechecking in mutation methods ('push', 'shift', 'pop' etc) but
> >> removed
>  it in favour of discussing and reviewing it first.  Coming up with a
>  'usable' set of options will really benefit from your collective
> input,
> >>> so
>  I hope you can 

Re: [royale-asjs] 05/07: refactor private beads to correspond to different requirements between targets

[Alex Harui]

Ideally, there wouldn't be an HTMLElementWrapper at all on the SWF side since 
there is no HTMLElement to wrap.

I would rather we find a way to get rid of HTMLElementWrapper on the SWF side 
in order to prove that we don't need the same set of base classes on each 
platform.  In fact, there might be a way to put the "override" in a 
"COMPILE::JS" block in UIBase.

My 2 cents,
-Alex

On 5/23/19, 12:05 AM, "gregd...@apache.org"  wrote:

This is an automated email from the ASF dual-hosted git repository.

gregdove pushed a commit to branch improvements/Language
in repository 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.gitdata=02%7C01%7Caharui%40adobe.com%7Cfab4455dfe08412f9edd08d6df4d0f98%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636941919434601918sdata=Vn82YDCwic7rTP%2BXXAq8IxK9%2Fi%2FGAmEuldRkVLr0gXs%3Dreserved=0

commit bce6ba5a778372f10f60ba4f7af872da56740a39
Author: greg-dove 
AuthorDate: Thu May 23 18:30:06 2019 +1200

refactor private beads to correspond to different requirements between 
targets
---
 .../main/royale/org/apache/royale/core/UIBase.as   |  99 ++
 .../org/apache/royale/core/HTMLElementWrapper.as   | 112 
+++--
 2 files changed, 109 insertions(+), 102 deletions(-)

diff --git 
a/frameworks/projects/Basic/src/main/royale/org/apache/royale/core/UIBase.as 
b/frameworks/projects/Basic/src/main/royale/org/apache/royale/core/UIBase.as
index 613c940..a9f9f52 100644
--- 
a/frameworks/projects/Basic/src/main/royale/org/apache/royale/core/UIBase.as
+++ 
b/frameworks/projects/Basic/src/main/royale/org/apache/royale/core/UIBase.as
@@ -904,43 +904,6 @@ package org.apache.royale.core
 {
 return element.childNodes as Array;
 }
-
-COMPILE::SWF
-   private var _model:IBeadModel;
-
-/**
- *  An IBeadModel that serves as the data model for the component.
- *  
- *  @langversion 3.0
- *  @playerversion Flash 10.2
- *  @playerversion AIR 2.6
- *  @productversion Royale 0.0
- */
-COMPILE::SWF
-public function get model():Object
-   {
-if (_model == null)
-{
-// addbead will set _model
-addBead(new (ValuesManager.valuesImpl.getValue(this, 
"iBeadModel")) as IBead);
-}
-   return _model;
-   }
-
-COMPILE::SWF
-/**
- * @private
- * @royaleignorecoercion org.apache.royale.core.IBead
- */
-[Bindable("modelChanged")]
-   public function set model(value:Object):void
-   {
-   if (_model != value)
-   {
-   addBead(value as IBead);
-   dispatchEvent(new Event("modelChanged"));
-   }
-   }

 private var _view:IBeadView;
 
@@ -1157,8 +1120,6 @@ package org.apache.royale.core
  */
public var beads:Array;

-COMPILE::SWF
-   private var _beads:Vector.;
 
 /**
  *  @copy org.apache.royale.core.IStrand#addBead()
@@ -1173,17 +1134,12 @@ package org.apache.royale.core
override public function addBead(bead:IBead):void
{
 var isView:Boolean;
-   if (!_beads)
-   _beads = new Vector.;
-   _beads.push(bead);
-   if (bead is IBeadModel)
-   _model = bead as IBeadModel;
-else if (bead is IBeadView)
-{
-_view = bead as IBeadView;
-isView = true
-}
-   bead.strand = this;
+   
+   super.addBead(bead);
+   if (this._model !== bead && bead is IBeadView) {
+   _view = bead as IBeadView;
+   isView = true
+   }

if (isView) {
dispatchEvent(new Event("viewChanged"));
@@ -1191,49 +1147,6 @@ package org.apache.royale.core
}

 /**
- *  @copy org.apache.royale.core.IStrand#getBeadByType()
- *  
- *  @langversion 3.0
- *  @playerversion Flash 10.2
- *  @playerversion AIR 2.6
- *  @productversion Royale 0.0
- */
-COMPILE::SWF
-   

Re: Language improvements

[Harbs]

As far as XML unit tests go, the starting point should be XMLTest in manual 
tests. (Almost) every time I ran into an issue, I added it to that project.

I think I might have been lax on the last few issues I fixed, so we should 
probably go through the later XML commits and make sure we have tests for that.

As far as Node goes, I think we probably need conditional Node compilation to 
handle Node-specific (and browser specific) code in a PAYG way.

To technically handle the parsing, something like 
https://github.com/isaacs/sax-js  is a good 
starting point and something like this https://github.com/nfarina/xmldoc 
 might be useful to either use or modify.

Harbs

> On May 23, 2019, at 10:18 AM, Greg Dove  wrote:
> 
> All, I started porting some adhoc XML tests to UnitTests and eventually
> ended up spending quite a bit of time on addressing issues that arose for
> XML before getting back to Vector stuff.
> I think XML probably needs many more unit tests before we get to 1.0
> because it has an extensive api. I have not used royale with Node yet, but
> XML also needs some thought about how to get it working on Node, I assume.
> Because XML uses the browser's parser and Node does not have one by
> default, then using the same code will need something to take the place of
> the browser's native parser for Node. There is a lib in npm that might be
> useful for that, but I don't know how that might work with licence etc.
> Anyhow, that is just an observation, I will focus on Vector in this
> thread... I will post here late tomorrow local time with more info, and
> discussion points. I am keen to see this merged in, but also keen to get
> buy-in first.
> 
> 
> On Fri, May 10, 2019 at 11:15 PM Carlos Rovira 
> wrote:
> 
>> Hi Greg,
>> 
>> thanks for reporting. I can share here that I was able to test your branch
>> with our real project and seems all goes well.
>> Could make a intense test, but almost app is working and we found just a
>> few type error coercions that your code was able to catch (so great! :))
>> and must be solved as you merge the branch in.
>> 
>> I think that if Vector is something new and others don't have problems, the
>> branch can be merged and Vector discussions can be done after that, since
>> it will not break anything since there's no uses of that code since is new,
>> but the other changes can be very beneficial
>> 
>> thanks in advance for your progress in all this stuff :)
>> 
>> Carlos
>> 
>> 
>> 
>> 
>> 
>> 
>> El vie., 10 may. 2019 a las 8:44, Greg Dove ()
>> escribió:
>> 
>>> All, I am really sorry, I keep thinking I will be able to get back to
>> this,
>>> but I have some other personal things taking my spare time at the moment.
>>> These will be done in 2 days, and I then will update the branch with some
>>> extra stuff, and continue this discussion with a focus on Vector
>> (bringing
>>> some other relevant discussion on the same topic from Alex as well) at
>> that
>>> time. Sorry to set the wrong expectations earlier.
>>> 
>>> 
>>> On Tue, May 7, 2019 at 9:01 AM Greg Dove  wrote:
>>> 
 Thanks for the feedback, Josh, Carlos, Alex.
 
 js-complex-implicit-coercions
 js-resolve-uncertain
 js-vector-index-checks
 
 I will make those changes for compiler settings at some point in the
 branch later today, invert the config default values to match, and swap
>>> all
 'off' settings in the framework builds (ant and maven) from true to
>>> false.
 I will also add compiler tests for these settings (either today or
 tomorrow). At the moment I only tested the new settings in the code
>>> result
 tests in javascript.
 
 In another day or two I will post a call to discuss the Vector
 implementation in more detail. For Vectors, the js-vector-index-checks
>>> was
 the obvious first candidate for dialing back on the impact of runtime
 type-checking, but there are a number of options for 'dialing' other
 aspects back (or even forward) and choosing the scope of their effect
 (local code, local project, or entire codebase code including external
 swcs). I already had stub code for the start of something else to
>> remove
 typechecking in mutation methods ('push', 'shift', 'pop' etc) but
>> removed
 it in favour of discussing and reviewing it first.  Coming up with a
 'usable' set of options will really benefit from your collective input,
>>> so
 I hope you can participate.
 
 
 
 
 
 On Tue, May 7, 2019 at 4:19 AM Alex Harui 
 wrote:
 
> +1 to renaming the options to the positive.
> 
> On 5/6/19, 8:12 AM, "Josh Tynjala"  wrote:
> 
>Hey Greg,
> 
>I haven't had a chance to look through all of the changes, but one
> thing caught my eye. I find it confusing when a boolean value is named
>>> with
> a "negative" phrase. For instance, your new compiler options 

Re: Language improvements

[Greg Dove]

All, I started porting some adhoc XML tests to UnitTests and eventually
ended up spending quite a bit of time on addressing issues that arose for
XML before getting back to Vector stuff.
I think XML probably needs many more unit tests before we get to 1.0
because it has an extensive api. I have not used royale with Node yet, but
XML also needs some thought about how to get it working on Node, I assume.
Because XML uses the browser's parser and Node does not have one by
default, then using the same code will need something to take the place of
the browser's native parser for Node. There is a lib in npm that might be
useful for that, but I don't know how that might work with licence etc.
Anyhow, that is just an observation, I will focus on Vector in this
thread... I will post here late tomorrow local time with more info, and
discussion points. I am keen to see this merged in, but also keen to get
buy-in first.


On Fri, May 10, 2019 at 11:15 PM Carlos Rovira 
wrote:

> Hi Greg,
>
> thanks for reporting. I can share here that I was able to test your branch
> with our real project and seems all goes well.
> Could make a intense test, but almost app is working and we found just a
> few type error coercions that your code was able to catch (so great! :))
> and must be solved as you merge the branch in.
>
> I think that if Vector is something new and others don't have problems, the
> branch can be merged and Vector discussions can be done after that, since
> it will not break anything since there's no uses of that code since is new,
> but the other changes can be very beneficial
>
> thanks in advance for your progress in all this stuff :)
>
> Carlos
>
>
>
>
>
>
> El vie., 10 may. 2019 a las 8:44, Greg Dove ()
> escribió:
>
> > All, I am really sorry, I keep thinking I will be able to get back to
> this,
> > but I have some other personal things taking my spare time at the moment.
> > These will be done in 2 days, and I then will update the branch with some
> > extra stuff, and continue this discussion with a focus on Vector
> (bringing
> > some other relevant discussion on the same topic from Alex as well) at
> that
> > time. Sorry to set the wrong expectations earlier.
> >
> >
> > On Tue, May 7, 2019 at 9:01 AM Greg Dove  wrote:
> >
> > > Thanks for the feedback, Josh, Carlos, Alex.
> > >
> > > js-complex-implicit-coercions
> > > js-resolve-uncertain
> > > js-vector-index-checks
> > >
> > > I will make those changes for compiler settings at some point in the
> > > branch later today, invert the config default values to match, and swap
> > all
> > > 'off' settings in the framework builds (ant and maven) from true to
> > false.
> > > I will also add compiler tests for these settings (either today or
> > > tomorrow). At the moment I only tested the new settings in the code
> > result
> > > tests in javascript.
> > >
> > > In another day or two I will post a call to discuss the Vector
> > > implementation in more detail. For Vectors, the js-vector-index-checks
> > was
> > > the obvious first candidate for dialing back on the impact of runtime
> > > type-checking, but there are a number of options for 'dialing' other
> > > aspects back (or even forward) and choosing the scope of their effect
> > > (local code, local project, or entire codebase code including external
> > > swcs). I already had stub code for the start of something else to
> remove
> > > typechecking in mutation methods ('push', 'shift', 'pop' etc) but
> removed
> > > it in favour of discussing and reviewing it first.  Coming up with a
> > > 'usable' set of options will really benefit from your collective input,
> > so
> > > I hope you can participate.
> > >
> > >
> > >
> > >
> > >
> > > On Tue, May 7, 2019 at 4:19 AM Alex Harui 
> > > wrote:
> > >
> > >> +1 to renaming the options to the positive.
> > >>
> > >> On 5/6/19, 8:12 AM, "Josh Tynjala"  wrote:
> > >>
> > >> Hey Greg,
> > >>
> > >> I haven't had a chance to look through all of the changes, but one
> > >> thing caught my eye. I find it confusing when a boolean value is named
> > with
> > >> a "negative" phrase. For instance, your new compiler options have "no"
> > in
> > >> the name:
> > >>
> > >> js-no-complex-implicit-coercions
> > >> js-no-resolve-uncertain
> > >> js-no-vector-index-checks
> > >>
> > >> As they are named, true means no, and so false means yes. With
> this
> > >> kind of naming, I find that I always need to take a moment to remember
> > >> which means which. I think it would be better if true means yes and
> > false
> > >> means no.
> > >>
> > >> - Josh
> > >>
> > >> On 2019/05/05 08:00:20, 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
> > >> >