Re: [royale-asjs] 01/06: RoyaleArrayLike support (IArrayList and BinaryData)

2019-10-14 Thread Greg Dove
Thanks for bringing that to my attention, Josh. it should be fixed now (I
tested with your example, thanks for that).

On Tue, Oct 15, 2019 at 10:31 AM Greg Dove  wrote:

>
> Hi Josh, thanks, I will look into that today.
>
>
> On Tue, Oct 15, 2019 at 10:30 AM Josh Tynjala 
> wrote:
>
>> Hey Greg,
>>
>> Starting with the commit, there are times when compilation gets stuck in
>> an infinite loop. It should be possible to reproduce using the following
>> code:
>>
>> for each(var key:Object in Fake.hello)
>> {
>> }
>>
>> "Fake" is a class that does not exist. It should result in an error, but
>> the compiler seems to get stuck trying to resolve it over and over again.
>>
>> - Josh
>>
>> On 2019/10/02 08:39:35, gregd...@apache.org wrote:
>> > This is an automated email from the ASF dual-hosted git repository.
>> >
>> > gregdove pushed a commit to branch develop
>> > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>> >
>> > commit e52954b22a4599c75ba242955273627867e00e4d
>> > Author: greg-dove 
>> > AuthorDate: Sun Sep 29 15:16:21 2019 +1300
>> >
>> > RoyaleArrayLike support (IArrayList and BinaryData)
>> > ---
>> >  frameworks/projects/Collections/pom.xml|  14 ++
>> >  .../src/main/config/compile-swf-config.xml |   1 +
>> >  .../src/main/royale/CollectionsClasses.as  |   2 +
>> >  .../org/apache/royale/collections/ArrayList.as |   2 +-
>> >  .../org/apache/royale/collections/IArrayList.as|  13 +-
>> >  frameworks/projects/Core/pom.xml   |  19 +-
>> >  .../Core/src/main/config/compile-swf-config.xml|   6 +-
>> >  .../projects/Core/src/main/royale/CoreClasses.as   |   3 +
>> >  .../royale/org/apache/royale/utils/BinaryData.as   |  11 +-
>> >  .../Language/src/main/royale/LanguageClasses.as|   2 +-
>> >  .../apache/royale/language/iterator/arrayLike.as   |  73 +++
>> >  .../main/royale/flexUnitTests/LanguageTester.as|   8 +-
>> >  .../language/LanguageTesterTestArraylikeGetSet.as  | 227
>> +
>> >  .../language/LanguageTesterTestForEach.as  | 205
>> +++
>> >  .../language/support/checkArrayLikeFunc.as |  30 +--
>> >  15 files changed, 587 insertions(+), 29 deletions(-)
>> >
>> > diff --git a/frameworks/projects/Collections/pom.xml
>> b/frameworks/projects/Collections/pom.xml
>> > index a105423..59cb218 100644
>> > --- a/frameworks/projects/Collections/pom.xml
>> > +++ b/frameworks/projects/Collections/pom.xml
>> > @@ -60,6 +60,20 @@
>> >
>> >  
>> >org.apache.royale.framework
>> > +  Language
>> > +  0.9.6-SNAPSHOT
>> > +  swc
>> > +  swf
>> > +
>> > +
>> > +  org.apache.royale.framework
>> > +  Language
>> > +  0.9.6-SNAPSHOT
>> > +  swc
>> > +  js
>> > +
>> > +
>> > +  org.apache.royale.framework
>> >Core
>> >0.9.6-SNAPSHOT
>> >swc
>> > diff --git
>> a/frameworks/projects/Collections/src/main/config/compile-swf-config.xml
>> b/frameworks/projects/Collections/src/main/config/compile-swf-config.xml
>> > index 6116aec..1c00110 100644
>> > ---
>> a/frameworks/projects/Collections/src/main/config/compile-swf-config.xml
>> > +++
>> b/frameworks/projects/Collections/src/main/config/compile-swf-config.xml
>> > @@ -31,6 +31,7 @@
>> >  
>> >
>> ${env.AIR_HOME}/frameworks/libs/air/airglobal.swc
>> >  ../../../../../libs/Core.swc
>> > +
>> ../../../../../libs/Language.swc
>> >  
>> >
>> >   
>> > diff --git
>> a/frameworks/projects/Collections/src/main/royale/CollectionsClasses.as
>> b/frameworks/projects/Collections/src/main/royale/CollectionsClasses.as
>> > index fe946df..ecc1033 100644
>> > ---
>> a/frameworks/projects/Collections/src/main/royale/CollectionsClasses.as
>> > +++
>> b/frameworks/projects/Collections/src/main/royale/CollectionsClasses.as
>> > @@ -43,6 +43,8 @@ internal class CollectionsClasses
>> >   import org.apache.royale.collections.SortField; SortField;
>> >   import org.apache.royale.collections.SortFieldCompareTypes;
>> SortFieldCompareTypes;
>> >   import o

Re: [royale-asjs] 01/06: RoyaleArrayLike support (IArrayList and BinaryData)

2019-10-14 Thread Greg Dove
Hi Josh, thanks, I will look into that today.


On Tue, Oct 15, 2019 at 10:30 AM Josh Tynjala 
wrote:

> Hey Greg,
>
> Starting with the commit, there are times when compilation gets stuck in
> an infinite loop. It should be possible to reproduce using the following
> code:
>
> for each(var key:Object in Fake.hello)
> {
> }
>
> "Fake" is a class that does not exist. It should result in an error, but
> the compiler seems to get stuck trying to resolve it over and over again.
>
> - Josh
>
> On 2019/10/02 08:39:35, gregd...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > gregdove pushed a commit to branch develop
> > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> >
> > commit e52954b22a4599c75ba242955273627867e00e4d
> > Author: greg-dove 
> > AuthorDate: Sun Sep 29 15:16:21 2019 +1300
> >
> > RoyaleArrayLike support (IArrayList and BinaryData)
> > ---
> >  frameworks/projects/Collections/pom.xml|  14 ++
> >  .../src/main/config/compile-swf-config.xml |   1 +
> >  .../src/main/royale/CollectionsClasses.as  |   2 +
> >  .../org/apache/royale/collections/ArrayList.as |   2 +-
> >  .../org/apache/royale/collections/IArrayList.as|  13 +-
> >  frameworks/projects/Core/pom.xml   |  19 +-
> >  .../Core/src/main/config/compile-swf-config.xml|   6 +-
> >  .../projects/Core/src/main/royale/CoreClasses.as   |   3 +
> >  .../royale/org/apache/royale/utils/BinaryData.as   |  11 +-
> >  .../Language/src/main/royale/LanguageClasses.as|   2 +-
> >  .../apache/royale/language/iterator/arrayLike.as   |  73 +++
> >  .../main/royale/flexUnitTests/LanguageTester.as|   8 +-
> >  .../language/LanguageTesterTestArraylikeGetSet.as  | 227
> +
> >  .../language/LanguageTesterTestForEach.as  | 205
> +++
> >  .../language/support/checkArrayLikeFunc.as |  30 +--
> >  15 files changed, 587 insertions(+), 29 deletions(-)
> >
> > diff --git a/frameworks/projects/Collections/pom.xml
> b/frameworks/projects/Collections/pom.xml
> > index a105423..59cb218 100644
> > --- a/frameworks/projects/Collections/pom.xml
> > +++ b/frameworks/projects/Collections/pom.xml
> > @@ -60,6 +60,20 @@
> >
> >  
> >org.apache.royale.framework
> > +  Language
> > +  0.9.6-SNAPSHOT
> > +  swc
> > +  swf
> > +
> > +
> > +  org.apache.royale.framework
> > +  Language
> > +  0.9.6-SNAPSHOT
> > +  swc
> > +  js
> > +
> > +
> > +  org.apache.royale.framework
> >Core
> >0.9.6-SNAPSHOT
> >swc
> > diff --git
> a/frameworks/projects/Collections/src/main/config/compile-swf-config.xml
> b/frameworks/projects/Collections/src/main/config/compile-swf-config.xml
> > index 6116aec..1c00110 100644
> > ---
> a/frameworks/projects/Collections/src/main/config/compile-swf-config.xml
> > +++
> b/frameworks/projects/Collections/src/main/config/compile-swf-config.xml
> > @@ -31,6 +31,7 @@
> >  
> >
> ${env.AIR_HOME}/frameworks/libs/air/airglobal.swc
> >  ../../../../../libs/Core.swc
> > +
> ../../../../../libs/Language.swc
> >  
> >
> >   
> > diff --git
> a/frameworks/projects/Collections/src/main/royale/CollectionsClasses.as
> b/frameworks/projects/Collections/src/main/royale/CollectionsClasses.as
> > index fe946df..ecc1033 100644
> > ---
> a/frameworks/projects/Collections/src/main/royale/CollectionsClasses.as
> > +++
> b/frameworks/projects/Collections/src/main/royale/CollectionsClasses.as
> > @@ -43,6 +43,8 @@ internal class CollectionsClasses
> >   import org.apache.royale.collections.SortField; SortField;
> >   import org.apache.royale.collections.SortFieldCompareTypes;
> SortFieldCompareTypes;
> >   import org.apache.royale.collections.CompareUtils; CompareUtils;
> > +
> > + import org.apache.royale.language.iterator.arrayLike;arrayLike;
> >
> >  }
> >
> > diff --git
> a/frameworks/projects/Collections/src/main/royale/org/apache/royale/collections/ArrayList.as
> b/frameworks/projects/Collections/src/main/royale/org/apache/royale/collections/ArrayList.as
> > index 38164aa..75ea856 100644
> > ---
> a/frameworks/projects/Collections/src/main/royale/org/apache/royale/collections/ArrayList.as
> > +++
> b/frameworks/projects/Collections/src/main/royale

Re: RoyaleUnit testing - swf player version used for testing

2019-10-09 Thread Greg Dove
Thanks Josh, that definitely sounds like a better option.  I will give that
a try for that side of things locally.
Maybe we can also use this on the CI server to specify the version that is
used?



On Thu, Oct 10, 2019 at 7:30 AM Josh Tynjala 
wrote:

> The RoyaleUnit Ant task has a "command" parameter where we can pass in the
> path of a specific executable. I don't think the Ant task should try to
> read a magic environment variable. Instead, we can reference the
> environment variable inside the Ant script.
>
> Something like this should probably work:
>
> 
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Oct 9, 2019 at 11:09 AM Greg Dove  wrote:
>
> > This is partly for general input, but also for Josh specifically in
> > relation to RoyaleUnit
> >
> > Background
> > I am continuing to add unit tests, mostly language level stuff.
> >
> > It is rare, but there can be some things to account for in terms of
> > differences caused by the player being used for testing (and also
> sometimes
> > for swf versions).
> > This has come up with some XML related stuff recently, where there was a
> > one test that failed in the CI build. I discovered this was happening in
> > standalone player (probably regular player and air too) only in versions
> > between 11.2 and 20.0 - it passes in version 11.1 and versions 21.0+ . I
> > only tested this on windows, so it may not be apparent on mac.  It wasn't
> > failing for me locally because my system player was version 30.
> >
> > RoyaleUnit testing uses the system file ('.swf') association to launch
> the
> > player. So for some tests it means that they could pass or not depending
> on
> > the version of the standalone player being launched, because bugs were
> > fixed in later versions of the player /AVM.
> >
> > I have my local FLASHPLAYER_DEBUGGER pointing to a 22 version. I know
> that
> > version is used in some of the build configs as well, but it seems that
> the
> > player version for testing on the CI server was something between 11.2
> and
> > 20 so that firstly seems inconsistent with version 22 used elsewhere.
> >
> > So two topics really:
> >
> > 1. General request: Could we agree to standardize the version of the
> flash
> > player we use for RoyaleUnit testing for CI builds? And what version
> should
> > that be. I don't really mind what that is although I think more recent
> > versions make sense mainly because I think we should be aiming to emulate
> > the most up to date version of the player behavior with various bug
> fixes.
> > However mostly I just would like to be aware of it so I can match it
> > locally.
> >
> > 2. For Josh, a request:
> > Could we have RoyaleUnit configurable for the player that should be used
> > for testing (with the system player as fallback)?
> > I was able to do this quickly locally in WindowsDefaults.java by doing
> the
> > following:
> >
> > public String getOpenCommand()
> > {
> > if (System.getenv("FLASHPLAYER_DEBUGGER") != null) {
> > return System.getenv("FLASHPLAYER_DEBUGGER");
> > }
> > return "rundll32";
> > }
> >
> > public String[] getOpenSystemArguments()
> > {
> > if (System.getenv("FLASHPLAYER_DEBUGGER") != null) {
> > return new String[]{""};
> > }
> > return new String[]{"url.dll,FileProtocolHandler"};
> > }
> >
> > I am not sure if it should be using the same ' FLASHPLAYER_DEBUGGER' env
> > var  there that we use elsewhere or not... but I was able to use that
> > approach to quickly cycle through a lot of different player versions with
> > the tests to find the versions that had the issue.
> > If it needs to be different it could be something that is specific to
> > RoyaleUnit... ROYALEUNIT_SWF_PLAYER or anything really. I don't know if
> > this approach works the same on mac... anyhow please consider that
> > (generally) as a possible addition for Royaleunit.
> >
>


RoyaleUnit testing - swf player version used for testing

2019-10-09 Thread Greg Dove
This is partly for general input, but also for Josh specifically in
relation to RoyaleUnit

Background
I am continuing to add unit tests, mostly language level stuff.

It is rare, but there can be some things to account for in terms of
differences caused by the player being used for testing (and also sometimes
for swf versions).
This has come up with some XML related stuff recently, where there was a
one test that failed in the CI build. I discovered this was happening in
standalone player (probably regular player and air too) only in versions
between 11.2 and 20.0 - it passes in version 11.1 and versions 21.0+ . I
only tested this on windows, so it may not be apparent on mac.  It wasn't
failing for me locally because my system player was version 30.

RoyaleUnit testing uses the system file ('.swf') association to launch the
player. So for some tests it means that they could pass or not depending on
the version of the standalone player being launched, because bugs were
fixed in later versions of the player /AVM.

I have my local FLASHPLAYER_DEBUGGER pointing to a 22 version. I know that
version is used in some of the build configs as well, but it seems that the
player version for testing on the CI server was something between 11.2 and
20 so that firstly seems inconsistent with version 22 used elsewhere.

So two topics really:

1. General request: Could we agree to standardize the version of the flash
player we use for RoyaleUnit testing for CI builds? And what version should
that be. I don't really mind what that is although I think more recent
versions make sense mainly because I think we should be aiming to emulate
the most up to date version of the player behavior with various bug fixes.
However mostly I just would like to be aware of it so I can match it
locally.

2. For Josh, a request:
Could we have RoyaleUnit configurable for the player that should be used
for testing (with the system player as fallback)?
I was able to do this quickly locally in WindowsDefaults.java by doing the
following:

public String getOpenCommand()
{
if (System.getenv("FLASHPLAYER_DEBUGGER") != null) {
return System.getenv("FLASHPLAYER_DEBUGGER");
}
return "rundll32";
}

public String[] getOpenSystemArguments()
{
if (System.getenv("FLASHPLAYER_DEBUGGER") != null) {
return new String[]{""};
}
return new String[]{"url.dll,FileProtocolHandler"};
}

I am not sure if it should be using the same ' FLASHPLAYER_DEBUGGER' env
var  there that we use elsewhere or not... but I was able to use that
approach to quickly cycle through a lot of different player versions with
the tests to find the versions that had the issue.
If it needs to be different it could be something that is specific to
RoyaleUnit... ROYALEUNIT_SWF_PLAYER or anything really. I don't know if
this approach works the same on mac... anyhow please consider that
(generally) as a possible addition for Royaleunit.


Re: Heads up on XML

2019-10-08 Thread Greg Dove
Hi Piotr, quick response below...

> 
> generate-swcs-for-swf
> 
> 
> org.apache.royale.framework
> Core
> 0.9.7-SNAPSHOT
> swc
> swf
> 
> 
> 
>
>
How this activates  generate.swf.swcs ? What should I do if I wanted to
build only one module ? Doing that in above way how will change main
command which launches maven build ?

For: How this activates  generate.swf.swcs ?
Response:
It doesn't - it would use the already defined profile ('
generate-swcs-for-swf') but the same dependency variations that are
currently specified for 'generate.swf.swcs' .
I did not have time to test this yet with a clean maven repo.

Basically instead of : mvn clean install -Pmain,generate-swcs-for-swf
-Dgenerate.swf.swcs=true
It would be (as before) mvn clean install -Pmain,generate-swcs-for-swf

  The ' -Dgenerate.swf.swcs=true' is necessary to activate the new profile
defined at lower levels.

but because the
generate-swcs-for-swf
profile is already defined at a higher level and includes the airglobal
dependency (alongside 'generate-swf' which includes playerglobal)
it can also be used in the lower modules to add swf-only dependencies

so we should (usually, I think, in my experience with customer projects)
re-use the top level profile in the lower level maven modules.
But I am not really clear in my understanding of details of the problem
that this original change had to solve, so I might be missing something.

>From an IDE perspective (which was really why I focused on this originally,
because I use maven by default from my IDE and things started to look a lot
more complicated), I have this working now, and I just 'check' (select the
checkbox for)  the 'generate-swcs-for-swf' profile and the 'main' profile
in my maven IDE tools, instead of 'checking' two different profiles, then I
can build the combo of js and swf swcs individually for each framework
project from my ide, which is how I do it locally when I make changes.

Hopefully I can check this today... I will try



On Tue, Oct 8, 2019 at 8:33 PM Piotr Zarzycki 
wrote:

> Hi Greg,
>
> Questions inline.
>
> pon., 7 paź 2019 o 01:49 Greg Dove  napisał(a):
>
> > Hi Piotr, just a quick follow-up to let you know that was all good, I had
> > already tested the merge and conflict resolution myself and was ready to
> > step in and help with that if that was necessary, but you already did it
> > before I got a chance to send my email about that. :)
> >
> > I have to say: well done for getting through the release process. I could
> > sense your frustration at times, and I know it must have seemed like it
> > took far too long, but I am sure you have made a huge difference for the
> > future in terms of that process.
> >
> >
> > also fyi, I had to use -Dgenerate.swf.swcs=true in my local maven build
> > today, and I was vaguely aware of discussions about this during release
> > prep.
> > But I wonder if this is necessary. Can't we just use the top level
> profiles
> > at the lower levels instead of creating new profiles? There's probably a
> > gap in my understanding of why this was necessary, but I would have
> > expected that we could simply use something like:
> >
> > 
> > generate-swcs-for-swf
> > 
> > 
> > org.apache.royale.framework
> > Core
> > 0.9.7-SNAPSHOT
> > swc
> > swf
> > 
> > 
> > 
> >
> >
> How this activates  generate.swf.swcs ? What should I do if I wanted to
> build only one module ? Doing that in above way how will change main
> command which launches maven build ?
>
>
> > in the framework modules, instead of:
> >
> >   
> >   swf-dependencies
> >   
> >   
> >   generate.swf.swcs
> >   
> >   
> >   
> >   
> >   org.apache.royale.framework
> >   Core
> >   0.9.7-SNAPSHOT
> >   swc
> >   swf
> >   
> >   
> >   
> >
> > (the above approach works locally for me just using the maven profile
> > itself, if I make the changes to all framework modules, but as I said I
> > could be missing something in relation to the issue that is being
> > addressed)
> >
> >
> > On Sun, Oct 6, 2019 at 11:20 PM Greg Dove  wrote:
> >
> > > Hi Piotr, I will check that in the morning l

Re: maven fails on build royale-asjs 0.9.7-SNAPSHOT

2019-10-08 Thread Greg Dove
Carlos, you need:

mvn clean install -Pmain,generate-swcs-for-swf -Dgenerate.swf.swcs=true

But I think that could be avoided. I hope to check today with empty maven
repo


On Wed, Oct 9, 2019 at 8:00 AM Carlos Rovira 
wrote:

> Hi,
>
> just trying to build as usual, but now with new 0.9.7-SNAPSHOT
> when reach royale-asjs try to build with:
>
> mvn clean install -Pgenerate-swcs-for-swf,main -DskipTests
>
> and getting this error:
>
> https://paste.apache.org/kt8wi
>
> Maybe I miss some latest change?
>
> thanks
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: ROYALE_REFLECTION_INFO.compileFlags

2019-10-07 Thread Greg Dove
Hi Harbs I actually noticed that recently prompted by something Alex had
mentioned in a thread somewhere. It should be fixed in a recent commit
during the past week sometime, unless I missed something (it was working
for Hello World). What build are you using? And are you using any features
that require reflection?



On Tue, 8 Oct 2019, 00:01 Harbs,  wrote:

> It seems to me like the size of my app has recently increased and I’m
> trying to understand why. I noticed that I have 1270 instances of
> ROYALE_REFLECTION_INFO.compileFlags in my app (and 1421 instances of
> ROYALE_REFLECTION_INFO) in my minified app.  I don’t know what this does.
> Is this always needed, and is there a way of preventing reflection data
> when it’s not needed? If it is needed, is there some way of getting these
> keys minified? A rough calculation tells me these additions comprise more
> than 5 percent of my compiled app.
>
> Thanks,
> Harbs


Re: Build failed in Jenkins: royale-asjs #2777

2019-10-07 Thread Greg Dove
I'll check it today Piotr.

On Tue, 8 Oct 2019, 01:50 Piotr Zarzycki,  wrote:

> RoyaleUnit tests are failing on XML module, can someone with some free
> cycle look into this ?
>
> pon., 7 paź 2019 o 14:47 Apache Royale CI Server  >
> napisał(a):
>
> > See <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/2777/display/redirect
> > >
> >
> > --
> > [...truncated 1.61 MB...]
> >  [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m
> > -Xmx2g
> >
> > compile-js:
> >  [echo] swc-date is 10/07/19 12:45 +
> >[delete] Deleting: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/js/projects/XMLJS/XMLJS.swc.properties
> > >
> >
> > clean:
> >  [echo] swc-date is 10/07/19 12:45 +
> >[delete] Deleting: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/js/projects/XMLJS/XMLJS.swc.properties
> > >
> >
> > check-for-tests:
> >
> > clean-tests:
> >
> > clean:
> >
> > check-compiler-home:
> >
> > check-transpiler-home:
> >
> > check-compiler:
> >
> > compile:
> >  [echo] Cross-compiling XMLJS.swc
> >  [echo] ROYALE_COMPILER_HOME: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/js
> > >
> > [mkdir] Created dir: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/js/projects/XMLJS/target/generated-sources/royale
> > >
> >  [java] args:
> >  [java] +royalelib=<
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks
> > >
> >  [java] -compiler.strict-xml=true
> >  [java] -warn-public-vars=false
> >  [java] -compiler.targets=SWF,JSRoyale
> >  [java] -metadata.date=10/07/19 12:45 +
> >  [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
> >  [java] -swf-debugfile-alias=/org/apache/royale/0.9.7
> >  [java] -output=<
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/js/projects/XMLJS/target/XMLJS.swc
> > >
> >  [java] -load-config=<
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/js-config.xml
> > >
> >  [java] -load-config+=<
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/js/projects/XMLJS/src/main/config/compile-js-config.xml
> > >
> >  [java] target:SWF
> >  [java] target:JSRoyale
> >  [java] COMPC
> >  [java] Loading configuration: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/js-config.xml
> > >
> >  [java] Loading configuration: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/js/projects/XMLJS/src/main/config/compile-js-config.xml
> > >
> >  [java]
> >  [java] 30565 bytes written to
> >
> C:\jenkins\workspace\royale-asjs\frameworks\js\projects\XMLJS\target\XMLJS.swc
> > in 2.132 seconds
> >  [java] COMPCJSCRoyale
> >  [java] 4.7130553 seconds
> >  [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m
> > -Xmx2g
> >  [copy] Copying 1 file to <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/js/libs
> > >
> >
> > main:
> >
> > copy-swc:
> >  [copy] Copying 1 file to <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/libs
> > >
> >
> > check-for-tests:
> >
> > test:
> >
> > clean:
> >
> > compile:
> >  [echo] Compiling FlexUnitRoyaleApplication.swf
> >  [echo] ROYALE_HOME: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/>
> >  [echo] ROYALE_SWF_COMPILER_HOME: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/>
> >  [echo] playerglobal.version: 11.7
> > Trying to override old definition of task compc
> > Trying to override old definition of task mxmlc
> > [mxmlc] MXMLJSC
> > [mxmlc] -debug
> > [mxmlc] -compiler.targets=SWF
> > [mxmlc] +playerglobal.version=11.7
> > [mxmlc] +env.PLAYERGLOBAL_HOME=C:\adobe\flash
> > [mxmlc] +royalelib=<
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/
> > >
> > [mxmlc] -output=<
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/projects/XML/src/test/royale/FlexUnitRoyaleApplication.swf
> > >
> > [mxmlc] --
> > [mxmlc] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/projects/XML/src/test/royale/FlexUnitRoyaleApplication.mxml
> > >
> > [mxmlc] Loading configuration: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ws/frameworks/royale-config.xml
> > >
> > [mxmlc] Loading configuration: <
> >
> 

Re: Heads up on XML

2019-10-06 Thread Greg Dove
Ok, thanks Alex, I will do that tomorrow.


On Mon, Oct 7, 2019 at 4:02 PM Alex Harui  wrote:

> Improvements to the Maven builds and Ant builds are always welcome.  Just
> make sure they work from a truly clean machine (empty the local Maven repo,
> build without access to the snapshots repo, etc).
>
> There are some issues with profile inheritance in Maven, but I don't
> understand your proposal enough to know if there is some hole in it.  Try
> it and find out.
>
> -Alex
>
> On 10/6/19, 4:49 PM, "Greg Dove"  wrote:
>
> Hi Piotr, just a quick follow-up to let you know that was all good, I
> had
> already tested the merge and conflict resolution myself and was ready
> to
> step in and help with that if that was necessary, but you already did
> it
> before I got a chance to send my email about that. :)
>
> I have to say: well done for getting through the release process. I
> could
> sense your frustration at times, and I know it must have seemed like it
> took far too long, but I am sure you have made a huge difference for
> the
> future in terms of that process.
>
>
> also fyi, I had to use -Dgenerate.swf.swcs=true in my local maven build
> today, and I was vaguely aware of discussions about this during release
> prep.
> But I wonder if this is necessary. Can't we just use the top level
> profiles
> at the lower levels instead of creating new profiles? There's probably
> a
> gap in my understanding of why this was necessary, but I would have
> expected that we could simply use something like:
>
> 
> generate-swcs-for-swf
> 
> 
> org.apache.royale.framework
> Core
> 0.9.7-SNAPSHOT
> swc
> swf
> 
> 
> 
>
> in the framework modules, instead of:
>
>   
>   swf-dependencies
>   
>   
>   generate.swf.swcs
>   
>   
>   
>   
>   org.apache.royale.framework
>   Core
>   0.9.7-SNAPSHOT
>   swc
>   swf
>   
>   
>   
>
> (the above approach works locally for me just using the maven profile
> itself, if I make the changes to all framework modules, but as I said I
> could be missing something in relation to the issue that is being
> addressed)
>
>
> On Sun, Oct 6, 2019 at 11:20 PM Greg Dove  wrote:
>
> > Hi Piotr, I will check that in the morning local time... in about 8
> hours.
> >
> > On Sun, 6 Oct 2019, 21:54 Piotr Zarzycki,  >
> > wrote:
> >
> >> Hi Greg,
> >>
> >> I run into merge conflict during merge release branch to develop
> into file
> >> which you have changed lately. Could you please verify on develop
> if I
> >> didn't remove anything, if I resolve conflict correctly. [1]
> >>
> >> [1]
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fblob%2Fdevelop%2Fcompiler-jx%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Froyale%2Fcompiler%2Finternal%2Fcodegen%2Fjs%2Fjx%2FMemberAccessEmitter.javadata=02%7C01%7Caharui%40adobe.com%7C8e7bf2601258466052f808d74ab7db82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637060025834669854sdata=AdnP68Opu%2BA8bOMc34%2FsNR2ZXT6gAHRsio9NX758278%3Dreserved=0
> >>
> >> Thanks,
> >> Piotr
> >>
> >> śr., 2 paź 2019 o 11:06 Harbs  napisał(a):
> >>
> >> > OK.
> >> >
> >> > I’ll test memory with and without your changes and let you know
> the
> >> > differences. :-)
> >> >
> >> > Harbs
> >> >
> >> > > On Oct 2, 2019, at 11:29 AM, Greg Dove 
> wrote:
> >> > >
> >> > > @harbs
> >> > >
> >> > > FYI in addition to some other stuff, I am close to pushing my
> updates
> >> to
> >> > > XML. This should be in the next hour or so.
> >> > >
> >> > > I kept the QName caching pretty close to how you had it, with
> only
> >> some
> >> > > minor changes.
> >> > > I tried to do some extra memory op

Re: Heads up on XML

2019-10-06 Thread Greg Dove
Hi Piotr, just a quick follow-up to let you know that was all good, I had
already tested the merge and conflict resolution myself and was ready to
step in and help with that if that was necessary, but you already did it
before I got a chance to send my email about that. :)

I have to say: well done for getting through the release process. I could
sense your frustration at times, and I know it must have seemed like it
took far too long, but I am sure you have made a huge difference for the
future in terms of that process.


also fyi, I had to use -Dgenerate.swf.swcs=true in my local maven build
today, and I was vaguely aware of discussions about this during release
prep.
But I wonder if this is necessary. Can't we just use the top level profiles
at the lower levels instead of creating new profiles? There's probably a
gap in my understanding of why this was necessary, but I would have
expected that we could simply use something like:


generate-swcs-for-swf


org.apache.royale.framework
Core
0.9.7-SNAPSHOT
swc
swf




in the framework modules, instead of:

  
  swf-dependencies
  
  
  generate.swf.swcs
  
  
  
  
  org.apache.royale.framework
  Core
  0.9.7-SNAPSHOT
  swc
  swf
  
  
  

(the above approach works locally for me just using the maven profile
itself, if I make the changes to all framework modules, but as I said I
could be missing something in relation to the issue that is being addressed)


On Sun, Oct 6, 2019 at 11:20 PM Greg Dove  wrote:

> Hi Piotr, I will check that in the morning local time... in about 8 hours.
>
> On Sun, 6 Oct 2019, 21:54 Piotr Zarzycki, 
> wrote:
>
>> Hi Greg,
>>
>> I run into merge conflict during merge release branch to develop into file
>> which you have changed lately. Could you please verify on develop if I
>> didn't remove anything, if I resolve conflict correctly. [1]
>>
>> [1]
>>
>> https://github.com/apache/royale-compiler/blob/develop/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
>>
>> Thanks,
>> Piotr
>>
>> śr., 2 paź 2019 o 11:06 Harbs  napisał(a):
>>
>> > OK.
>> >
>> > I’ll test memory with and without your changes and let you know the
>> > differences. :-)
>> >
>> > Harbs
>> >
>> > > On Oct 2, 2019, at 11:29 AM, Greg Dove  wrote:
>> > >
>> > > @harbs
>> > >
>> > > FYI in addition to some other stuff, I am close to pushing my updates
>> to
>> > > XML. This should be in the next hour or so.
>> > >
>> > > I kept the QName caching pretty close to how you had it, with only
>> some
>> > > minor changes.
>> > > I tried to do some extra memory optimization, and in theory it should
>> > > provide better results, but to be honest I don't have a good way to
>> > measure
>> > > this in the browser. I tried the Chrome performance.memory extensions
>> > but I
>> > > don't have much confidence in that given how much it varies between
>> > reloads
>> > > without changing anything else. The extra code changes I made were to
>> > make
>> > > the '_nodeKind' strings into String object references, so they only
>> refer
>> > > to a single reference to a string instead of multiple copies of
>> > primitives.
>> > > That change is isolated to a single commit so can easily be reversed
>> if
>> > > there is something not good about it... but all my local tests
>> continue
>> > to
>> > > pass. I will get the new tests into RoyaleUnit in the coming days.
>> > >
>> > >
>> > >
>> > >
>> > > On Thu, Sep 5, 2019 at 7:39 AM Greg Dove  wrote:
>> > >
>> > >> Yeah, I saw that ;) Don't worry, I am aware of it.
>> > >>
>> > >> My first goal is to make sure it works like it should, because that
>> > comes
>> > >> first, and then to optimize. I'll check the memory side of things and
>> > make
>> > >> sure it's at least the same as before. If you can point me to some
>> > >> publicly accessible large test cases that would be really helpful. I
>> > will
>> > >> work through that before I push anything.
>> > >>
>> > >&g

Re: Heads up on XML

2019-10-06 Thread Greg Dove
Hi Piotr, I will check that in the morning local time... in about 8 hours.

On Sun, 6 Oct 2019, 21:54 Piotr Zarzycki,  wrote:

> Hi Greg,
>
> I run into merge conflict during merge release branch to develop into file
> which you have changed lately. Could you please verify on develop if I
> didn't remove anything, if I resolve conflict correctly. [1]
>
> [1]
>
> https://github.com/apache/royale-compiler/blob/develop/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
>
> Thanks,
> Piotr
>
> śr., 2 paź 2019 o 11:06 Harbs  napisał(a):
>
> > OK.
> >
> > I’ll test memory with and without your changes and let you know the
> > differences. :-)
> >
> > Harbs
> >
> > > On Oct 2, 2019, at 11:29 AM, Greg Dove  wrote:
> > >
> > > @harbs
> > >
> > > FYI in addition to some other stuff, I am close to pushing my updates
> to
> > > XML. This should be in the next hour or so.
> > >
> > > I kept the QName caching pretty close to how you had it, with only some
> > > minor changes.
> > > I tried to do some extra memory optimization, and in theory it should
> > > provide better results, but to be honest I don't have a good way to
> > measure
> > > this in the browser. I tried the Chrome performance.memory extensions
> > but I
> > > don't have much confidence in that given how much it varies between
> > reloads
> > > without changing anything else. The extra code changes I made were to
> > make
> > > the '_nodeKind' strings into String object references, so they only
> refer
> > > to a single reference to a string instead of multiple copies of
> > primitives.
> > > That change is isolated to a single commit so can easily be reversed if
> > > there is something not good about it... but all my local tests continue
> > to
> > > pass. I will get the new tests into RoyaleUnit in the coming days.
> > >
> > >
> > >
> > >
> > > On Thu, Sep 5, 2019 at 7:39 AM Greg Dove  wrote:
> > >
> > >> Yeah, I saw that ;) Don't worry, I am aware of it.
> > >>
> > >> My first goal is to make sure it works like it should, because that
> > comes
> > >> first, and then to optimize. I'll check the memory side of things and
> > make
> > >> sure it's at least the same as before. If you can point me to some
> > >> publicly accessible large test cases that would be really helpful. I
> > will
> > >> work through that before I push anything.
> > >>
> > >> On Thu, Sep 5, 2019 at 7:26 AM Harbs  wrote:
> > >>
> > >>> Heads up:
> > >>>
> > >>> I did some (on first blush) odd things in XML related to QNames.
> QNames
> > >>> are pooled and many XML properties are not initialized by default.
> The
> > >>> reason I did this was it avoided many MB of memory waste for complex
> > XML.
> > >>> Please don’t mess that up.
> > >>>
> > >>> Thanks,
> > >>> Harbs
> > >>>
> > >>>> On Sep 4, 2019, at 1:02 PM, Greg Dove  wrote:
> > >>>>
> > >>>> This is particularly for Harbs and Yishay, as I think you are both
> (or
> > >>> both
> > >>>> have been) using XML quite a bit. I have quite a few  fixes coming.
> > All
> > >>>> with tests that match on swf and js.
> > >>>>
> > >>>> I am currently working to demonstrate proof of concept to a
> > prospective
> > >>>> client for migration of a Flex app. The app makes extensive use of
> e4x
> > >>> and
> > >>>> uses a bunch of features that I expect had not received attention
> > >>>> previously, because they were originally either not working with the
> > >>>> codebase I am porting, or i think some even caused errors in the
> > >>> javascript
> > >>>> output.
> > >>>>
> > >>>> So I have spent the last several days almost full time figuring
> things
> > >>> out
> > >>>> and working on fixes, between the compiler and emulation classes.
> > >>>> All the previous XML tests continue to pass, but I have many more
> unit
> > >>>> tests and fixes lined up for the following:
> > >>>>
> > >>>> namespace directives
> > >>&g

RoyaleArrayLike - quick summary

2019-10-02 Thread Greg Dove
Just a quick overview of something I added that I was meaning to do for a
long time. It makes a huge difference when porting from things like
ArrayCollection to Royale ArrayList. It saved me hours of menial stuff on
something I had to do recently, and that was also a time-consuming task
that both Carlos and I experienced when working on his app.

The latest updates include support for IArrayList and BinaryData to be used
in for each loops and also to use indexed array access. This works the same
(and uses the same code) to make it work between swf and js - it is
metadata driven.  This only works with strong typing - it is compile-time
only, and follows normal inheritance rules (so AMFBinaryData should also
work the same because it inherits from BinaryData, for example).


So you can do (assuming myArrayList and myOtherArrayList are either
IArrayList typed or some implementing type or subclass such as ArrayList or
ArrayListView):
myArrayList[0] = myOtherArrayList[100]

and it will generate:
myArrayList.setItemAt(myOtherArrayList.getItemAt(100),0)

or:
myBinaryData[0] = 255;

and things like:
for each(var byte:uint in myBinaryData) 

for-each loops (and for-in loops) are supported without special methods or
properties needed on the classes that are supported. There is a single
support function in Language that provides backing support and is included
in the build only if it is needed. At the moment it is a one-size-fits-all
support function.
The loops behave like normal as3 for loops, and handle null target values
and also loop target mutation inside the loop (e.g removeAll() on an
ArrayList loop target instance inside the loop will stop the loop early).
This could also be a safer option for things like XMLList and
ArrayCollection as well, I did not consider that yet, but I will test those
in the coming days.


Re: Heads up on XML

2019-10-02 Thread Greg Dove
@harbs

FYI in addition to some other stuff, I am close to pushing my updates to
XML. This should be in the next hour or so.

I kept the QName caching pretty close to how you had it, with only some
minor changes.
I tried to do some extra memory optimization, and in theory it should
provide better results, but to be honest I don't have a good way to measure
this in the browser. I tried the Chrome performance.memory extensions but I
don't have much confidence in that given how much it varies between reloads
without changing anything else. The extra code changes I made were to make
the '_nodeKind' strings into String object references, so they only refer
to a single reference to a string instead of multiple copies of primitives.
That change is isolated to a single commit so can easily be reversed if
there is something not good about it... but all my local tests continue to
pass. I will get the new tests into RoyaleUnit in the coming days.




On Thu, Sep 5, 2019 at 7:39 AM Greg Dove  wrote:

> Yeah, I saw that ;) Don't worry, I am aware of it.
>
> My first goal is to make sure it works like it should, because that comes
> first, and then to optimize. I'll check the memory side of things and make
> sure it's at least the same as before. If you can point me to some
> publicly accessible large test cases that would be really helpful. I will
> work through that before I push anything.
>
> On Thu, Sep 5, 2019 at 7:26 AM Harbs  wrote:
>
>> Heads up:
>>
>> I did some (on first blush) odd things in XML related to QNames. QNames
>> are pooled and many XML properties are not initialized by default. The
>> reason I did this was it avoided many MB of memory waste for complex XML.
>> Please don’t mess that up.
>>
>> Thanks,
>> Harbs
>>
>> > On Sep 4, 2019, at 1:02 PM, Greg Dove  wrote:
>> >
>> > This is particularly for Harbs and Yishay, as I think you are both (or
>> both
>> > have been) using XML quite a bit. I have quite a few  fixes coming. All
>> > with tests that match on swf and js.
>> >
>> > I am currently working to demonstrate proof of concept to a prospective
>> > client for migration of a Flex app. The app makes extensive use of e4x
>> and
>> > uses a bunch of features that I expect had not received attention
>> > previously, because they were originally either not working with the
>> > codebase I am porting, or i think some even caused errors in the
>> javascript
>> > output.
>> >
>> > So I have spent the last several days almost full time figuring things
>> out
>> > and working on fixes, between the compiler and emulation classes.
>> > All the previous XML tests continue to pass, but I have many more unit
>> > tests and fixes lined up for the following:
>> >
>> > namespace directives
>> > default xml namespace
>> > use namespace (multiple)
>> >
>> > a number of fixes for xml filtering, including:
>> > -'this' resolves correctly in filters that include external references
>> from
>> > the fitler expression to the 'this' scope
>> > -handles alternate ordering of comparisons between XML 'getters' and
>> > literals
>> > e.g. something.(name() = "cat")  or something.("cat" = name()) (these
>> are
>> > the same)
>> > -it (will) now handle XML e4x references in nested function calls inside
>> > the filter, e.g. things like:
>> > e.g.
>> > var people:XML = 
>> >
>> >Bob
>> >32
>> >
>> >
>> >Joe
>> >46
>> >
>> >;
>> > var findJoeByAge:Function = function (i:int):Boolean {
>> >return i > 40;
>> >};
>> > people.person.(findJoeByAge(parseInt(age))).name
>> >
>> >
>> > I have lots more granular tests in QName, Namespace, and XML with
>> tuning to
>> > improve reliability.
>> > toXMLString XML node output also matches flash more correctly in what I
>> > have coming.
>> >
>> > One thing that I am trying to figure out, which I would appreciate
>> input on
>> > if someone has an answer:
>> > For the example:
>> >
>> > var feed:XML = new XML(
>> >'http://www.w3.org/2005/Atom;
>> > xmlns:m="nothing">\n' +
>> >'  > > href="blah/12321/domain/"/>\n' +
>> >   

Re: RoyaleUnit [BeforeClass], [AfterClass], Reflection

2019-09-22 Thread Greg Dove
And fresh eyes on old code usually always finds things that could be
better. I can see an Array sort in there that was likely intended to be
outside a loop instead of inside... oh well :)


On Mon, Sep 23, 2019 at 5:54 AM Greg Dove  wrote:

>
> Josh, here's how I was handling that metadata for the very lightweight
> setup I did:
>
> https://github.com/apache/royale-asjs/blob/develop/manualtests/UnitTests/src/main/royale/testshim/RoyaleUnitTestRunner.as#L134
>
>
> Then the test would run the static BeforeClass, run the instance level
> Before, run all the tests, run the instance level After, then run the
> AfterClass.
> I can't remember the details from when I did that, so can't say for sure
> that it matches what FlexUnit was doing, but I guess my assumption has been
> that it was close at the time.
>
>
> On Mon, Sep 23, 2019 at 5:09 AM Greg Dove  wrote:
>
>> Yeah, iirc those metas run static methods before the test class instance
>> is instantiated and again after the instance level AFTER method has run. At
>> least that's how I think I did it in the manual test version. I don't use
>> those much either. Also afk here for now.. can check later.
>>
>> On Mon, 23 Sep 2019, 04:53 Josh Tynjala, 
>> wrote:
>>
>>> Is that metadata supposed to go on static methods? I guess I assumed
>>> that,
>>> like [Before] and [After], they're supposed to go on instance methods.
>>> I've
>>> never had a reason to use [BeforeClass] and [AfterClass] in a real world
>>> project, so perhaps I should have looked at the FlexUnit examples more
>>> closely.
>>>
>>> I'm not at my computer, so I can't look at the Reflection stuff right
>>> now.
>>> Greg might know, or I can look more closely later.
>>>
>>> - Josh
>>>
>>> On Sunday, September 22, 2019, Yishay Weiss 
>>> wrote:
>>> > Those are not working for me.
>>> >
>>> > I think the problem is that metadata is that only non-static methods
>>> are
>>> iterated when figuring out the meta-data. But then I run into a different
>>> problem, which is how to invoke a static method with reflection.
>>> >
>>> > Any ideas?
>>> >
>>> >
>>>
>>> --
>>> --
>>> Josh Tynjala
>>> Bowler Hat LLC <https://bowlerhat.dev>
>>>
>>


Re: RoyaleUnit [BeforeClass], [AfterClass], Reflection

2019-09-22 Thread Greg Dove
Josh, here's how I was handling that metadata for the very lightweight
setup I did:
https://github.com/apache/royale-asjs/blob/develop/manualtests/UnitTests/src/main/royale/testshim/RoyaleUnitTestRunner.as#L134


Then the test would run the static BeforeClass, run the instance level
Before, run all the tests, run the instance level After, then run the
AfterClass.
I can't remember the details from when I did that, so can't say for sure
that it matches what FlexUnit was doing, but I guess my assumption has been
that it was close at the time.


On Mon, Sep 23, 2019 at 5:09 AM Greg Dove  wrote:

> Yeah, iirc those metas run static methods before the test class instance
> is instantiated and again after the instance level AFTER method has run. At
> least that's how I think I did it in the manual test version. I don't use
> those much either. Also afk here for now.. can check later.
>
> On Mon, 23 Sep 2019, 04:53 Josh Tynjala, 
> wrote:
>
>> Is that metadata supposed to go on static methods? I guess I assumed that,
>> like [Before] and [After], they're supposed to go on instance methods.
>> I've
>> never had a reason to use [BeforeClass] and [AfterClass] in a real world
>> project, so perhaps I should have looked at the FlexUnit examples more
>> closely.
>>
>> I'm not at my computer, so I can't look at the Reflection stuff right now.
>> Greg might know, or I can look more closely later.
>>
>> - Josh
>>
>> On Sunday, September 22, 2019, Yishay Weiss 
>> wrote:
>> > Those are not working for me.
>> >
>> > I think the problem is that metadata is that only non-static methods are
>> iterated when figuring out the meta-data. But then I run into a different
>> problem, which is how to invoke a static method with reflection.
>> >
>> > Any ideas?
>> >
>> >
>>
>> --
>> --
>> Josh Tynjala
>> Bowler Hat LLC <https://bowlerhat.dev>
>>
>


Re: RoyaleUnit [BeforeClass], [AfterClass], Reflection

2019-09-22 Thread Greg Dove
Yeah, iirc those metas run static methods before the test class instance is
instantiated and again after the instance level AFTER method has run. At
least that's how I think I did it in the manual test version. I don't use
those much either. Also afk here for now.. can check later.

On Mon, 23 Sep 2019, 04:53 Josh Tynjala,  wrote:

> Is that metadata supposed to go on static methods? I guess I assumed that,
> like [Before] and [After], they're supposed to go on instance methods. I've
> never had a reason to use [BeforeClass] and [AfterClass] in a real world
> project, so perhaps I should have looked at the FlexUnit examples more
> closely.
>
> I'm not at my computer, so I can't look at the Reflection stuff right now.
> Greg might know, or I can look more closely later.
>
> - Josh
>
> On Sunday, September 22, 2019, Yishay Weiss 
> wrote:
> > Those are not working for me.
> >
> > I think the problem is that metadata is that only non-static methods are
> iterated when figuring out the meta-data. But then I run into a different
> problem, which is how to invoke a static method with reflection.
> >
> > Any ideas?
> >
> >
>
> --
> --
> Josh Tynjala
> Bowler Hat LLC 
>


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

2019-09-18 Thread Greg Dove
Responses also inline.
Beyond this reply, I'm going to dip out and let others contribute their
ideas for a bit... because I really need to focus on other things for now.
If I go silent that is why.

On Thu, Sep 19, 2019 at 7:14 AM Alex Harui  wrote:

> Responses inline.
>
> On 9/18/19, 11:53 AM, "Greg Dove"  wrote:
>
> Alex, the idea was to make the js output itself support the options,
> without any need to manipulate any files at all.
> Why would you not want to use goog defines?
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23define-type-descriptiondata=02%7C01%7Caharui%40adobe.com%7C05e47962202a40946eac08d73c697d85%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044296118065315sdata=6RqR1nhJBOv9u0nAwGst325wXtHwWuKozGPZncE2FY0%3Dreserved=0
>
> It seems like the easiest way and it leverages the strength of GCC.
>
> if (JSBuild.includeReflection) {
> regular reflection data
> }
>
> I haven’t spent a lot of time thinking about this, but I don't see how a
> flag like JSBUild.includeReflection will drop reflection data for framework
> classes unless we specify only certain classes as "framework classes" and
> thus give only them that flag.
>

A single flag wouldn't. But with some careful planning a set of bit flags
could be used to achieve reasonable selectability I think. Not something
for most users, I agree. TBH I don't think most people will care about this
level of detail for reflection, but I can see people definitely wanting to
exclude it if they never use it in their app, and I'm sure some might want
to really tune it at a granular level. Perhaps there is simply and on and
off switch and the codeflow approach you mentioned can be introduced later
for people who want the real stuff.

>
> redefining that JSBuild.includeReflection goog define to be false at
> the
> application build stage (which is for illustrative purposes here
> only,  and
> would be true by default), eliminates it from all classes (that have
> had it
> included in the js output) in the release build, just like how
> goog.DEBUG
> works now.
>
> Having alternate swcs sounds complicated to me. It's different, but in
> some
> ways conceptually similar to monkey patching I guess (which works
> also).
> But it seems less desirable than being able to get everything you need
> from
> the one swc.
>
> OT: For the public vars stuff, that is not an issue for AMF
> serialization.
> Reflection classes do support the public var renaming and AMF works
> fine
> with the minimized names. I think the general issue with public vars is
> that people can use regular dynamic access in actionscript, and that
> should
> work by default rather than be another hurdle. But of course it should
> also
> be able to be switched back to how it is now.
>
> public vars is not OT.  It is the subject of this thread.  I'm curious as
> to how AMF supports the minified names.  When an object comes in from the
> server with a "name" property, how do you know it is now called "aa"?
>
> Good call.
The Variabledefinition and AccessorDefinition classes both have getValue
and setValue on-demand getter/setter creation. Support for public vars uses
a single function that serves as a getter/setter internally which supports
the renamed value in terms of getting/setting. Because all this is created
on demand it does not add any overhead at startup, but it works like it
should when it is needed via reflection. It's battle tested, works for AMF
and Crux and I also use it in the manual-tests unit testing setup to run
the same tests across debug and release builds. So to answer your
question... it doesn't know or care what the renamed name is, the
reflection class will map to it via its own gettter/setter approach.


> The ideas for the  granular stuff are interesting, but I think we need
> to
> go with things that are achievable in the near future, unless you
> realistically think the code-flow stuff is something you can work on.
> I don't think it's for me, but I believe I can do the stuff I already
> mentioned. And I don't expect the approaches would be mutually
> exclusive in
> terms of evolving things in the future.
>
> My point is to be careful as to how much time we make folks spend trying
> to understand our compiler options when we might want to do more
> intelligent things instead.  Having metadata or an interface drive the
> output of public var is not complex like code-flow analysis and might avoid
> folks having to learn some of these options or implement more options.  Or
> we might try

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

2019-09-18 Thread Greg Dove
Alex, the idea was to make the js output itself support the options,
without any need to manipulate any files at all.
Why would you not want to use goog defines?
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#define-type-description

It seems like the easiest way and it leverages the strength of GCC.

if (JSBuild.includeReflection) {
regular reflection data
}

redefining that JSBuild.includeReflection goog define to be false at the
application build stage (which is for illustrative purposes here only,  and
would be true by default), eliminates it from all classes (that have had it
included in the js output) in the release build, just like how goog.DEBUG
works now.

Having alternate swcs sounds complicated to me. It's different, but in some
ways conceptually similar to monkey patching I guess (which works also).
But it seems less desirable than being able to get everything you need from
the one swc.

OT: For the public vars stuff, that is not an issue for AMF serialization.
Reflection classes do support the public var renaming and AMF works fine
with the minimized names. I think the general issue with public vars is
that people can use regular dynamic access in actionscript, and that should
work by default rather than be another hurdle. But of course it should also
be able to be switched back to how it is now.

The ideas for the  granular stuff are interesting, but I think we need to
go with things that are achievable in the near future, unless you
realistically think the code-flow stuff is something you can work on.
I don't think it's for me, but I believe I can do the stuff I already
mentioned. And I don't expect the approaches would be mutually exclusive in
terms of evolving things in the future.

Whatever the menu 'buckets' are can be debated, but they would simply be
sets of granular settings that people don't have to try to understand if
they don't want to.



On Thu, Sep 19, 2019 at 5:24 AM Alex Harui  wrote:

> I probably won't object to folks trying out different config options, but
> the 3 buckets Harbs proposed didn't make any sense to me.  I would want to
> turn them all on, and not be sure what the trade-offs are.
>
> IMO, modifying the JS from SWCs after compilation is "easy" in the sense
> that it is all regular expressions in text and JS allows for it (at least
> so far).  The compiler already has options to skip linking certain
> classes.  That syntax can be extended to skip or modify some of the JS for
> a class.  Also, the GoogDepsWriter reads just about every file already so
> doing more automated text manipulation is also "easy".
>
> Also note that code-flow-analysis is also possible and may allow us to
> automatically/intelligently modify/remove code someday, so some of these
> options may be interim solutions.  For example, it might be possible to
> know which classes are being passed into Reflection and thus toss the
> reflection data from all of the other classes.
>
> I haven't tried this, but I've also considered that instead of compile
> options that you can link in alternate SWCs with alternate code, or that
> will overwrite the prototype at runtime to alter how things behave.
>
> Also, regarding public vars specifically, it may be that we use metadata
> to generate different code for vars.  We already do that with [Bindable].
>  It may be that if a class isn't a UI class and has [ClassAlias] or
> implements IExternalizable that we convert all vars to getter/setter (or do
> something else to prevent renaming) and that will the right default.  Or
> invent some new metadata to signal different var output.
>
> In summary, large bucket options can be confusing, granular options can be
> painful, but we might be able to use code-flow or other hints and get it
> right more often than we do now.
>
> My 2 cents,
> -Alex
>
>
>
> On 9/18/19, 9:45 AM, "Greg Dove"  wrote:
>
> I think it could be as simple as having something like a class (eg.
> JSBuild) with a bunch of static goog @defines. These could be used to
> delimit sections of output that provide things like reflection, default
> initialized, vector runtime checking etc. In a sense it is not much
> different to how you might think of as3 compile flag stuff. But perhaps
> there are ways to use some bitwise flag sets that evaluate to compile
> time
> constants (for GCC) to achieve some of the granular/selective content
> discrimination like I described with the hypothetical reflection
> optimization example. E.g framework vs non-framework/ UI vs. non-UI. I
> realise that all sounds complicated, which is why simple combos would
> be
> good for most people as Harbs mentioned.
>
> On Thu, 19 Sep 2019, 02:15 Harbs,  wrote:
>
> > Abs

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

2019-09-18 Thread Greg Dove
I think it could be as simple as having something like a class (eg.
JSBuild) with a bunch of static goog @defines. These could be used to
delimit sections of output that provide things like reflection, default
initialized, vector runtime checking etc. In a sense it is not much
different to how you might think of as3 compile flag stuff. But perhaps
there are ways to use some bitwise flag sets that evaluate to compile time
constants (for GCC) to achieve some of the granular/selective content
discrimination like I described with the hypothetical reflection
optimization example. E.g framework vs non-framework/ UI vs. non-UI. I
realise that all sounds complicated, which is why simple combos would be
good for most people as Harbs mentioned.

On Thu, 19 Sep 2019, 02:15 Harbs,  wrote:

> Absolutely. Now we just need to figure out how… ;-)
>
> > On Sep 18, 2019, at 5:10 PM, Josh Tynjala 
> wrote:
> >
> >> I think the main thing we are missing (from my perspective) is to avoid
> > the need to recompile the swcs to swap things in and out.
> >
> > I think that being able to switch things off and on without recompiling
> > SWCs would be awesome. Without that control, we will continue to struggle
> > with differing opinions on how it should work.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Wed, Sep 18, 2019 at 12:31 AM Greg Dove  wrote:
> >
> >> I agree 100% Harbs. And I think that is not difficult to achieve.
> >>
> >> The decisions and collaborative effort need to take place in the
> planning
> >> side of things to figure out the reasonable set of granular things to
> >> support. Perhaps we can do that once the 'dust has settled' after 0.9.6
> is
> >> out. Then your 3 sets (or whatever is decided to be the menu) could
> simply
> >> be defined as a collection of settings for those, with people free to
> tune
> >> things at a more granular level if they wanted.
> >> I might want to, for example, be able to strip out reflection data from
> UI
> >> based Framework classes but keep it for all other framework stuff, and
> all
> >> my own custom UI components, (perhaps that sounds weird, but I can
> think of
> >> this as being useful in a real-world scenario with Crux). Whether that
> >> level or control is reasonable for us to support is probably
> questionable.
> >> But I think it is *possible*. This is the same type of granular
> switching I
> >> was trying to explain for switching off Vector runtime checking in
> recent
> >> months, but I did not get a sense that anyone clearly understood what I
> was
> >> trying to convey at the time (my impression only).
> >>
> >> I think the main thing we are missing (from my perspective) is to avoid
> the
> >> need to recompile the swcs to swap things in and out.
> >> Anyway, I will stop talking about this, I just wanted to highlight the
> fact
> >> that I believe we can technically meet most people's needs, whatever
> they
> >> are, but that I also think the general need is best served by matching
> as3
> >> behavior by default, as Josh has proposed for public vars.
> >>
> >>
> >>
> >> On Tue, Sep 17, 2019 at 10:28 PM Harbs  wrote:
> >>
> >>> Rather than having to specify a whole slew of compiler options, I’d
> like
> >>> to see 2 or 3 compiler configurations that would set the defaults on a
> >>> group of options to get the best default behavior for a use case.
> >>> Maybe something like this:
> >>>
> >>> js-config=compatible (for maximum, compatibility with Flash behavior)
> >>> js-config=optimized (for minimum code size)
> >>> js-config=safe (for best type safety but not necessarily Flash
> >> compatible)
> >>>
> >>> Obviously, you could override the defaults on any one of these, but I
> >> hope
> >>> we could give predefined sets of defaults which cover the vast majority
> >> of
> >>> use cases out of the box.
> >>>
> >>> It’s hard learning all the compiler options, but being able to specify
> a
> >>> few sets of defaults seems reasonable.
> >>>
> >>> Harbs
> >>>
> >>>> On Sep 17, 2019, at 11:02 AM, Greg Dove  wrote:
> >>>>
> >>>> I personally would use a non-default setting to keep things as they
> are
> >>>> right now, but I agree with Josh in that as it is, I don't think it's
> a
> >>>> good hu

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

2019-09-18 Thread Greg Dove
I agree 100% Harbs. And I think that is not difficult to achieve.

The decisions and collaborative effort need to take place in the planning
side of things to figure out the reasonable set of granular things to
support. Perhaps we can do that once the 'dust has settled' after 0.9.6 is
out. Then your 3 sets (or whatever is decided to be the menu) could simply
be defined as a collection of settings for those, with people free to tune
things at a more granular level if they wanted.
I might want to, for example, be able to strip out reflection data from UI
based Framework classes but keep it for all other framework stuff, and all
my own custom UI components, (perhaps that sounds weird, but I can think of
this as being useful in a real-world scenario with Crux). Whether that
level or control is reasonable for us to support is probably questionable.
But I think it is *possible*. This is the same type of granular switching I
was trying to explain for switching off Vector runtime checking in recent
months, but I did not get a sense that anyone clearly understood what I was
trying to convey at the time (my impression only).

I think the main thing we are missing (from my perspective) is to avoid the
need to recompile the swcs to swap things in and out.
Anyway, I will stop talking about this, I just wanted to highlight the fact
that I believe we can technically meet most people's needs, whatever they
are, but that I also think the general need is best served by matching as3
behavior by default, as Josh has proposed for public vars.



On Tue, Sep 17, 2019 at 10:28 PM Harbs  wrote:

> Rather than having to specify a whole slew of compiler options, I’d like
> to see 2 or 3 compiler configurations that would set the defaults on a
> group of options to get the best default behavior for a use case.
> Maybe something like this:
>
> js-config=compatible (for maximum, compatibility with Flash behavior)
> js-config=optimized (for minimum code size)
> js-config=safe (for best type safety but not necessarily Flash compatible)
>
> Obviously, you could override the defaults on any one of these, but I hope
> we could give predefined sets of defaults which cover the vast majority of
> use cases out of the box.
>
> It’s hard learning all the compiler options, but being able to specify a
> few sets of defaults seems reasonable.
>
> Harbs
>
> > On Sep 17, 2019, at 11:02 AM, Greg Dove  wrote:
> >
> > I personally would use a non-default setting to keep things as they are
> > right now, but I agree with Josh in that as it is, I don't think it's a
> > good hurdle to present to new users, or people in general that simply
> want
> > things to 'work' out of the box, based on what they should reasonably
> > expect to work. The language layer is the foundation for building
> > everything else. People have serious doubts when things don't work right
> at
> > that level. I have had to reassure people about this recently (XML -
> still
> > working on it - soon!).
> >
> > We have only touched the surface of what we could do with GCC for tuning
> > the output. There are ways to have all the default stuff in there but
> > selectively remove it from release builds without having to recompile
> > library code, for example. So I think it is possible that we could
> provide
> > flexible solutions that match whatever we consider people want.
> > But in terms of defaults, is it not obvious that it we should be guided
> by
> > actionscript 3 language itself and the reference implementation we
> already
> > have? We can't always match things, but I think the onus is on us to get
> as
> > close as we can by default.
> >
> >
> > On Tue, Sep 17, 2019 at 5:59 PM Alex Harui 
> wrote:
> >
> >> Some folks want us to get smarter and not automatically export all
> public
> >> methods and getter/setters.  There are a lot of just-in-case strings in
> >> Royale apps.  That's not good.  So better control over things even after
> >> compiling without being painful to use is the goal.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 9/16/19, 12:39 PM, "Josh Tynjala" 
> wrote:
> >>
> >>I was thinking about this some more, and is there anything else
> that's
> >>public that also we allow to be renamed? I'm not aware of anything,
> but
> >>maybe I've missed something. If it's true, it seems inconsistent to
> >> allow
> >>public variables to be the one exception that should be renamed. If
> >> public
> >>methods, properties, and other things can't be renamed, public
> >> variables
> >>shouldn't be either.
> >>
> >>Loo

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

2019-09-17 Thread Greg Dove
I personally would use a non-default setting to keep things as they are
right now, but I agree with Josh in that as it is, I don't think it's a
good hurdle to present to new users, or people in general that simply want
things to 'work' out of the box, based on what they should reasonably
expect to work. The language layer is the foundation for building
everything else. People have serious doubts when things don't work right at
that level. I have had to reassure people about this recently (XML - still
working on it - soon!).

We have only touched the surface of what we could do with GCC for tuning
the output. There are ways to have all the default stuff in there but
selectively remove it from release builds without having to recompile
library code, for example. So I think it is possible that we could provide
flexible solutions that match whatever we consider people want.
But in terms of defaults, is it not obvious that it we should be guided by
actionscript 3 language itself and the reference implementation we already
have? We can't always match things, but I think the onus is on us to get as
close as we can by default.


On Tue, Sep 17, 2019 at 5:59 PM Alex Harui  wrote:

> Some folks want us to get smarter and not automatically export all public
> methods and getter/setters.  There are a lot of just-in-case strings in
> Royale apps.  That's not good.  So better control over things even after
> compiling without being painful to use is the goal.
>
> My 2 cents,
> -Alex
>
> On 9/16/19, 12:39 PM, "Josh Tynjala"  wrote:
>
> I was thinking about this some more, and is there anything else that's
> public that also we allow to be renamed? I'm not aware of anything, but
> maybe I've missed something. If it's true, it seems inconsistent to
> allow
> public variables to be the one exception that should be renamed. If
> public
> methods, properties, and other things can't be renamed, public
> variables
> shouldn't be either.
>
> Looking into the configuration classes, I see that we have the
> export-public-symbols compiler option. That seems like it's the one
> that is
> meant to control whether public things should be renamed or not. It's
> true
> by default. I have no issue with public variables being renamed when
> it's
> false. Again, that would be consistent with how the compiler handles
> other
> public things.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795496907sdata=ii0taRMhu0bD0Ea577FNZ9CzDn%2B60MAdu7VsVIA92W4%3Dreserved=0
> >
>
>
> On Mon, Sep 16, 2019 at 11:13 AM Josh Tynjala <
> joshtynj...@bowlerhat.dev>
> wrote:
>
> > Unfortunately, people actively avoid using public vars because we
> warn
> > about them. Our warnings are too aggressive if it doesn't actually
> matter
> > most of the time. Plus, this warning leaves a bad impression because
> it's
> > such a basic feature of the language that pretty much everyone uses.
> >
> > What can we do to provide a more sensible default behavior, while
> also
> > giving someone the ability to tell the compiler that everything can
> be
> > renamed (or selective renaming)?
> >
> > We could add an option that doesn't rename public things by default,
> but
> > can also be toggled to rename everything. I guess we could have some
> > @royalewhatever annotations to give someone selective control over
> which
> > things are renamed or not, if someone needs that. Thoughts?
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795496907sdata=ii0taRMhu0bD0Ea577FNZ9CzDn%2B60MAdu7VsVIA92W4%3Dreserved=0
> >
> >
> >
> > On Mon, Sep 16, 2019 at 10:50 AM Alex Harui  >
> > wrote:
> >
> >> I'm not sure I understand your proposal.  Are you proposing that all
> >> public variables will be quoted and thus not renamed so we never
> warn
> >> again?  I am not in favor of that.  IMO, the vast majority of
> public vars
> >> can be renamed without penalty.  It is only certain classes that
> will be
> >> mapped to external code that matter.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 9/16/19, 10:46 AM, "Josh Tynjala" 
> wrote:
> >>
> >> You're right. After a number of tests, I cannot find any
> annotation
> >> (or
> >> combination of them) that will prevent the renaming of variables
> >> defined on
> >> a prototype. All of the official advice that I see from Google
> >> suggests
> >> quoting the properties (or using externs). So, from a Royale
> >> 

Re: Question about stringifyNode

2019-09-13 Thread Greg Dove
Thanks, Yeah I expected it to create mappings. I just wondered if it might
create problems with offsets if the final output does not align with
whatever happened during the original walk. I will investigate further as I
get along with what I am doing.




On Sat, Sep 14, 2019 at 11:20 AM Josh Tynjala 
wrote:

> When I was first implementing source maps, I remember running into an issue
> where a use of stringifyNode() was messing them up. I don't remember the
> exact details, but I think I had to shift some of the logic around to get
> the mappings into the correct order. If that's right, then yes,
> stringifyNode() will create mappings.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Fri, Sep 13, 2019 at 4:08 PM Greg Dove  wrote:
>
> > Josh, I think this is a question more for you...
> >
> > In terms of source mapping... is the 'stringifyNode' pattern that is used
> > in some places supported?
> >
> > For example
> >
> > s = stringifyNode(myNode); //<-walks and presumably creates mappings like
> > normal
> >
> > write("("): //<-- some wrapper around 's' content (could be any arbitrary
> > length pre-pended for example
> > s = s.substring(2,s.length()-3); //<--- some manipulation of s
> > write(")") //<-- something else to wrap the stuff that changed.
> >
> > I did not look to see if this was somehow supported, so this is just a
> lazy
> > question based on my wondering if/how it was. I did not specifically test
> > output that uses those parts yet.
> >
>


Re: Question about stringifyNode

2019-09-13 Thread Greg Dove
sorry there is probably a write(s); in the middle there as well :)

On Sat, Sep 14, 2019 at 11:08 AM Greg Dove  wrote:

> Josh, I think this is a question more for you...
>
> In terms of source mapping... is the 'stringifyNode' pattern that is used
> in some places supported?
>
> For example
>
> s = stringifyNode(myNode); //<-walks and presumably creates mappings like
> normal
>
> write("("): //<-- some wrapper around 's' content (could be any arbitrary
> length pre-pended for example
> s = s.substring(2,s.length()-3); //<--- some manipulation of s
> write(")") //<-- something else to wrap the stuff that changed.
>
> I did not look to see if this was somehow supported, so this is just a
> lazy question based on my wondering if/how it was. I did not specifically
> test output that uses those parts yet.
>
>


Question about stringifyNode

2019-09-13 Thread Greg Dove
Josh, I think this is a question more for you...

In terms of source mapping... is the 'stringifyNode' pattern that is used
in some places supported?

For example

s = stringifyNode(myNode); //<-walks and presumably creates mappings like
normal

write("("): //<-- some wrapper around 's' content (could be any arbitrary
length pre-pended for example
s = s.substring(2,s.length()-3); //<--- some manipulation of s
write(")") //<-- something else to wrap the stuff that changed.

I did not look to see if this was somehow supported, so this is just a lazy
question based on my wondering if/how it was. I did not specifically test
output that uses those parts yet.


Re: Discuss of release steps preparation

2019-09-13 Thread Greg Dove
Oh thanks, Josh! I will do that later today.


On Sat, Sep 14, 2019 at 5:32 AM Josh Tynjala 
wrote:

> In royale-compiler, I already added my release notes from develop into
> release/0.9.6. I simply forgot to do the same for royale-asjs. I added
> that
> line about RoyaleUnit just now. Go ahead and add yours too, Greg. We'll be
> merging release/0.9.6 back into develop later, so if you put them directly
> in release/0.9.6, they won't be lost.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Fri, Sep 13, 2019 at 10:24 AM Greg Dove  wrote:
>
> > Hi Piotr,
> >
> > I'm not so familiar with the release process. Do you want additions to go
> > directly into the release branch or should that be added to develop
> > (assuming you would merge into release)?
> >
> > I see Josh added note about RoyalUnit in develop [1], which is not yet in
> > release.[2] . So perhaps you will merge from develop? I'm not sure how
> this
> > all needs to work.
> >
> > I'm thinking to add the following to 0.9.6 release notes (changes since
> > 0.9.4) for some of the things I worked on:
> >
> > -Improvements to AMF / RemoteObject Support
> > -AMFBinaryData api now matches flash.utils.ByteArray, (the missing
> feature
> > is non-UTF String encoding support). It therefore now works for deep
> > cloning via readObject/writeObject and registerClassAlias.
> > -Updates to Royale collections library with support for sorting and
> > filtering via ArrayListView. Simple example added to Tour de Jewel
> > -A conforming runtime implementation of AS3 Vector (typed Arrays) was
> added
> > for javascript output, with options for avoiding certain runtime checks.
> > -int, uint, Class are now represented as simple, distinct types (Class is
> > now not 'Object', int is now not 'Number' for example), and these support
> > indirect 'as' or 'is' type checking and instantiation, matching swf
> > behavior.
> > -General Improvements and additions in Reflection library
> > -New Apache Royale Crux MVC/DI/IOC application architecture library
> (based
> > on Swiz Framework) was added, with some simple examples
> >
> > If it's too late to add those, no worries, I can add that to the 'Updates
> > to the RELEASE_NOTES discovered after this file was packaged' wiki
> >
> > 1. https://github.com/apache/royale-asjs/blob/develop/RELEASE_NOTES.md
> > 2.
> >
> https://github.com/apache/royale-asjs/blob/release/0.9.6/RELEASE_NOTES.md
> >
> >
> > Thanks,
> > Greg
> >
> > On Fri, Sep 13, 2019 at 8:49 PM Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> > wrote:
> >
> > > Hi Guys,
> > >
> > > I would like to cut RC1 again on Monday, so if anything should be
> tested
> > or
> > > added please do so before Monday.
> > >
> > > Let me know if anything is against that.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > On Fri, Sep 13, 2019, 12:32 AM Alex Harui 
> > > wrote:
> > >
> > > > I pushed changes to update the config.xml files.  It seemed to work
> for
> > > > me.  Try beta10 if you want to test it.
> > > >
> > > > npm install  @apache-royale/royale-js-swf@0.9.6-beta10 -g
> > > >
> > > > Thanks,
> > > > -Alex
> > > >
> > > > On 9/12/19, 10:56 AM, "Alex Harui" 
> wrote:
> > > >
> > > > I guess that’s expected.  I didn’t realize I had a
> > PLAYERGLOBAL_HOME
> > > > environment variable that was overriding.
> > > >
> > > > The post install script would have to go replace the
> target-player
> > in
> > > > every -config.xml file (like royale-config.xml).  If you add
> > > > -target-player=25.0, that will get you past it.
> > > >
> > > > Another option is to have the install download 11.1 instead of
> > 25.0.
> > > >
> > > > Thoughts?
> > > > -Alex
> > > >
> > > >
> > > > On 9/12/19, 10:30 AM, "Carlos Rovira" 
> > > wrote:
> > > >
> > > > Hi Alex,
> > > >
> > > > I uninstall then install again. Commented all my paths
> (royale,
> > > > flash
> > > > player, AIR,...) in my .bash_profile. Then open a new
> terminal
> > > > window.
> > > >
> > > > Results:
> > > >
> > > > macbookpr

Re: Discuss of release steps preparation

2019-09-13 Thread Greg Dove
Hi Piotr,

I'm not so familiar with the release process. Do you want additions to go
directly into the release branch or should that be added to develop
(assuming you would merge into release)?

I see Josh added note about RoyalUnit in develop [1], which is not yet in
release.[2] . So perhaps you will merge from develop? I'm not sure how this
all needs to work.

I'm thinking to add the following to 0.9.6 release notes (changes since
0.9.4) for some of the things I worked on:

-Improvements to AMF / RemoteObject Support
-AMFBinaryData api now matches flash.utils.ByteArray, (the missing feature
is non-UTF String encoding support). It therefore now works for deep
cloning via readObject/writeObject and registerClassAlias.
-Updates to Royale collections library with support for sorting and
filtering via ArrayListView. Simple example added to Tour de Jewel
-A conforming runtime implementation of AS3 Vector (typed Arrays) was added
for javascript output, with options for avoiding certain runtime checks.
-int, uint, Class are now represented as simple, distinct types (Class is
now not 'Object', int is now not 'Number' for example), and these support
indirect 'as' or 'is' type checking and instantiation, matching swf
behavior.
-General Improvements and additions in Reflection library
-New Apache Royale Crux MVC/DI/IOC application architecture library (based
on Swiz Framework) was added, with some simple examples

If it's too late to add those, no worries, I can add that to the 'Updates
to the RELEASE_NOTES discovered after this file was packaged' wiki

1. https://github.com/apache/royale-asjs/blob/develop/RELEASE_NOTES.md
2.
https://github.com/apache/royale-asjs/blob/release/0.9.6/RELEASE_NOTES.md


Thanks,
Greg

On Fri, Sep 13, 2019 at 8:49 PM Piotr Zarzycki 
wrote:

> Hi Guys,
>
> I would like to cut RC1 again on Monday, so if anything should be tested or
> added please do so before Monday.
>
> Let me know if anything is against that.
>
> Thanks,
> Piotr
>
> On Fri, Sep 13, 2019, 12:32 AM Alex Harui 
> wrote:
>
> > I pushed changes to update the config.xml files.  It seemed to work for
> > me.  Try beta10 if you want to test it.
> >
> > npm install  @apache-royale/royale-js-swf@0.9.6-beta10 -g
> >
> > Thanks,
> > -Alex
> >
> > On 9/12/19, 10:56 AM, "Alex Harui"  wrote:
> >
> > I guess that’s expected.  I didn’t realize I had a PLAYERGLOBAL_HOME
> > environment variable that was overriding.
> >
> > The post install script would have to go replace the target-player in
> > every -config.xml file (like royale-config.xml).  If you add
> > -target-player=25.0, that will get you past it.
> >
> > Another option is to have the install download 11.1 instead of 25.0.
> >
> > Thoughts?
> > -Alex
> >
> >
> > On 9/12/19, 10:30 AM, "Carlos Rovira" 
> wrote:
> >
> > Hi Alex,
> >
> > I uninstall then install again. Commented all my paths (royale,
> > flash
> > player, AIR,...) in my .bash_profile. Then open a new terminal
> > window.
> >
> > Results:
> >
> > macbookpro:~ carlosrovira$ mxmlc
> >
> > Using Royale Compiler codebase:
> >
> >
> /usr/local/lib/node_modules/@apache-royale/royale-js-swf/royale-asjs/js/bin/../..
> >
> > Using Royale SDK:
> >
> >
> /usr/local/lib/node_modules/@apache-royale/royale-js-swf/royale-asjs/js/bin/../..
> >
> > MXMLJSC
> >
> >
> >
> +royalelib=/usr/local/lib/node_modules/@apache-royale/royale-js-swf/royale-asjs/js/bin/../../frameworks
> >
> >
> >
> -sdk-js-lib=/usr/local/lib/node_modules/@apache-royale/royale-js-swf/royale-asjs/js/bin/../../frameworks/js/Royale/generated-sources
> >
> >
> >
> /usr/local/lib/node_modules/@apache-royale/royale-js-swf/royale-asjs/frameworks/royale-config.xml(74):
> > col: 0 Error: unable to open
> >
> >
> '/usr/local/lib/node_modules/@apache-royale/royale-js-swf/royale-asjs/frameworks/libs/player/11.1/playerglobal.swc'.
> >
> >
> >
> /usr/local/lib/node_modules/@apache-royale/royale-js-swf/royale-asjs/frameworks/royale-config.xml
> > (line: 74)
> >
> >
> >   
> >
> >
> >
> >
> >
> /usr/local/lib/node_modules/@apache-royale/royale-js-swf/royale-asjs/frameworks/royale-config.xml(129):
> > col: 0 Error: unable to open
> >
> >
> '/usr/local/lib/node_modules/@apache-royale/royale-js-swf/royale-asjs/frameworks/libs/player/11.1'.
> >
> >
> >
> /usr/local/lib/node_modules/@apache-royale/royale-js-swf/royale-asjs/frameworks/royale-config.xml
> > (line: 129)
> >
> >
> >   
> >
> >
> >
> > 0.68472554 seconds
> >
> > macbookpro:~ carlosrovira$
> >
> >
> >
> >
> > Hope results are the expected ones :)
> >
> >
> > Best
> >
> >
> > Carlos
> >
> > El jue., 12 sept. 2019 a las 18:46, Alex Harui
> > ()
> > escribió:
> >
> > > Thanks for catching the places where FlexJS was still being
> used.
> > >
> > > Your output indicates that there is a ROYALE_HOME 

Re: Heads up on XML

2019-09-10 Thread Greg Dove
And... I'm still going. I keep finding things that need addressing. I am in
attributes now.

Anyway, I haven't gotten to the memory testing yet and I need to focus
tomorrow on showing my client progress, so I'm sorry but this code will be
another couple of days.

If you do look into the as2 XMLDocument stuff and find issues with
emulating that in Royale XML, feel free to ask me about anything that might
be changing (to match what swf does). Otherwise it might be easier to wait
and see if you really need some of those fixes. Once again, sorry for the
delay. I prefer to get what I get in 'right' rather than have only some of
it right.




On Mon, Sep 9, 2019 at 5:33 PM Alex Harui  wrote:

> No problem.  I've spent today trying to fix the build in the Ant source
> package.
>
> -Alex
>
> On 9/8/19, 10:03 PM, "Greg Dove"  wrote:
>
> Not quite there yet with the final changes, I'm afraid. I'm getting
> close... should be tomorrow my time.
>
>
> On Sun, Sep 8, 2019 at 7:32 AM Greg Dove  wrote:
>
> >
> > Yeah thanks Josh, Alex made a suggestion for that option too, it was
> the
> > one I thought I would try first. I hope to get there later today, so
> I will
> > see if I can figure that out.
> >
> >
> > On Sun, Sep 8, 2019 at 7:20 AM Josh Tynjala <
> joshtynj...@bowlerhat.dev>
> > wrote:
> >
> >> I think the DITA files generated by asdoc are pretty big too, so
> they're
> >> probably really useful for your testing.
> >>
> >> - Josh
> >>
> >> On Friday, September 6, 2019, Greg Dove 
> wrote:
> >> > 'I think that SWFDump will generate valid XML and there is a way
> to get
> >> > DITA files from Flex ASDoc that are valid XML.'
> >> > Sounds like a good idea for some large xml files. I did not use
> that
> >> yet,
> >> > so will take a look and see if I can figure it out. Thanks!
> >> >
> >> >
> >> > On Sat, Sep 7, 2019 at 12:30 PM Greg Dove 
> wrote:
> >> >
> >> >>
> >> >> Just to clarify I was referring to this stuff here:
> >> >>
> >> >>
> >> >>
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2F8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab%2Fframeworks%2Fprojects%2FMXRoyale%2Fsrc%2Fmain%2Froyale%2Fmx%2Frpc%2Fhttp%2FAbstractOperation.as%23L1038data=02%7C01%7Caharui%40adobe.com%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036021948216407sdata=7V0k6g15%2FwI2JY7v7E32iLjX6lIUSkOs9%2BpRDfhOrGI%3Dreserved=0
> >> >>
> >> >>
> >> >> with '//old XML style'
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui
> 
> >> >> wrote:
> >> >>
> >> >>> I haven't looked at what XML is used/supported by MX
> HTTPService.  It
> >> >>> looks like WebService does use MX HTTPService.  I am currently
> >> migrating
> >> >>> other things that WebService needs (XMLEncoder/Decoder,
> >> >>> SOAPEncoder/Decoder).  These are new files that aren't in the
> repo
> >> yet,
> >> so
> >> >>> HTTPService couldn't be relying on them or else their use is
> commented
> >> >>> out.   The goal is to change as little as possible to get it to
> >> compile
> >> and
> >> >>> then see if it runs.  I have no idea yet if the XML
> improvements you
> >> are
> >> >>> working on are going to be impactful on what I'm doing or not.
> >> >>>
> >> >>> BTW, I could be wrong, but I think that SWFDump will generate
> valid
> >> XML
> >> >>> and there is a way to get DITA files from Flex ASDoc that are
> valid
> >> XML.
> >> >>>
> >> >>> Thanks for the heads up,
> >> >>> -Alex
> >> >>>
> >> >>> On 9/6/19, 5:14 PM, "Greg Dove"  wrote:
> >> >>>
> >> >>> Actually I know you are looking into the WSDL stuff
> maybe this
> >> is
> >> >>> going
>     >> >>> 

Re: Heads up on XML

2019-09-08 Thread Greg Dove
Not quite there yet with the final changes, I'm afraid. I'm getting
close... should be tomorrow my time.


On Sun, Sep 8, 2019 at 7:32 AM Greg Dove  wrote:

>
> Yeah thanks Josh, Alex made a suggestion for that option too, it was the
> one I thought I would try first. I hope to get there later today, so I will
> see if I can figure that out.
>
>
> On Sun, Sep 8, 2019 at 7:20 AM Josh Tynjala 
> wrote:
>
>> I think the DITA files generated by asdoc are pretty big too, so they're
>> probably really useful for your testing.
>>
>> - Josh
>>
>> On Friday, September 6, 2019, Greg Dove  wrote:
>> > 'I think that SWFDump will generate valid XML and there is a way to get
>> > DITA files from Flex ASDoc that are valid XML.'
>> > Sounds like a good idea for some large xml files. I did not use that
>> yet,
>> > so will take a look and see if I can figure it out. Thanks!
>> >
>> >
>> > On Sat, Sep 7, 2019 at 12:30 PM Greg Dove  wrote:
>> >
>> >>
>> >> Just to clarify I was referring to this stuff here:
>> >>
>> >>
>> >>
>>
>> https://github.com/apache/royale-asjs/blob/8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab/frameworks/projects/MXRoyale/src/main/royale/mx/rpc/http/AbstractOperation.as#L1038
>> >>
>> >>
>> >> with '//old XML style'
>> >>
>> >>
>> >>
>> >>
>> >> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui 
>> >> wrote:
>> >>
>> >>> I haven't looked at what XML is used/supported by MX HTTPService.  It
>> >>> looks like WebService does use MX HTTPService.  I am currently
>> migrating
>> >>> other things that WebService needs (XMLEncoder/Decoder,
>> >>> SOAPEncoder/Decoder).  These are new files that aren't in the repo
>> yet,
>> so
>> >>> HTTPService couldn't be relying on them or else their use is commented
>> >>> out.   The goal is to change as little as possible to get it to
>> compile
>> and
>> >>> then see if it runs.  I have no idea yet if the XML improvements you
>> are
>> >>> working on are going to be impactful on what I'm doing or not.
>> >>>
>> >>> BTW, I could be wrong, but I think that SWFDump will generate valid
>> XML
>> >>> and there is a way to get DITA files from Flex ASDoc that are valid
>> XML.
>> >>>
>> >>> Thanks for the heads up,
>> >>> -Alex
>> >>>
>> >>> On 9/6/19, 5:14 PM, "Greg Dove"  wrote:
>> >>>
>> >>> Actually I know you are looking into the WSDL stuff maybe this
>> is
>> >>> going
>> >>> to be important for that (not sure)?
>> >>> My goal is to get the XML stuff tidied up and ready to push by end
>> of
>> >>> day
>> >>> tomorrow, worst case the following morning, local time (UTC+12). I
>> >>> also
>> >>> need to find some big XML test cases to check the memory side of
>> >>> things.
>> >>> FYI there is also some XMLDocument stuff missing (commented out)
>> from
>> >>> some
>> >>> of the MX HttpService code, which came up in a recent issue. I
>> don't
>> >>> know
>> >>> if it shares any of the code from the WSDL stuff you are looking
>> at
>> or
>> >>> not...
>> >>> If it does then I don't want to double up on things, but
>> otherwise I
>> >>> will
>> >>> try to look at that on my Monday.
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove 
>> >>> wrote:
>> >>>
>> >>> > Thanks for checking that.
>> >>> >
>> >>> > child is specified in 13.4.4.6 and essentially calls [[Get]]
>> >>> > (After cycling through this kind of thing a few times, I found
>> the
>> >>> easiest
>> >>> > way to find methods is to search in the spec for 'e.mehodName'
>> >>> which gets
>> >>> > you XML.prototype.methodName)
>> >>> >
>> >>> > and [[Get]] is specified in 9.1.1.1
>> >>> >
>> >>> > So I assume it is a bug. As discussed I think it is good to
>> match
>

Re: Heads up on XML

2019-09-07 Thread Greg Dove
Yeah thanks Josh, Alex made a suggestion for that option too, it was the
one I thought I would try first. I hope to get there later today, so I will
see if I can figure that out.


On Sun, Sep 8, 2019 at 7:20 AM Josh Tynjala 
wrote:

> I think the DITA files generated by asdoc are pretty big too, so they're
> probably really useful for your testing.
>
> - Josh
>
> On Friday, September 6, 2019, Greg Dove  wrote:
> > 'I think that SWFDump will generate valid XML and there is a way to get
> > DITA files from Flex ASDoc that are valid XML.'
> > Sounds like a good idea for some large xml files. I did not use that yet,
> > so will take a look and see if I can figure it out. Thanks!
> >
> >
> > On Sat, Sep 7, 2019 at 12:30 PM Greg Dove  wrote:
> >
> >>
> >> Just to clarify I was referring to this stuff here:
> >>
> >>
> >>
>
> https://github.com/apache/royale-asjs/blob/8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab/frameworks/projects/MXRoyale/src/main/royale/mx/rpc/http/AbstractOperation.as#L1038
> >>
> >>
> >> with '//old XML style'
> >>
> >>
> >>
> >>
> >> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui 
> >> wrote:
> >>
> >>> I haven't looked at what XML is used/supported by MX HTTPService.  It
> >>> looks like WebService does use MX HTTPService.  I am currently
> migrating
> >>> other things that WebService needs (XMLEncoder/Decoder,
> >>> SOAPEncoder/Decoder).  These are new files that aren't in the repo yet,
> so
> >>> HTTPService couldn't be relying on them or else their use is commented
> >>> out.   The goal is to change as little as possible to get it to compile
> and
> >>> then see if it runs.  I have no idea yet if the XML improvements you
> are
> >>> working on are going to be impactful on what I'm doing or not.
> >>>
> >>> BTW, I could be wrong, but I think that SWFDump will generate valid XML
> >>> and there is a way to get DITA files from Flex ASDoc that are valid
> XML.
> >>>
> >>> Thanks for the heads up,
> >>> -Alex
> >>>
> >>> On 9/6/19, 5:14 PM, "Greg Dove"  wrote:
> >>>
> >>> Actually I know you are looking into the WSDL stuff maybe this
> is
> >>> going
> >>> to be important for that (not sure)?
> >>> My goal is to get the XML stuff tidied up and ready to push by end
> of
> >>> day
> >>> tomorrow, worst case the following morning, local time (UTC+12). I
> >>> also
> >>> need to find some big XML test cases to check the memory side of
> >>> things.
> >>> FYI there is also some XMLDocument stuff missing (commented out)
> from
> >>> some
> >>> of the MX HttpService code, which came up in a recent issue. I
> don't
> >>> know
> >>> if it shares any of the code from the WSDL stuff you are looking at
> or
> >>> not...
> >>> If it does then I don't want to double up on things, but otherwise
> I
> >>> will
> >>> try to look at that on my Monday.
> >>>
> >>>
> >>>
> >>> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove 
> >>> wrote:
> >>>
> >>> > Thanks for checking that.
> >>> >
> >>> > child is specified in 13.4.4.6 and essentially calls [[Get]]
> >>> > (After cycling through this kind of thing a few times, I found
> the
> >>> easiest
> >>> > way to find methods is to search in the spec for 'e.mehodName'
> >>> which gets
> >>> > you XML.prototype.methodName)
> >>> >
> >>> > and [[Get]] is specified in 9.1.1.1
> >>> >
> >>> > So I assume it is a bug. As discussed I think it is good to match
> >>> the
> >>> > behavior. If we can verify 100% it is off spec, we could add
> >>> something as a
> >>> > define to avoid the 'fix' for people who want to be on-spec.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui
>  >>> >
> >>> > wrote:
> >>> >
> >>> >> FWIW, I went and looked at the ABC.
> >>> >>
> &

Re: Heads up on XML

2019-09-06 Thread Greg Dove
'I think that SWFDump will generate valid XML and there is a way to get
DITA files from Flex ASDoc that are valid XML.'
Sounds like a good idea for some large xml files. I did not use that yet,
so will take a look and see if I can figure it out. Thanks!


On Sat, Sep 7, 2019 at 12:30 PM Greg Dove  wrote:

>
> Just to clarify I was referring to this stuff here:
>
>
> https://github.com/apache/royale-asjs/blob/8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab/frameworks/projects/MXRoyale/src/main/royale/mx/rpc/http/AbstractOperation.as#L1038
>
>
> with '//old XML style'
>
>
>
>
> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui 
> wrote:
>
>> I haven't looked at what XML is used/supported by MX HTTPService.  It
>> looks like WebService does use MX HTTPService.  I am currently migrating
>> other things that WebService needs (XMLEncoder/Decoder,
>> SOAPEncoder/Decoder).  These are new files that aren't in the repo yet, so
>> HTTPService couldn't be relying on them or else their use is commented
>> out.   The goal is to change as little as possible to get it to compile and
>> then see if it runs.  I have no idea yet if the XML improvements you are
>> working on are going to be impactful on what I'm doing or not.
>>
>> BTW, I could be wrong, but I think that SWFDump will generate valid XML
>> and there is a way to get DITA files from Flex ASDoc that are valid XML.
>>
>> Thanks for the heads up,
>> -Alex
>>
>> On 9/6/19, 5:14 PM, "Greg Dove"  wrote:
>>
>> Actually I know you are looking into the WSDL stuff maybe this is
>> going
>> to be important for that (not sure)?
>> My goal is to get the XML stuff tidied up and ready to push by end of
>> day
>> tomorrow, worst case the following morning, local time (UTC+12). I
>> also
>> need to find some big XML test cases to check the memory side of
>> things.
>> FYI there is also some XMLDocument stuff missing (commented out) from
>> some
>> of the MX HttpService code, which came up in a recent issue. I don't
>> know
>> if it shares any of the code from the WSDL stuff you are looking at or
>> not...
>> If it does then I don't want to double up on things, but otherwise I
>> will
>> try to look at that on my Monday.
>>
>>
>>
>> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove 
>> wrote:
>>
>> > Thanks for checking that.
>> >
>> > child is specified in 13.4.4.6 and essentially calls [[Get]]
>> > (After cycling through this kind of thing a few times, I found the
>> easiest
>> > way to find methods is to search in the spec for 'e.mehodName'
>> which gets
>> > you XML.prototype.methodName)
>> >
>> > and [[Get]] is specified in 9.1.1.1
>> >
>> > So I assume it is a bug. As discussed I think it is good to match
>> the
>> > behavior. If we can verify 100% it is off spec, we could add
>> something as a
>> > define to avoid the 'fix' for people who want to be on-spec.
>> >
>> >
>> >
>> >
>> >
>> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui > >
>> > wrote:
>> >
>> >> FWIW, I went and looked at the ABC.
>> >>
>> >> The first syntax sets up a getProperty just like any other property
>> >> fetch.  The second (as expected) calls "child()".  I've looked at
>> the E4X
>> >> spec a couple of times now and cannot see where the behavior we
>> are seeing
>> >> in child() is specified so I am going to assume it is a bug, and
>> that we
>> >> just have to live with it.
>> >>
>> >> I expect that getProperty does not call child().  I haven't looked
>> at the
>> >> AVM code to see what getProperty does for XML.
>> >>
>> >> HTH,
>> >> -Alex
>> >>
>> >> On 9/5/19, 12:05 PM, "Greg Dove"  wrote:
>> >>
>> >> Oh that is a good find! And perfect timing :)
>> >> Thanks Alex, I am pretty sure that answers the question! (It
>> quite
>> >> specifically describes what I was seeing, I don't think it
>> makes a
>> >> difference whether it is attributes or elements)
>> >>
>> >> And yes, I agree it should be the implemented to give the same
>> >> results 

Re: Heads up on XML

2019-09-06 Thread Greg Dove
Just to clarify I was referring to this stuff here:

https://github.com/apache/royale-asjs/blob/8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab/frameworks/projects/MXRoyale/src/main/royale/mx/rpc/http/AbstractOperation.as#L1038


with '//old XML style'




On Sat, Sep 7, 2019 at 12:24 PM Alex Harui  wrote:

> I haven't looked at what XML is used/supported by MX HTTPService.  It
> looks like WebService does use MX HTTPService.  I am currently migrating
> other things that WebService needs (XMLEncoder/Decoder,
> SOAPEncoder/Decoder).  These are new files that aren't in the repo yet, so
> HTTPService couldn't be relying on them or else their use is commented
> out.   The goal is to change as little as possible to get it to compile and
> then see if it runs.  I have no idea yet if the XML improvements you are
> working on are going to be impactful on what I'm doing or not.
>
> BTW, I could be wrong, but I think that SWFDump will generate valid XML
> and there is a way to get DITA files from Flex ASDoc that are valid XML.
>
> Thanks for the heads up,
> -Alex
>
> On 9/6/19, 5:14 PM, "Greg Dove"  wrote:
>
> Actually I know you are looking into the WSDL stuff maybe this is
> going
> to be important for that (not sure)?
> My goal is to get the XML stuff tidied up and ready to push by end of
> day
> tomorrow, worst case the following morning, local time (UTC+12). I also
> need to find some big XML test cases to check the memory side of
> things.
> FYI there is also some XMLDocument stuff missing (commented out) from
> some
> of the MX HttpService code, which came up in a recent issue. I don't
> know
> if it shares any of the code from the WSDL stuff you are looking at or
> not...
> If it does then I don't want to double up on things, but otherwise I
> will
> try to look at that on my Monday.
>
>
>
> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove  wrote:
>
> > Thanks for checking that.
> >
> > child is specified in 13.4.4.6 and essentially calls [[Get]]
> > (After cycling through this kind of thing a few times, I found the
> easiest
> > way to find methods is to search in the spec for 'e.mehodName' which
> gets
> > you XML.prototype.methodName)
> >
> > and [[Get]] is specified in 9.1.1.1
> >
> > So I assume it is a bug. As discussed I think it is good to match the
> > behavior. If we can verify 100% it is off spec, we could add
> something as a
> > define to avoid the 'fix' for people who want to be on-spec.
> >
> >
> >
> >
> >
> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui  >
> > wrote:
> >
> >> FWIW, I went and looked at the ABC.
> >>
> >> The first syntax sets up a getProperty just like any other property
> >> fetch.  The second (as expected) calls "child()".  I've looked at
> the E4X
> >> spec a couple of times now and cannot see where the behavior we are
> seeing
> >> in child() is specified so I am going to assume it is a bug, and
> that we
> >> just have to live with it.
> >>
> >> I expect that getProperty does not call child().  I haven't looked
> at the
> >> AVM code to see what getProperty does for XML.
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 9/5/19, 12:05 PM, "Greg Dove"  wrote:
> >>
> >> Oh that is a good find! And perfect timing :)
> >> Thanks Alex, I am pretty sure that answers the question! (It
> quite
> >> specifically describes what I was seeing, I don't think it
> makes a
> >> difference whether it is attributes or elements)
> >>
> >> And yes, I agree it should be the implemented to give the same
> >> results as
> >> swf.
> >> I will add this to the other work I have over the weekend
> before I
> >> get it
> >> in. It only seems relevant for when child (or descendants, I
> don't
> >> expect
> >> that will be different) method call is explicit (as opposed to
> the
> >> compiler-generated method calls from e4x 'member access') with
> QName
> >> argument only. I think most people won't use this approach with
> >> explicit
> >> QNames, but it is one of those things that will cause misery if
> you do
> >> (when porting legacy code), so it should be the same IMO also.
> I will
>

Re: Heads up on XML

2019-09-06 Thread Greg Dove
Actually I know you are looking into the WSDL stuff maybe this is going
to be important for that (not sure)?
My goal is to get the XML stuff tidied up and ready to push by end of day
tomorrow, worst case the following morning, local time (UTC+12). I also
need to find some big XML test cases to check the memory side of things.
FYI there is also some XMLDocument stuff missing (commented out) from some
of the MX HttpService code, which came up in a recent issue. I don't know
if it shares any of the code from the WSDL stuff you are looking at or
not...
If it does then I don't want to double up on things, but otherwise I will
try to look at that on my Monday.



On Sat, Sep 7, 2019 at 12:02 PM Greg Dove  wrote:

> Thanks for checking that.
>
> child is specified in 13.4.4.6 and essentially calls [[Get]]
> (After cycling through this kind of thing a few times, I found the easiest
> way to find methods is to search in the spec for 'e.mehodName' which gets
> you XML.prototype.methodName)
>
> and [[Get]] is specified in 9.1.1.1
>
> So I assume it is a bug. As discussed I think it is good to match the
> behavior. If we can verify 100% it is off spec, we could add something as a
> define to avoid the 'fix' for people who want to be on-spec.
>
>
>
>
>
> On Sat, Sep 7, 2019 at 11:30 AM Alex Harui 
> wrote:
>
>> FWIW, I went and looked at the ABC.
>>
>> The first syntax sets up a getProperty just like any other property
>> fetch.  The second (as expected) calls "child()".  I've looked at the E4X
>> spec a couple of times now and cannot see where the behavior we are seeing
>> in child() is specified so I am going to assume it is a bug, and that we
>> just have to live with it.
>>
>> I expect that getProperty does not call child().  I haven't looked at the
>> AVM code to see what getProperty does for XML.
>>
>> HTH,
>> -Alex
>>
>> On 9/5/19, 12:05 PM, "Greg Dove"  wrote:
>>
>> Oh that is a good find! And perfect timing :)
>> Thanks Alex, I am pretty sure that answers the question! (It quite
>> specifically describes what I was seeing, I don't think it makes a
>> difference whether it is attributes or elements)
>>
>> And yes, I agree it should be the implemented to give the same
>> results as
>> swf.
>> I will add this to the other work I have over the weekend before I
>> get it
>> in. It only seems relevant for when child (or descendants, I don't
>> expect
>> that will be different) method call is explicit (as opposed to the
>> compiler-generated method calls from e4x 'member access') with QName
>> argument only. I think most people won't use this approach with
>> explicit
>> QNames, but it is one of those things that will cause misery if you do
>> (when porting legacy code), so it should be the same IMO also. I will
>> make
>> sure it costs nothing for the more common (other) use cases. I have
>> had to
>> do something similar to support 'use namespace' directives which
>> create a
>> MultiName-like variant of QName in my local change that includes the
>> default namespace and the specified set of other 'used'/open
>> namespace uris
>> in the current execution scope. (That 'use namespace' pattern was
>> being
>> used quite a bit in the codebase I have been working on)
>>
>> Thanks again, that will save me investigating it with bytecode.
>>
>>
>>
>>
>> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui 
>> wrote:
>>
>> > Out of pure random chance, I was starting the migration of
>> WebService
>> > which had a dependency on XMLUtil which contained the comment:
>> >
>> > //xml.attribute(QName) will also return local no-namespace
>> > attributes
>> > //even if we are looking for a specific full qualified name.
>> >
>> > So, still could be a bug in Flash, but maybe we should just make our
>> > implementation work the same way to reduce migration effort in case
>> someone
>> > is relying on this behavior.
>> >
>> > Thoughts?
>> > -Alex
>> >
>> > On 9/4/19, 1:47 PM, "Alex Harui"  wrote:
>> >
>> > I read the example incorrectly.  So yeah, it should return 0
>> and empty
>> > string in both cases, IMO.  There might be some subtlety in how the
>> > namespaces are specified for a QName or how QName works in child().
>> >
>> > H

Re: Heads up on XML

2019-09-06 Thread Greg Dove
Thanks for checking that.

child is specified in 13.4.4.6 and essentially calls [[Get]]
(After cycling through this kind of thing a few times, I found the easiest
way to find methods is to search in the spec for 'e.mehodName' which gets
you XML.prototype.methodName)

and [[Get]] is specified in 9.1.1.1

So I assume it is a bug. As discussed I think it is good to match the
behavior. If we can verify 100% it is off spec, we could add something as a
define to avoid the 'fix' for people who want to be on-spec.





On Sat, Sep 7, 2019 at 11:30 AM Alex Harui  wrote:

> FWIW, I went and looked at the ABC.
>
> The first syntax sets up a getProperty just like any other property
> fetch.  The second (as expected) calls "child()".  I've looked at the E4X
> spec a couple of times now and cannot see where the behavior we are seeing
> in child() is specified so I am going to assume it is a bug, and that we
> just have to live with it.
>
> I expect that getProperty does not call child().  I haven't looked at the
> AVM code to see what getProperty does for XML.
>
> HTH,
> -Alex
>
> On 9/5/19, 12:05 PM, "Greg Dove"  wrote:
>
> Oh that is a good find! And perfect timing :)
> Thanks Alex, I am pretty sure that answers the question! (It quite
> specifically describes what I was seeing, I don't think it makes a
> difference whether it is attributes or elements)
>
> And yes, I agree it should be the implemented to give the same results
> as
> swf.
> I will add this to the other work I have over the weekend before I get
> it
> in. It only seems relevant for when child (or descendants, I don't
> expect
> that will be different) method call is explicit (as opposed to the
> compiler-generated method calls from e4x 'member access') with QName
> argument only. I think most people won't use this approach with
> explicit
> QNames, but it is one of those things that will cause misery if you do
> (when porting legacy code), so it should be the same IMO also. I will
> make
> sure it costs nothing for the more common (other) use cases. I have
> had to
> do something similar to support 'use namespace' directives which
> create a
> MultiName-like variant of QName in my local change that includes the
> default namespace and the specified set of other 'used'/open namespace
> uris
> in the current execution scope. (That 'use namespace' pattern was being
> used quite a bit in the codebase I have been working on)
>
> Thanks again, that will save me investigating it with bytecode.
>
>
>
>
> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui 
> wrote:
>
> > Out of pure random chance, I was starting the migration of WebService
> > which had a dependency on XMLUtil which contained the comment:
> >
> > //xml.attribute(QName) will also return local no-namespace
> > attributes
> > //even if we are looking for a specific full qualified name.
> >
> > So, still could be a bug in Flash, but maybe we should just make our
> > implementation work the same way to reduce migration effort in case
> someone
> > is relying on this behavior.
> >
> > Thoughts?
> > -Alex
> >
> > On 9/4/19, 1:47 PM, "Alex Harui"  wrote:
> >
> > I read the example incorrectly.  So yeah, it should return 0 and
> empty
> > string in both cases, IMO.  There might be some subtlety in how the
> > namespaces are specified for a QName or how QName works in child().
> >
> > HTH,
> > -Alex
> >
> > On 9/4/19, 11:33 AM, "Greg Dove"  wrote:
> >
> > Good idea. I'll check the swf output, although probably
> tomorrow
> > as I need
> > to focus on something else today.
> > ' I would have expected both to return "1" and the node.  '
> >
> > In that example I would expect the opposite (because the the
> link
> > node
> > being returned by the second query is not in the specified
> explicit
> > namespace of the QName), so I am curious to understand why
> you
> > think
> > that... maybe it will help me understand.
> >
> > When I use feed.atom::link I expect only links that are
> bound to
> > the atom
> > namespace (uri). Because  node has no prefix
> bound to
> > the uri
> > that the atom namespace defines, and it is in the default
> > namespace, I
> &

Re: ${body} in index template

2019-09-06 Thread Greg Dove
Hi Carlos,

Based on the variation that happens, I'm not sure ${application} is useful
in its current form, although at first glance it appeared to be when I used
it.

Probably we just need
${applicationclass}

The code that handles this is here:
https://github.com/apache/royale-compiler/blob/a9fcf4f1f1b71508c7f9bf984975a27fbb13b8d5/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/mxml/royale/MXMLRoyalePublisher.java#L832

And based on what it seems to be doing I think the ${applicationclass}
token would just need to be substituted with the same value that is passed
as the argument to getTemplateBody call here:
https://github.com/apache/royale-compiler/blob/a9fcf4f1f1b71508c7f9bf984975a27fbb13b8d5/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/mxml/royale/MXMLRoyalePublisher.java#L879

so I'm guessing all it needs is:
if (type.equals("release")) {
result = input.replaceAll("\\$\\{applicationclass\\}",
projectName );
} else {
result = input.replaceAll("\\$\\{applicationclass\\}",
mainClassName );
}

But I did not check the variation between projectName and mainClassName
between release and debug for that, so I don't fully understand that part
yet. Maybe @aharui can confirm.




On Fri, Sep 6, 2019 at 7:36 PM Carlos Rovira 
wrote:

> Hi Greg,
>
> so the proposal is to end with:
>
> -body
> -application (used for standard Royale apps)
> -AppClassName (for Flex emulated apps that will have
> "_mx_managers_SystemManager" as part of the string. so this is really
> "{application}" + "_mx_managers_SystemManager")
>
> right?
>
> what do you think about
>
> -body
> -application
> -flexapplication
>
> ?
>
> (just trying to have the same style for names and simplifying to something
> more human readable)
>
> thanks!
>
>
> El vie., 6 sept. 2019 a las 5:16, Greg Dove ()
> escribió:
>
> > This seems like an easy thing to fix (unless I missed something).
> > So I think we just need to decide what the token should be.
> >
> > What does everyone think of:
> > ${AppClassName}
> >
> > Input welcome...
> >
> >
> >
> > On Fri, Sep 6, 2019 at 3:05 PM Greg Dove  wrote:
> >
> > > It looks like that only works for debug builds because it gets '.min'
> > > appended in the release build template.
> > > And it seems that MXRoyale Application builds append the system manager
> > > part as a variation.
> > > So we need a new token probably just for the main class name.
> > >
> > > For now it is possible to do:
> > > ${application}_mx_managers_SystemManager
> > > for debug builds of mx apps.
> > >
> > >
> > >
> > > On Fri, Sep 6, 2019 at 1:17 PM Greg Dove  wrote:
> > >
> > >>
> > >> Just to add to this thread:
> > >>
> > >> this type of thing also works if you need the name of the application
> > >> injected (which seems quite helpful for injecting into customised
> > >> javascript):
> > >>
> > >> 
> > >> // the name of my app is:${application}
> > >> 
> > >>
> > >>
> > >> On Wed, Aug 28, 2019 at 8:02 PM Carlos Rovira <
> carlosrov...@apache.org>
> > >> wrote:
> > >>
> > >>> Hi Chris,
> > >>>
> > >>> ua-parser-js seems very complete. I'll have into account for my own
> > >>> projects :).
> > >>> Thanks for sharing.
> > >>>
> > >>> El mié., 28 ago. 2019 a las 5:59, Chris Velevitch (<
> > >>> chris.velevi...@gmail.com>) escribió:
> > >>>
> > >>> > On Tue, 27 Aug 2019 at 16:34, Carlos Rovira <
> carlosrov...@apache.org
> > >
> > >>> > wrote:
> > >>> >
> > >>> > > maybe the actual way compiler deal with this is a bit restricted,
> > >>> and we
> > >>> > > can update that part including the 

Re: ${body} in index template

2019-09-05 Thread Greg Dove
This seems like an easy thing to fix (unless I missed something).
So I think we just need to decide what the token should be.

What does everyone think of:
${AppClassName}

Input welcome...



On Fri, Sep 6, 2019 at 3:05 PM Greg Dove  wrote:

> It looks like that only works for debug builds because it gets '.min'
> appended in the release build template.
> And it seems that MXRoyale Application builds append the system manager
> part as a variation.
> So we need a new token probably just for the main class name.
>
> For now it is possible to do:
> ${application}_mx_managers_SystemManager
> for debug builds of mx apps.
>
>
>
> On Fri, Sep 6, 2019 at 1:17 PM Greg Dove  wrote:
>
>>
>> Just to add to this thread:
>>
>> this type of thing also works if you need the name of the application
>> injected (which seems quite helpful for injecting into customised
>> javascript):
>>
>> 
>> // the name of my app is:${application}
>> 
>>
>>
>> On Wed, Aug 28, 2019 at 8:02 PM Carlos Rovira 
>> wrote:
>>
>>> Hi Chris,
>>>
>>> ua-parser-js seems very complete. I'll have into account for my own
>>> projects :).
>>> Thanks for sharing.
>>>
>>> El mié., 28 ago. 2019 a las 5:59, Chris Velevitch (<
>>> chris.velevi...@gmail.com>) escribió:
>>>
>>> > On Tue, 27 Aug 2019 at 16:34, Carlos Rovira 
>>> > wrote:
>>> >
>>> > > maybe the actual way compiler deal with this is a bit restricted,
>>> and we
>>> > > can update that part including the 

Re: ${body} in index template

2019-09-05 Thread Greg Dove
It looks like that only works for debug builds because it gets '.min'
appended in the release build template.
And it seems that MXRoyale Application builds append the system manager
part as a variation.
So we need a new token probably just for the main class name.

For now it is possible to do:
${application}_mx_managers_SystemManager
for debug builds of mx apps.



On Fri, Sep 6, 2019 at 1:17 PM Greg Dove  wrote:

>
> Just to add to this thread:
>
> this type of thing also works if you need the name of the application
> injected (which seems quite helpful for injecting into customised
> javascript):
>
> 
> // the name of my app is:${application}
> 
>
>
> On Wed, Aug 28, 2019 at 8:02 PM Carlos Rovira 
> wrote:
>
>> Hi Chris,
>>
>> ua-parser-js seems very complete. I'll have into account for my own
>> projects :).
>> Thanks for sharing.
>>
>> El mié., 28 ago. 2019 a las 5:59, Chris Velevitch (<
>> chris.velevi...@gmail.com>) escribió:
>>
>> > On Tue, 27 Aug 2019 at 16:34, Carlos Rovira 
>> > wrote:
>> >
>> > > maybe the actual way compiler deal with this is a bit restricted, and
>> we
>> > > can update that part including the 

Re: ${body} in index template

2019-09-05 Thread Greg Dove
Just to add to this thread:

this type of thing also works if you need the name of the application
injected (which seems quite helpful for injecting into customised
javascript):


// the name of my app is:${application}



On Wed, Aug 28, 2019 at 8:02 PM Carlos Rovira 
wrote:

> Hi Chris,
>
> ua-parser-js seems very complete. I'll have into account for my own
> projects :).
> Thanks for sharing.
>
> El mié., 28 ago. 2019 a las 5:59, Chris Velevitch (<
> chris.velevi...@gmail.com>) escribió:
>
> > On Tue, 27 Aug 2019 at 16:34, Carlos Rovira 
> > wrote:
> >
> > > maybe the actual way compiler deal with this is a bit restricted, and
> we
> > > can update that part including the 

Re: Heads up on XML

2019-09-05 Thread Greg Dove
Oh that is a good find! And perfect timing :)
Thanks Alex, I am pretty sure that answers the question! (It quite
specifically describes what I was seeing, I don't think it makes a
difference whether it is attributes or elements)

And yes, I agree it should be the implemented to give the same results as
swf.
I will add this to the other work I have over the weekend before I get it
in. It only seems relevant for when child (or descendants, I don't expect
that will be different) method call is explicit (as opposed to the
compiler-generated method calls from e4x 'member access') with QName
argument only. I think most people won't use this approach with explicit
QNames, but it is one of those things that will cause misery if you do
(when porting legacy code), so it should be the same IMO also. I will make
sure it costs nothing for the more common (other) use cases. I have had to
do something similar to support 'use namespace' directives which create a
MultiName-like variant of QName in my local change that includes the
default namespace and the specified set of other 'used'/open namespace uris
in the current execution scope. (That 'use namespace' pattern was being
used quite a bit in the codebase I have been working on)

Thanks again, that will save me investigating it with bytecode.




On Fri, Sep 6, 2019 at 6:37 AM Alex Harui  wrote:

> Out of pure random chance, I was starting the migration of WebService
> which had a dependency on XMLUtil which contained the comment:
>
> //xml.attribute(QName) will also return local no-namespace
> attributes
> //even if we are looking for a specific full qualified name.
>
> So, still could be a bug in Flash, but maybe we should just make our
> implementation work the same way to reduce migration effort in case someone
> is relying on this behavior.
>
> Thoughts?
> -Alex
>
> On 9/4/19, 1:47 PM, "Alex Harui"  wrote:
>
> I read the example incorrectly.  So yeah, it should return 0 and empty
> string in both cases, IMO.  There might be some subtlety in how the
> namespaces are specified for a QName or how QName works in child().
>
> HTH,
> -Alex
>
> On 9/4/19, 11:33 AM, "Greg Dove"  wrote:
>
> Good idea. I'll check the swf output, although probably tomorrow
> as I need
> to focus on something else today.
> ' I would have expected both to return "1" and the node.  '
>
> In that example I would expect the opposite (because the the link
> node
> being returned by the second query is not in the specified explicit
> namespace of the QName), so I am curious to understand why you
> think
> that... maybe it will help me understand.
>
> When I use feed.atom::link I expect only links that are bound to
> the atom
> namespace (uri). Because  node has no prefix bound to
> the uri
> that the atom namespace defines, and it is in the default
> namespace, I
> would not expect it to be included.
> At the moment the atom::link part is working the same as swf, so
> I'm happy
> with that at least for what I am working on. All the explicit
> calls to
> child(name) or descendants(name) in the app I am working on use
> string args
> so these all work correctly as well.
> I'm just trying to cover things for the future... while my head is
> still in
> this stuff.
>
>
>
> On Thu, Sep 5, 2019 at 6:11 AM Alex Harui 
> wrote:
>
> > Speaking of multinames, what is the ABC code generated by the
> Flex
> > compiler for the two cases?  It might contain some clues.  I
> would have
> > expected both to return "1" and the node.  But I did see in the
> spec the
>     > notion of "InScopeNamespaces".  I generally hate reading specs
> like these
> > so I am not very knowledgeable about what the spec says.
> >
> > HTH,
> > -Alex
> >
> > On 9/4/19, 11:05 AM, "Greg Dove"  wrote:
> >
> > 'Have you rummaged through the spec?'
> > Yes, if anything I probably need to step away from it and
> experience
> > the
> > world a bit more! I have been focused on each portion of the
> spec as I
> > create unit tests and verify things between the player and
> the Royale
> > implementation.
> > I've also glanced a few times in the avmplus code, and that
> has
> > provided
> > some clues where things were intentionally implemented
> slightly off
> 

Re: Heads up on XML

2019-09-04 Thread Greg Dove
Yeah, I saw that ;) Don't worry, I am aware of it.

My first goal is to make sure it works like it should, because that comes
first, and then to optimize. I'll check the memory side of things and make
sure it's at least the same as before. If you can point me to some
publicly accessible large test cases that would be really helpful. I will
work through that before I push anything.

On Thu, Sep 5, 2019 at 7:26 AM Harbs  wrote:

> Heads up:
>
> I did some (on first blush) odd things in XML related to QNames. QNames
> are pooled and many XML properties are not initialized by default. The
> reason I did this was it avoided many MB of memory waste for complex XML.
> Please don’t mess that up.
>
> Thanks,
> Harbs
>
> > On Sep 4, 2019, at 1:02 PM, Greg Dove  wrote:
> >
> > This is particularly for Harbs and Yishay, as I think you are both (or
> both
> > have been) using XML quite a bit. I have quite a few  fixes coming. All
> > with tests that match on swf and js.
> >
> > I am currently working to demonstrate proof of concept to a prospective
> > client for migration of a Flex app. The app makes extensive use of e4x
> and
> > uses a bunch of features that I expect had not received attention
> > previously, because they were originally either not working with the
> > codebase I am porting, or i think some even caused errors in the
> javascript
> > output.
> >
> > So I have spent the last several days almost full time figuring things
> out
> > and working on fixes, between the compiler and emulation classes.
> > All the previous XML tests continue to pass, but I have many more unit
> > tests and fixes lined up for the following:
> >
> > namespace directives
> > default xml namespace
> > use namespace (multiple)
> >
> > a number of fixes for xml filtering, including:
> > -'this' resolves correctly in filters that include external references
> from
> > the fitler expression to the 'this' scope
> > -handles alternate ordering of comparisons between XML 'getters' and
> > literals
> > e.g. something.(name() = "cat")  or something.("cat" = name()) (these are
> > the same)
> > -it (will) now handle XML e4x references in nested function calls inside
> > the filter, e.g. things like:
> > e.g.
> > var people:XML = 
> >
> >Bob
> >32
> >
> >
> >Joe
> >46
> >
> >;
> > var findJoeByAge:Function = function (i:int):Boolean {
> >return i > 40;
> >};
> > people.person.(findJoeByAge(parseInt(age))).name
> >
> >
> > I have lots more granular tests in QName, Namespace, and XML with tuning
> to
> > improve reliability.
> > toXMLString XML node output also matches flash more correctly in what I
> > have coming.
> >
> > One thing that I am trying to figure out, which I would appreciate input
> on
> > if someone has an answer:
> > For the example:
> >
> > var feed:XML = new XML(
> >'http://www.w3.org/2005/Atom;
> > xmlns:m="nothing">\n' +
> >'   > href="blah/12321/domain/"/>\n' +
> >'\n');
> > var atomSpace:Namespace = new Namespace('http://www.w3.org/2005/Atom');
> >
> > Can anyone explain why this (in SWF, as a reference implementation):
> > trace(feed.atomSpace::link.length())
> > trace(feed.atomSpace::link.toXMLString())
> > //output:
> > 0
> > {empty string}
> > is different to:
> > trace(feed.child(new QName(atomSpace,'link')).length())
> > trace(feed.child(new QName(atomSpace,'link')).toXMLString())
> > //output:
> > 1
> > http://www.w3.org/2005/Atom; xmlns:m="nothing"/>
> >
> > I had assumed the above cases would be the same, but the second one is
> > behaving as if it has the default namespace included with the specified
> > namespace in the QName matching (it does correctly match the namespace
> > specifically as well -with e.g.  > bound to the uri, but also seems to include link nodes with the default
> > namespace, whether or not it is declared). I can accommodate this
> > difference to make them behave the same, I just would like to understand
> > the basis for the actual rules if anyone knows
> >
> > I should be in a position to push the updates this coming weekend I
> think.
>
>


Re: Heads up on XML

2019-09-04 Thread Greg Dove
Good idea. I'll check the swf output, although probably tomorrow as I need
to focus on something else today.
' I would have expected both to return "1" and the node.  '

In that example I would expect the opposite (because the the link node
being returned by the second query is not in the specified explicit
namespace of the QName), so I am curious to understand why you think
that... maybe it will help me understand.

When I use feed.atom::link I expect only links that are bound to the atom
namespace (uri). Because  node has no prefix bound to the uri
that the atom namespace defines, and it is in the default namespace, I
would not expect it to be included.
At the moment the atom::link part is working the same as swf, so I'm happy
with that at least for what I am working on. All the explicit calls to
child(name) or descendants(name) in the app I am working on use string args
so these all work correctly as well.
I'm just trying to cover things for the future... while my head is still in
this stuff.



On Thu, Sep 5, 2019 at 6:11 AM Alex Harui  wrote:

> Speaking of multinames, what is the ABC code generated by the Flex
> compiler for the two cases?  It might contain some clues.  I would have
> expected both to return "1" and the node.  But I did see in the spec the
> notion of "InScopeNamespaces".  I generally hate reading specs like these
> so I am not very knowledgeable about what the spec says.
>
> HTH,
> -Alex
>
> On 9/4/19, 11:05 AM, "Greg Dove"  wrote:
>
> 'Have you rummaged through the spec?'
> Yes, if anything I probably need to step away from it and experience
> the
> world a bit more! I have been focused on each portion of the spec as I
> create unit tests and verify things between the player and the Royale
> implementation.
> I've also glanced a few times in the avmplus code, and that has
> provided
> some clues where things were intentionally implemented slightly off
> spec,
> but still a few things to figure out. However I am making progress - I
> think I have everything covered for the codebase I am working on
> but I
> will keep going beyond that. For that example above, I might be wrong,
> but
> I suspect it is using a multiname with default namespace included for
> the
> explicit call case in the player, but not for the implicit one, but I
> am
> not yet sure why. I will double-check the spec though...
>
>
> On Thu, Sep 5, 2019 at 4:02 AM Alex Harui 
> wrote:
>
> > Don't know.  Have you rummaged through the spec?
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdfdata=02%7C01%7Caharui%40adobe.com%7C8b56d09a6a314e2d55aa08d731628822%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637032171567244570sdata=8LW6weJevEYXpCx%2FEdegixnO%2BgVXDasn3gjKZFOrPFI%3Dreserved=0
> >
> > HTH,
> > -Alex
> >
> > On 9/4/19, 3:11 AM, "Greg Dove"  wrote:
> >
> > This is particularly for Harbs and Yishay, as I think you are
> both (or
> > both
> > have been) using XML quite a bit. I have quite a few  fixes
> coming. All
> > with tests that match on swf and js.
> >
> > I am currently working to demonstrate proof of concept to a
> prospective
> > client for migration of a Flex app. The app makes extensive use
> of e4x
> > and
> > uses a bunch of features that I expect had not received attention
> > previously, because they were originally either not working with
> the
> > codebase I am porting, or i think some even caused errors in the
> > javascript
> > output.
> >
> > So I have spent the last several days almost full time figuring
> things
> > out
> > and working on fixes, between the compiler and emulation classes.
> > All the previous XML tests continue to pass, but I have many
> more unit
> > tests and fixes lined up for the following:
> >
> > namespace directives
> > default xml namespace
> > use namespace (multiple)
> >
> > a number of fixes for xml filtering, including:
> > -'this' resolves correctly in filters that include external
> references
> > from
> > the fitler expression to the 'this' scope
> > -handles alternate ordering of comparisons between XML 'getters'
> and
> > literals
> > e.g. something.(name() = "cat")  or something.("cat" = name())
> 

Re: Heads up on XML

2019-09-04 Thread Greg Dove
'Have you rummaged through the spec?'
Yes, if anything I probably need to step away from it and experience the
world a bit more! I have been focused on each portion of the spec as I
create unit tests and verify things between the player and the Royale
implementation.
I've also glanced a few times in the avmplus code, and that has provided
some clues where things were intentionally implemented slightly off spec,
but still a few things to figure out. However I am making progress - I
think I have everything covered for the codebase I am working on but I
will keep going beyond that. For that example above, I might be wrong, but
I suspect it is using a multiname with default namespace included for the
explicit call case in the player, but not for the implicit one, but I am
not yet sure why. I will double-check the spec though...


On Thu, Sep 5, 2019 at 4:02 AM Alex Harui  wrote:

> Don't know.  Have you rummaged through the spec?
>
> https://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/Ecma-357.pdf
>
> HTH,
> -Alex
>
> On 9/4/19, 3:11 AM, "Greg Dove"  wrote:
>
> This is particularly for Harbs and Yishay, as I think you are both (or
> both
> have been) using XML quite a bit. I have quite a few  fixes coming. All
> with tests that match on swf and js.
>
> I am currently working to demonstrate proof of concept to a prospective
> client for migration of a Flex app. The app makes extensive use of e4x
> and
> uses a bunch of features that I expect had not received attention
> previously, because they were originally either not working with the
> codebase I am porting, or i think some even caused errors in the
> javascript
> output.
>
> So I have spent the last several days almost full time figuring things
> out
> and working on fixes, between the compiler and emulation classes.
> All the previous XML tests continue to pass, but I have many more unit
> tests and fixes lined up for the following:
>
> namespace directives
> default xml namespace
> use namespace (multiple)
>
> a number of fixes for xml filtering, including:
> -'this' resolves correctly in filters that include external references
> from
> the fitler expression to the 'this' scope
> -handles alternate ordering of comparisons between XML 'getters' and
> literals
> e.g. something.(name() = "cat")  or something.("cat" = name()) (these
> are
> the same)
> -it (will) now handle XML e4x references in nested function calls
> inside
> the filter, e.g. things like:
> e.g.
> var people:XML = 
> 
> Bob
> 32
> 
> 
> Joe
> 46
> 
> ;
>  var findJoeByAge:Function = function (i:int):Boolean {
> return i > 40;
> };
> people.person.(findJoeByAge(parseInt(age))).name
>
>
> I have lots more granular tests in QName, Namespace, and XML with
> tuning to
> improve reliability.
> toXMLString XML node output also matches flash more correctly in what I
> have coming.
>
> One thing that I am trying to figure out, which I would appreciate
> input on
> if someone has an answer:
> For the example:
>
> var feed:XML = new XML(
> 'https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtomdata=02%7C01%7Caharui%40adobe.com%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%3Dreserved=0
> "
> xmlns:m="nothing">\n' +
> '   href="blah/12321/domain/"/>\n' +
> '\n');
> var atomSpace:Namespace = new Namespace('
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtomdata=02%7C01%7Caharui%40adobe.com%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%3Dreserved=0'
> );
>
> Can anyone explain why this (in SWF, as a reference implementation):
> trace(feed.atomSpace::link.length())
> trace(feed.atomSpace::link.toXMLString())
> //output:
> 0
> {empty string}
> is different to:
> trace(feed.child(new QName(atomSpace,'link')).length())
> trace(feed.child(new QName(atomSpace,'link')).toXMLString())
> //output:
> 1
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2

Heads up on XML

2019-09-04 Thread Greg Dove
This is particularly for Harbs and Yishay, as I think you are both (or both
have been) using XML quite a bit. I have quite a few  fixes coming. All
with tests that match on swf and js.

I am currently working to demonstrate proof of concept to a prospective
client for migration of a Flex app. The app makes extensive use of e4x and
uses a bunch of features that I expect had not received attention
previously, because they were originally either not working with the
codebase I am porting, or i think some even caused errors in the javascript
output.

So I have spent the last several days almost full time figuring things out
and working on fixes, between the compiler and emulation classes.
All the previous XML tests continue to pass, but I have many more unit
tests and fixes lined up for the following:

namespace directives
default xml namespace
use namespace (multiple)

a number of fixes for xml filtering, including:
-'this' resolves correctly in filters that include external references from
the fitler expression to the 'this' scope
-handles alternate ordering of comparisons between XML 'getters' and
literals
e.g. something.(name() = "cat")  or something.("cat" = name()) (these are
the same)
-it (will) now handle XML e4x references in nested function calls inside
the filter, e.g. things like:
e.g.
var people:XML = 

Bob
32


Joe
46

;
 var findJoeByAge:Function = function (i:int):Boolean {
return i > 40;
};
people.person.(findJoeByAge(parseInt(age))).name


I have lots more granular tests in QName, Namespace, and XML with tuning to
improve reliability.
toXMLString XML node output also matches flash more correctly in what I
have coming.

One thing that I am trying to figure out, which I would appreciate input on
if someone has an answer:
For the example:

var feed:XML = new XML(
'http://www.w3.org/2005/Atom;
xmlns:m="nothing">\n' +
'  \n' +
'\n');
var atomSpace:Namespace = new Namespace('http://www.w3.org/2005/Atom');

Can anyone explain why this (in SWF, as a reference implementation):
trace(feed.atomSpace::link.length())
trace(feed.atomSpace::link.toXMLString())
//output:
0
{empty string}
is different to:
trace(feed.child(new QName(atomSpace,'link')).length())
trace(feed.child(new QName(atomSpace,'link')).toXMLString())
//output:
1
http://www.w3.org/2005/Atom; xmlns:m="nothing"/>

I had assumed the above cases would be the same, but the second one is
behaving as if it has the default namespace included with the specified
namespace in the QName matching (it does correctly match the namespace
specifically as well -with e.g. 

Re: Apache Royale Jewel Browser List supported

2019-09-03 Thread Greg Dove
Hi Piotr,

Royale might work for IE9 for some things, but I think (my opinion) it is
fair to say that it is probably only reliable with IE11 as the base 'IE'
browser. Some as3 language level features or core types may not reasonable
before that. I don't think IE9 had TypedArrays for example, which means
things like BinaryData won't work, and all the AMF remoting stuff etc, as
one example.

If someone is insisting on IE9 compatibility, then it might be possible to
get there by limiting what you use, or with some es5 polyfills. Polyfills
are standard practice for this type of thing when you need to do it with
React or whatever, but I don't think others are doing this yet with Royale
(I might be wrong).
For the older IE browsers, I assume the flash player will continue to work
if the browser is in a contained environment like some sort of intranet
(which it probably should be), and therefore should continue to run the
original flex app... so when I have spoken to clients about Royale IE
compatibility, IE11 seems to be a common base, with most people (or at
least one of them: me) waiting for it to fade away as soon as possible. But
that doesn't mean that it's easy to convince everybody.
Aside from that, the general problem with older browsers is that actively
supporting them prolongs the 'problem' of needing to support them. At the
moment I would not be inclined to say that Royale supported IE9, and
hesitant about IE10 - but again it depends what you use. Hello World might
work... but that's not really an app.


On Tue, Sep 3, 2019 at 7:35 PM Piotr Zarzycki 
wrote:

> Carlos,
>
> I thought that Royale can work even in IE9. Jewel not but Basic should. I
> recall this information I think when we were FlexJS.
>
> Thanks,
> Piotr
>
> wt., 3 wrz 2019 o 09:31 Carlos Rovira 
> napisał(a):
>
> > Hi Chris,
> >
> > others could say if I'm wrong or not but I think minimum version for IE
> is
> > 11.
> > But take into account that in the case of IE, users always can run normal
> > old flex version.
> >
> > thanks
> >
> > Carlos
> >
> > El mar., 3 sept. 2019 a las 6:13, Chris Velevitch (<
> > chris.velevi...@gmail.com>) escribió:
> >
> > > Does Royale need to use strict? I ask this because IE9 doesn't support
> > > ES5 use strict.
> > >
> > > On Thu, 29 Aug 2019 at 15:41, Carlos Rovira 
> > > wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > > I think nobody makes a test for this. But Royale uses ES5 at compiler
> > > > level, so all browsers that support that ES version should work [1]
> > > >
> > > > For Jewel the page is this [2]
> > > >
> > > > [1] https://www.w3schools.com/js/js_versions.asp
> > > > [2] https://apache.github.io/royale-docs/component-sets/jewel.html
> > > >
> > > >
> > > > El jue., 29 ago. 2019 a las 7:19, Chris Velevitch (<
> > > > chris.velevi...@gmail.com>) escribió:
> > > >
> > > > > Is there a list of supported browsers for non-Jewel based apps?
> > > > >
> > > > >
> > > > > On Mon, 24 Sep 2018 at 23:49, Carlos Rovira <
> carlosrov...@apache.org
> > >
> > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > today I was testing Jewel in Browserstack to see minimum versions
> > > > > required
> > > > > > to see Jewel Example without problems.
> > > > > > This is the list:
> > > > > >
> > > > > > Desktop
> > > > > > - *Chrome v44*  - (released *July,21, 2015*)
> > > > > > - *Firefox v34* - (released *Dec, 1, 2014*)
> > > > > > - *Microsoft Internet Explorer 11 y Edge 15*
> > > > > > - *Safari 11.1, Mac OS X High Sierra, *(released* Feb, 22 2018*)
> > > > > >
> > > > > > Mobile
> > > > > > - *iOS 11. 19 *(release* Sep 2017*)
> > > > > > - *Android 5*, (released, *2014*) , although I think Android
> > devices
> > > can
> > > > > be
> > > > > > very different between manufactures, so maybe is not as easy, I
> > tried
> > > > > with
> > > > > > Samsung Galaxy different models and versions)
> > > > > >
> > > > > > I'll put this info on the wiki
> > > > > >
> > > > > > --
> > > > > > Carlos Rovira
> > > > > > http://about.me/carlosrovira
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > >
> > > > > Chris
> > > > > --
> > > > > Chris Velevitch
> > > > > m: 0415 469 095
> > > > >
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > >
> > >
> > >
> > > --
> > >
> > >
> > > Chris
> > > --
> > > Chris Velevitch
> > > m: 0415 469 095
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>


Re: Build failed in Jenkins: royale-asjs #2650

2019-08-30 Thread Greg Dove
As far as I can see there are issues with the compiler build not being able
to delete some files. I don't think this was anything I did. Can someone
else please verify if you get a chance?



On Sat, Aug 31, 2019 at 12:10 PM Apache Royale CI Server <
apacheroyal...@gmail.com> wrote:

> See <
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/2650/display/redirect?page=changes
> >
>
> Changes:
>
> [greg.dove] Updates to tests to cover namespace variants in child and
> descendant
>
> --
> [...truncated 650.81 KB...]
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\Dictionary.java:71:
> warning: [rawtypes] found raw type: Entry
> [javac] Entry entry = (Entry) iterator.next();
> [javac] ^
> [javac]   missing type arguments for generic class Entry
> [javac]   where K,V are type-variables:
> [javac] K extends Object declared in interface Entry
> [javac] V extends Object declared in interface Entry
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\tags\DefineSprite.java:74:
> warning: [rawtypes] found raw type: Iterator
> [javac] for (Iterator i = tagList.tags.iterator();
> i.hasNext();)
> [javac]  ^
> [javac]   missing type arguments for generic class Iterator
> [javac]   where E is a type-variable:
> [javac] E extends Object declared in interface Iterator
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\Shape.java:30:
> warning: [overrides] Class Shape overrides equals, but neither it nor any
> superclass overrides hashCode method
> [javac] public class Shape
> [javac]^
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\ShapeWithStyle.java:66:
> warning: [rawtypes] found raw type: Iterator
> [javac] Iterator it = fillstyles.iterator();
> [javac] ^
> [javac]   missing type arguments for generic class Iterator
> [javac]   where E is a type-variable:
> [javac] E extends Object declared in interface Iterator
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\ShapeWithStyle.java:31:
> warning: [overrides] Class ShapeWithStyle overrides equals, but neither it
> nor any superclass overrides hashCode method
> [javac] public class ShapeWithStyle extends Shape
> [javac]^
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\Matrix.java:27:
> warning: [overrides] Class Matrix overrides equals, but neither it nor any
> superclass overrides hashCode method
> [javac] public class Matrix
> [javac]^
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\CXForm.java:27:
> warning: [overrides] Class CXForm overrides equals, but neither it nor any
> superclass overrides hashCode method
> [javac] public class CXForm
> [javac]^
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\ButtonRecord.java:42:
> warning: [rawtypes] found raw type: List
> [javac] public List filters;
> [javac]^
> [javac]   missing type arguments for generic class List
> [javac]   where E is a type-variable:
> [javac] E extends Object declared in interface List
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\ButtonRecord.java:77:
> warning: [rawtypes] found raw type: List
> [javac] private boolean compareFilters(List filterList1, List
> filterList2)
> [javac]^
> [javac]   missing type arguments for generic class List
> [javac]   where E is a type-variable:
> [javac] E extends Object declared in interface List
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\ButtonRecord.java:77:
> warning: [rawtypes] found raw type: List
> [javac] private boolean compareFilters(List filterList1, List
> filterList2)
> [javac]  ^
> [javac]   missing type arguments for generic class List
> [javac]   where E is a type-variable:
> [javac] E extends Object declared in interface List
> [javac] C:\Program Files
> (x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\ButtonRecord.java:29:
> warning: [overrides] Class ButtonRecord overrides equals, but neither it
> nor any superclass overrides hashCode method
> [javac] public class ButtonRecord
> [javac]^
> [javac] C:\Program 

Re: Build failed in Jenkins: royale-asjs_jsonly #3409

2019-08-18 Thread Greg Dove
I have lost track of the original references for this.
I just have a 'note to myself' to always install version 47.0.1
I did this a couple of weeks back for something that I needed to check in
royale.
I usually let Firefox update to the latest version so I can use it for
normal testing of any work, but there are occasions when I have to revert
to the older version for royale.




On Mon, Aug 19, 2019 at 5:28 AM Piotr Zarzycki 
wrote:

> What version of Firefox on our machine we need to get it working?
>
> On Sun, Aug 18, 2019, 4:58 PM Apache Royale CI Server <
> apacheroyal...@gmail.com> wrote:
>
> > See <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/3409/display/redirect?page=changes
> > >
> >
> > Changes:
> >
> > [yishayjobs] Fixes #444
> >
> > --
> > [...truncated 1.71 MB...]
> >  [java] public static var noScriptComplete:Boolean = false;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1546)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var exitWhenDone:Boolean = false;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1551)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var playbackControl:String = "play";
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1557)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var bitmapServerPrefix:String;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1562)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var serverCopy:String;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1586)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var currentTestID:String;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1591)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var currentScript:String;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1600)
> >:
> > col: 5 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var _root:Object;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1605)
> >:
> > col: 5 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var contextFunction:Function;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1610)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var includeList:Object;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1615)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var excludeList:Object;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1673)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public var scriptName:String;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> 

Re: Build failed in Jenkins: royale-asjs_jsonly #3398

2019-08-16 Thread Greg Dove
In my experience locally that can break the build for some tests. I have
had to uninstall firefox and reinstall version 47 many times on my own
machine.
There is a compatibility with (iirc) mustella testing that requires the
older firefox version. So I would guess that is what is happening on the
server.


On Fri, Aug 16, 2019 at 10:04 PM Piotr Zarzycki 
wrote:

> I've seen on the server that Firefox was updated for some reason. Could it
> influence the build ?
>
> pt., 16 sie 2019 o 08:39 Apache Royale CI Server  >
> napisał(a):
>
> > See <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/3398/display/redirect
> > >
> >
> > --
> > [...truncated 1.72 MB...]
> >  [java]
> >  [java] public var scriptName:String;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1678)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public var testSWF:String;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1683)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public var startEvent:String = "applicationComplete";
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1688)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public var testCases:Array;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1693)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public var lastEvent:Event;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1704)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public static var excludedCount:int = 0;
> >  [java] ^
> >  [java]
> >  [java] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/src/main/royale/UnitTester.as(1979)
> >:
> > col: 2 public var may not work in minified JS output.  Use getter/setter
> > instead.
> >  [java]
> >  [java] public var valueChanged:Boolean;
> >  [java] ^
> >  [java]
> >  [java] 4.3761391 seconds
> >  [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m
> > -Xmx1g
> >  [java] Java Result: 2
> >
> > main:
> >
> > basictests-compile-java:
> >[delete] Deleting directory <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/target/classes
> > >
> > [mkdir] Created dir: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/target/classes
> > >
> > [javac] <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/build.xml
> >:1347:
> > warning: 'includeantruntime' was not set, defaulting to
> > build.sysclasspath=last; set to false for repeatable builds
> > [javac] Compiling 12 source files to <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/target/classes
> > >
> >
> > basictests:
> >
> > basictests-mustella:
> >
> > basictests-compile-js:
> >  [echo] ROYALE_HOME: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/
> > >
> >  [echo] ROYALE_COMPILER_HOME: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/js
> > >
> >  [echo] GOOG_HOME: <
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/js/lib/google/closure-library
> > >
> > [mxmlc] MXMLJSC
> > [mxmlc] -sdk-js-lib=<
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/mustella/js
> > >
> > [mxmlc] -compiler.debug=true
> > [mxmlc] +royalelib=<
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/frameworks/
> > >
> > [mxmlc] -closure-lib=<
> >
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ws/js/lib/google/closure-library
> > >
> > [mxmlc] -compiler.targets=JSRoyale
> > [mxmlc] -compiler.library-path=<
> >
> 

inject_html in the framework via rawgit

2019-08-14 Thread Greg Dove
"RawGit is now in a sunset phase and will soon shut down" [1]

It just came to my attention today that some of the framework code uses
script tag injections for rawgit urls, and I checked that service... it
could be shut down as early as October 2019.
This looks to only be used in MXRoyale and AceEditor.

One of the uses seems to be for base64 encoding and decoding, which
(hopefully) can be replaced with native browser functions, I think [2]

For now, I am just highlighting this. I realize we are in release mode for
0.96, but we probably want to ensure another release before too long with
alternative script urls before that service drops out.

1. https://rawgit.com/
2. https://caniuse.com/#feat=atob-btoa


Re: Compiler Performance (was Re: Problem with Vectors)

2019-08-14 Thread Greg Dove
I should have drawn attention to this again before release work started...
I guess it is too late to get rid of that diagnostic output (described
below) from the compiler in the release?
It might be confusing output for some people, or create the wrong
impression, but perhaps it is too late in the process?

On Wed, Jul 3, 2019 at 8:42 PM Greg Dove  wrote:

>
> Just a quick followup to Harbs' earlier comment about the compiler noise.
> I'm seeing this a lot also.
>
> It looks like there is some leftover diagnostic logging in
> ControlFlowGraph.traverseGraph. Hopefully it can be removed or dialed down.
>
>
>
>
> On Mon, Jul 1, 2019 at 7:06 AM Yishay Weiss 
> wrote:
>
>> I was also getting it before.
>> 
>> From: Josh Tynjala 
>> Sent: Sunday, June 30, 2019 3:53:56 PM
>> To: dev@royale.apache.org
>> Subject: Re: Compiler Performance (was Re: Problem with Vectors)
>>
>> Is this GC limit error something new? Or were you getting it before too?
>>
>> - Josh
>>
>> On Sun, Jun 30, 2019, 1:35 AM Yishay Weiss 
>> wrote:
>>
>> > On my windows/powershell env there’s a significant improvement (~34
>> > seconds instead of ~42) when building our app with verbose switched off.
>> > I’m getting a ‘GC overhead limit exceeded’ [1] error though quite often
>> > which brings it up to around a minute and a half. Increasing heap size
>> by
>> > setting ANT_OPTS to -Xmx2g doesn’t seem to make a difference.
>> >
>> >
>> >
>> > [1] https://paste.apache.org/BXf4
>> >
>> >
>> >
>> > 
>> > From: Josh Tynjala 
>> > Sent: Friday, June 28, 2019 6:24:10 PM
>> > To: dev@royale.apache.org
>> > Subject: Re: Compiler Performance (was Re: Problem with Vectors)
>> >
>> > Windows and PowerShell.
>> >
>> > I have not been cleaning bin/js-debug before each build. So my reported
>> > times are more like what an app developer would experience most of the
>> > time. Writing files after remove circulars still has an impact in that
>> > situation. It's not huge, but still enough to be worth the effort, I
>> think.
>> >
>> > Another thing I've noticed is that the compiler will randomly decide to
>> do
>> > a release build every now and then, even though I've always asked for
>> debug
>> > builds. Maybe a threading issue or something while the configuration
>> one of
>> > being initialized?
>> >
>> > - Josh
>> >
>> > On Thu, Jun 27, 2019, 9:35 PM Alex Harui 
>> wrote:
>> >
>> > > Good progress!  Are these times based on Windows? PowerShell?  Mac?
>> I'm
>> > > just wondering if the Java code outputting strings is slow or the
>> console
>> > > saving the output or both.
>> > >
>> > > Are you only testing from a clean bin/js-debug?  I thought that the
>> > > compiler did not copy JS files that were already in bin/js-debug and
>> > > remove-circulars re-uses those JS files.
>> > >
>> > > In theory, those of us modifying framework code have to clean out
>> > > bin/js-debug more often than app developers.
>> > >
>> > > HTH,
>> > > -Alex
>> > >
>> > > On 6/27/19, 4:00 PM, "Josh Tynjala" 
>> wrote:
>> > >
>> > > I made a few smaller optimizations today. It seems to shave off
>> about
>> > > 0.4
>> > > to 0.5 seconds from the time to compile TourDeJewel on my
>> computer.
>> > > Not as
>> > > dramatic as the last one, but still a measurable difference!
>> > >
>> > > I'd like to find a way to make remove-circulars happen earlier in
>> the
>> > > process. It takes files that are already written to the file
>> system
>> > and
>> > > then modifies them. The extra re-write to disk is pretty
>> expensive.
>> > If
>> > > all
>> > > JS files were written to disk only once, we'd save another half
>> > second
>> > > or
>> > > more.
>> > >
>> > > --
>> > > Josh Tynjala
>> > > Bowler Hat LLC <
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C3763ea8f30394ff716bd08d6fb534693%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636972732457

Re: Builds

2019-08-09 Thread Greg Dove
Hi Josh,

Thanks for the details. I had figured out the general ant setup for these.
The new tests were fine in terms of compiling across JS and SWF (and worked
without issue in the regular asjs build), so it wasn't an issue at the
COMPILE::JS/COMPILE::SWF level.
It was only in the js-only build that I had a problem, and that turned out
to be inconsistencies in ant for determining the skip-tests flag for that
build - for the framework projects that did not yet have tests. I missed
addressing this for the new tests I added yesterday.
I think it's all good now. Thanks again for your work on getting RoyaleUnit
to work for javascript - I have ported most of the tests from the
manualtests/UnitTests project I had set up.

I will continue to use this the manualtest project for iterative
development. But I now have the assertion method signatures aligned with
RoyaleUnit so it's very close for a simple copy/paste of test files into
RoyaleUnit - I just need to change a couple more minor things to get there,
which I will do in the coming week. Note that I added a swfVersion
detection in the RoyaleUnit test apps. For some things like XML behavior
and methods like removeAt/insertAt expected test results can vary depending
on the swf version (or some tests can't be performed for methods that are
not yet available in an older swf version). Having the tests aware of swf
version for their expected values is helpful in case the swf version
changes for compiling the tests at some future point... in theory they
should continue to work if that happens.


On Sat, Aug 10, 2019 at 4:59 AM Josh Tynjala 
wrote:

> In a library like frameworks/js/projects/CoreJS, the Ant build checks to
> see if src/test/royale/build.xml exists to determine if it needs to run
> tests for JS. If the file isn't there, it won't run tests for JS. This will
> not prevent it from running tests for SWF. A similar check is also in the
> Ant build for frameworks/projects/Core to determine if it needs to run
> tests for SWF.
>
> This was basically how it was set up when we were using FlexUnit and could
> only run SWF tests. I'm not sure who did that originally. I just made the
> same mechanism work for JS tests too, once we had RoyaleUnit and the
>  Ant task available.
>
> If you have some tests that need to be run in SWF only, but other tests
> that should be run in both SWF and JS, then I think that you need to use
> COMPILE::SWF to omit certain tests from the JS build. Similarly with
> COMPILE::JS for JS-only tests.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Fri, Aug 9, 2019 at 1:42 AM Greg Dove  wrote:
>
> > It looked like the asjs build was fine, but I need to figure out what I
> was
> > doing wrong with the royaleunit setup to get it (presumably) not run the
> > new swf tests in js-only.
> > So I commented out the new tests in the build, and (fingers crossed) this
> > should mean the js-only build will work again.
> > @josh if you have any guidance about the js-only side of things for
> > RoyaleUnit, I'd certainly welcome that! Maybe I'm missing something
> really
> > obvious (probably!).
> >
> > I'm not even sure how to run js-only build locally. But I will take
> another
> > look tomorrow.
> >
> >
> > On Fri, Aug 9, 2019 at 6:20 PM Greg Dove  wrote:
> >
> > >
> > > fyi, I am not sure what is causing the builds to fail, as they are
> > working
> > > fine for me locally.
> > >  I see one was failing on
> > > Express: DataBindingExample
> > > prior to my recent commits and is continuing to fail at the same spot
> (it
> > > does not do that for me locally)
> > >
> > > js-only seems stuck on one of the new royaleunit tests I added which
> > > appears attempting to run for swf.
> > >
> > > I will be back in one hour to try to figure these out, sorry if there
> is
> > > any inconvenience
> > >
> >
>


Re: Builds

2019-08-09 Thread Greg Dove
It looked like the asjs build was fine, but I need to figure out what I was
doing wrong with the royaleunit setup to get it (presumably) not run the
new swf tests in js-only.
So I commented out the new tests in the build, and (fingers crossed) this
should mean the js-only build will work again.
@josh if you have any guidance about the js-only side of things for
RoyaleUnit, I'd certainly welcome that! Maybe I'm missing something really
obvious (probably!).

I'm not even sure how to run js-only build locally. But I will take another
look tomorrow.


On Fri, Aug 9, 2019 at 6:20 PM Greg Dove  wrote:

>
> fyi, I am not sure what is causing the builds to fail, as they are working
> fine for me locally.
>  I see one was failing on
> Express: DataBindingExample
> prior to my recent commits and is continuing to fail at the same spot (it
> does not do that for me locally)
>
> js-only seems stuck on one of the new royaleunit tests I added which
> appears attempting to run for swf.
>
> I will be back in one hour to try to figure these out, sorry if there is
> any inconvenience
>


Builds

2019-08-09 Thread Greg Dove
fyi, I am not sure what is causing the builds to fail, as they are working
fine for me locally.
 I see one was failing on
Express: DataBindingExample
prior to my recent commits and is continuing to fail at the same spot (it
does not do that for me locally)

js-only seems stuck on one of the new royaleunit tests I added which
appears attempting to run for swf.

I will be back in one hour to try to figure these out, sorry if there is
any inconvenience


Re: [royale-compiler] branch develop updated: compiler-jx: added inline-constants compiler option for JS builds to optionally inline the values of primitive constants (like Number, String, Boolean, in

2019-08-08 Thread Greg Dove
That sounds great for sure, Josh.
I suspect the 4KB savings comparison might be before the release javascript
is gzipped?
I tend to use 7zip (on Windows) to gzip the release build javascript from
the 2 variations and compare those, using gzip here to mirror what
difference it would make in usual real world conditions. It can sometimes
be a bit demoralizing when you see the smaller difference in absolute terms
when comparing gzipped variants, but if you look at the percentage
improvements it is probably still quite a good improvement.

fyi I just fixed an annotation directive that was not working correctly at
the class level (it was at individual member level previously). If
something is never needed for reflection and is only for static constants,
like your example, then marking it as @royalesuppressexport at the class
level might even do something with similar results in the release build -
for that specific class only. But of course it is not a simple
configuration setting for the whole build, like you are doing.




On Fri, Aug 9, 2019 at 3:06 AM Josh Tynjala 
wrote:

> My goal is to be able to completely omit classes from release builds when
> their only purpose is to define a bunch of constants. Usually, you only
> need a small number of the constants, so the rest of them bloat your app
> for no good reason.
>
> I made a test project with a class that defines 100 Number constants. When
> combined this inline-constants option with a hacky tweak to the compiler
> that omitted the constant definitions from the output, it made the release
> build 4KB smaller. I still need to figure out how to do that in a non-hacky
> way, but that kind of reduction is really promising.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Aug 7, 2019 at 2:47 PM Greg Dove  wrote:
>
> > Hey Josh, that sounds pretty cool. I'm not sure, but it might however be
> > duplicating some aspects of what GCC already does when it optimizes
> because
> > I expect it might do the same types of thing when it processes the @const
> > annotations in the debug code hints.
> > Also, for example, strings are only included once in the js-release build
> > if they are above a minimal length and then accessed by reference
> > irrespective of what inlining changes were made in the debug code output.
> > This ends up being similar conceptually to SWF's (and AMF) string tables
> I
> > think, although I did not check whether that changed since the ASC 2.0
> > inlining support.
> >
> > fyi I have a local compiler branch from FlexJS days where I have bindings
> > for (static) primitive constants being converted to initialization value
> > assignments with inline values instead of *actual bindings*, similar to
> > what I assume you are doing here, but as a way to avoid running binding
> > code for simple static constant bindings. I will revisit that at some
> point
> > soon, It might help improve startup speed for some people.
> >
> >
> >
> > On Thu, Aug 8, 2019 at 9:09 AM  wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > joshtynjala pushed a commit to branch develop
> > > in repository https://gitbox.apache.org/repos/asf/royale-compiler.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/develop by this push:
> > >  new 61479f5  compiler-jx: added inline-constants compiler option
> for
> > > JS builds to optionally inline the values of primitive constants (like
> > > Number, String, Boolean, int, and uint) instead of referencing them.
> > > 61479f5 is described below
> > >
> > > commit 61479f5cce3c4ea582a1a6a859f1e74ef9256a9f
> > > Author: Josh Tynjala 
> > > AuthorDate: Wed Aug 7 13:52:59 2019 -0700
> > >
> > > compiler-jx: added inline-constants compiler option for JS builds
> to
> > > optionally inline the values of primitive constants (like Number,
> String,
> > > Boolean, int, and uint) instead of referencing them.
> > >
> > > Defaults to false. It may make sense to switch this to true in the
> > > future, but it's not stable yet.
> > >
> > > Does not yet skip unnecessary goog.require() calls, even though the
> > > classes may no longer be referenced. Figuring out how to do this should
> > > reduce the size of release builds.
> > > ---
> > >  .../internal/codegen/js/jx/IdentifierEmitter.java  | 37
> > > +-
> > >  .../driver/js/goog/JSGoogConfiguration.java| 19 +++
> > >  2 files changed, 55 insertions(+), 1 deletion(-)
>

Re: Minification problem with latest build

2019-08-08 Thread Greg Dove
I suggest you double check that your google closure js lib is correctly
unzipped and is not missing parts or has empty folders for some parts. I
had an issue yesterday where I needed to do that manually, but I thought it
was 'just me'
fwiw I think your tP.If might simply be remapped version of:
org.apache.royale.events.getTargetWrapper

...in which case org.apache.royale.events could correspond to tP and is
maybe undefined when it should not be. Not sure... good luck, I will try to
investigate tomorrow local time if you still see issues.


On Thu, 8 Aug 2019, 21:20 Piotr Zarzycki,  wrote:

> Hi Guys,
>
> Yesterday for some reason our application started to failing in release
> build. I have spend many hours to figure out where is the point of breakage
> but I'm still not sure and what is the code in our app that it causes.
> Here is the minified line of code [1]. Exception is saying:
>
> "TypeError: Cannot set property 'If' of undefined"
>
> So there is a variable "tP." which is undefined. Anyone understand for
> example why there upper case "If" word?
>
> I'm using build [2]
>
> [1] https://paste.apache.org/l7iez
> [2]
>
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/3355/
>
> Thanks,
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>


Re: [royale-compiler] branch develop updated: compiler-jx: added inline-constants compiler option for JS builds to optionally inline the values of primitive constants (like Number, String, Boolean, in

2019-08-07 Thread Greg Dove
Hey Josh, that sounds pretty cool. I'm not sure, but it might however be
duplicating some aspects of what GCC already does when it optimizes because
I expect it might do the same types of thing when it processes the @const
annotations in the debug code hints.
Also, for example, strings are only included once in the js-release build
if they are above a minimal length and then accessed by reference
irrespective of what inlining changes were made in the debug code output.
This ends up being similar conceptually to SWF's (and AMF) string tables I
think, although I did not check whether that changed since the ASC 2.0
inlining support.

fyi I have a local compiler branch from FlexJS days where I have bindings
for (static) primitive constants being converted to initialization value
assignments with inline values instead of *actual bindings*, similar to
what I assume you are doing here, but as a way to avoid running binding
code for simple static constant bindings. I will revisit that at some point
soon, It might help improve startup speed for some people.



On Thu, Aug 8, 2019 at 9:09 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> joshtynjala pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-compiler.git
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new 61479f5  compiler-jx: added inline-constants compiler option for
> JS builds to optionally inline the values of primitive constants (like
> Number, String, Boolean, int, and uint) instead of referencing them.
> 61479f5 is described below
>
> commit 61479f5cce3c4ea582a1a6a859f1e74ef9256a9f
> Author: Josh Tynjala 
> AuthorDate: Wed Aug 7 13:52:59 2019 -0700
>
> compiler-jx: added inline-constants compiler option for JS builds to
> optionally inline the values of primitive constants (like Number, String,
> Boolean, int, and uint) instead of referencing them.
>
> Defaults to false. It may make sense to switch this to true in the
> future, but it's not stable yet.
>
> Does not yet skip unnecessary goog.require() calls, even though the
> classes may no longer be referenced. Figuring out how to do this should
> reduce the size of release builds.
> ---
>  .../internal/codegen/js/jx/IdentifierEmitter.java  | 37
> +-
>  .../driver/js/goog/JSGoogConfiguration.java| 19 +++
>  2 files changed, 55 insertions(+), 1 deletion(-)
>
> diff --git
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/IdentifierEmitter.java
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/IdentifierEmitter.java
> index 4d42069..f6363ea 100644
> ---
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/IdentifierEmitter.java
> +++
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/IdentifierEmitter.java
> @@ -19,9 +19,12 @@
>
>  package org.apache.royale.compiler.internal.codegen.js.jx;
>
> +import org.apache.royale.abc.ABCConstants;
>  import org.apache.royale.abc.semantics.Namespace;
>  import org.apache.royale.compiler.codegen.ISubEmitter;
>  import org.apache.royale.compiler.codegen.js.IJSEmitter;
> +import org.apache.royale.compiler.constants.IASLanguageConstants;
> +import org.apache.royale.compiler.definitions.IConstantDefinition;
>  import org.apache.royale.compiler.definitions.IDefinition;
>  import org.apache.royale.compiler.definitions.IFunctionDefinition;
>  import
> org.apache.royale.compiler.definitions.IFunctionDefinition.FunctionClassification;
> @@ -37,6 +40,7 @@ import
> org.apache.royale.compiler.internal.codegen.js.goog.JSGoogEmitterTokens;
>  import
> org.apache.royale.compiler.internal.codegen.js.royale.JSRoyaleEmitterTokens;
>  import org.apache.royale.compiler.internal.codegen.js.utils.EmitterUtils;
>  import org.apache.royale.compiler.internal.definitions.*;
> +import org.apache.royale.compiler.internal.projects.RoyaleJSProject;
>  import org.apache.royale.compiler.internal.tree.as
> .BinaryOperatorAssignmentNode;
>  import org.apache.royale.compiler.internal.tree.as
> .BinaryOperatorDivisionAssignmentNode;
>  import org.apache.royale.compiler.internal.tree.as
> .MemberAccessExpressionNode;
> @@ -76,12 +80,43 @@ public class IdentifierEmitter extends JSSubEmitter
> implements
>  && !identifierIsAccessorFunction;
>  boolean emitName = true;
> JSRoyaleEmitter fjs = (JSRoyaleEmitter)getEmitter();
> +RoyaleJSProject project =
> (RoyaleJSProject)getWalker().getProject();
> boolean isCustomNamespace = false;
> boolean isStatic = nodeDef != null && nodeDef.isStatic();
>  if (nodeDef instanceof FunctionDefinition &&
>   fjs.isCustomNamespace((FunctionDefinition)nodeDef))
> -   isCustomNamespace = true;
> +  isCustomNamespace = true;
>
> +if (isStatic
> +&& nodeDef instanceof 

Re: [royale-asjs] 01/02: Specifying these dependencies in maven was necessary to get build working locally.

2019-07-31 Thread Greg Dove
Hi Piotr,

I'm not sure, but if there isn't I assume it will be easy to swap things
out to do that. I'm AFK now, but I can take a look at that tomorrow.



On Wed, 31 Jul 2019, 17:55 Piotr Zarzycki, 
wrote:

> Hi Greg,
>
> Is there any kind of global variable where version of Royale is specified
> instead hardcoded?
>
> Thanks,
> Piotr
>
> On Wed, Jul 31, 2019, 3:05 AM  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > gregdove pushed a commit to branch develop
> > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> >
> > commit 9010ab1fe8ede921541f212d7da850b23fc3aa88
> > Author: greg-dove 
> > AuthorDate: Wed Jul 31 12:44:55 2019 +1200
> >
> > Specifying these dependencies in maven was necessary to get build
> > working locally.
> > ---
> >  frameworks/projects/DragDrop/pom.xml | 28 
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/frameworks/projects/DragDrop/pom.xml
> > b/frameworks/projects/DragDrop/pom.xml
> > index d4ba4e4..9d14ed5 100644
> > --- a/frameworks/projects/DragDrop/pom.xml
> > +++ b/frameworks/projects/DragDrop/pom.xml
> > @@ -86,6 +86,34 @@
> >  swc
> >  js
> >  
> > +
> > +  org.apache.royale.framework
> > +  Collections
> > +  0.9.6-SNAPSHOT
> > +  swc
> > +  swf
> > +
> > +
> > +  org.apache.royale.framework
> > +  Collections
> > +  0.9.6-SNAPSHOT
> > +  swc
> > +  js
> > +
> > +
> > +  org.apache.royale.framework
> > +  Graphics
> > +  0.9.6-SNAPSHOT
> > +  swc
> > +  swf
> > +
> > +
> > +  org.apache.royale.framework
> > +  Graphics
> > +  0.9.6-SNAPSHOT
> > +  swc
> > +  js
> > +
> >
> >
> >  
> >
> >
>


Re: Royale Commercial Support Page (was: Fwd: AIR and Royale)

2019-07-25 Thread Greg Dove
Hi Carlos,

I would definitely be keen to be added.

Name: Greg Dove
Short Description: Independent, remote development services, with over 12
years of experience working with mxml and actionscript 3, for clients
around the globe.
Website url: http://greg-dove.com/
Contact person: Greg Dove
Contact email: greg.d...@gmail.com
Contact phone: +64 21 2725522
Apache Royale Contributor: committer

On Fri, Jul 26, 2019 at 10:54 AM Carlos Rovira 
wrote:

> Hi!
>
> New commercial support page is ready and published. Andrew, I get some of
> the texts from other apache webs, but anyway some review for your part
> would be great! :)
>
> https://royale.apache.org/royale-commercial-support/
>
> Anyone that wants to be listed, please follow instructions!! :)
>
>
>
>
> El vie., 7 jun. 2019 a las 15:51, Andrew Wetmore ()
> escribió:
>
> > This is s great idea
> >
> > On Fri, Jun 7, 2019, 6:24 AM Carlos Rovira, 
> > wrote:
> >
> > > Hi,
> > >
> > > I'll be creating a page on the website in the following days with a
> list
> > of
> > > third party providers that offers commercial support for Apache Royale,
> > in
> > > the lines we saw in the links shared by Dave Fisher as examples in
> other
> > > Apache products.
> > >
> > > It could be companies or individuals.
> > >
> > > Anyone that wants to be listed, please share here the following data:
> > >
> > > * NAME
> > > * SHORT DESCRIPTION (if applies)
> > > * LOGO (if applies) (PNG, background transparent, good resolution (at
> > least
> > > above 800px)
> > > * WEBSITE URL
> > > * CONTACT PERSON (in case of individual can be same as NAME)
> > > * EMAIL OF CONTACT
> > > * PHONE OF CONTACT
> > > * APACHE ROYALE CONTRIBUTOR (if the company or individual has people
> > > contributing to this project, or if is an individual contributes to
> this
> > > project)
> > >
> > > thanks
> > >
> > >
> > > -- Forwarded message -
> > > De: Carlos Rovira 
> > >
> > > If you consider this ok, I can create a thread so companies that want
> to
> > be
> > > listed, can express they want to, and I can create a page in our site
> > with
> > > the logos and urls and maybe more (contact person?, ...)
> > >
> > > thanks
> > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: library-path changes

2019-07-24 Thread Greg Dove
Hi Carlos,

Just to clarify: I had wondered whether there were inconsistencies in the
framework so I checked more on that before adding my previous post in this
thread.
It seems that
true was
achieving a similar result to using 'provided' for the (inter)dependencies
inside each framework project, so my concerns were not valid.

When I look inside royale-maven-plugin, I do see some minor differences
with respect to "runtime" specifically but tbh I would need to spend more
time to understand why it is doing what it does with a combination of
classifier and scope checks specifically for "runtime" and not "provided".
Other than those differences, I think "runtime" and "provided" do seem to
be treated the same.




On Thu, Jul 25, 2019 at 5:36 AM Carlos Rovira 
wrote:

> Hi,
>
> if I understand correctly, both "runtime" and "provided" are right now
> equal for the compiler, right? I'm ok to understand conceptually
> "runtime" and "provided" as Greg says. At least for now, although if we can
> inform the compiler to differentiate as well would be great.
>
> In the other hand, flemojos seems to me more natural ("merged",
> "external",...) since is what we use to manage in Flex days and in
> FlashBuilder,
> but don't know if is worth it to go to that kind of names, or better go to
> the standard maven names. If it was easy to add flemojos names, I'd choose
> those, but since there's many things to do, maybe we can stick with what we
> have.
>
> In the other hand, thanks to Greg, we have this config solved in our real
> App now. But I think in the process of doing this fix I think Greg saw some
> issues
> at framework level for maven. Hope Greg can expose it better if that's the
> case, since maybe I'm wrong.
>
> thanks
>
>
>
>
> El mié., 24 jul. 2019 a las 2:15, Greg Dove ()
> escribió:
>
> > Just to add to the discussion on the 'provided' vs. 'runtime' scopes...
> > I'm not really sure what scope name should be used for what, but here's
> > what I have assumed:
> > 'runtime' is for 'native' libs where the runtime provides the api surface
> > that is represented by the swc. (playerglobal/ js-typedefs examples)
> > 'provided' is for dependencies that are pre-compiled swc dependencies,
> > where the dependency is expected to provided when the application is
> built
> > (in this case I have assumed it is explicitly listed as a dependency for
> > the application build).
> >
> > I think these are different to what used to be the case with FlexMojos
> (see
> > 'Scope options in Flexmojos' [1])
> > Also it seems that we don't do any of this in the framework project level
> > poms, so I assume
> > that true at
> > frameworks/projects/pom.xml is a 'brute-force' override, simulating
> > provided for each of the child framework projects' swc
> > dependencies, and avoiding them being merged in for each of the framework
> > swcs. I assume this might be another difference from [1] also, but I'm
> not
> > really sure as my only exposure to maven has been since FlexJS/Royale.
> >
> >
> > 1.
> > https://www.adobe.com/devnet/flex/articles/flex-maven-flexmojos-pt3.html
> >
> >
> >
> > --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: library-path changes

2019-07-23 Thread Greg Dove
Just to add to the discussion on the 'provided' vs. 'runtime' scopes...
I'm not really sure what scope name should be used for what, but here's
what I have assumed:
'runtime' is for 'native' libs where the runtime provides the api surface
that is represented by the swc. (playerglobal/ js-typedefs examples)
'provided' is for dependencies that are pre-compiled swc dependencies,
where the dependency is expected to provided when the application is built
(in this case I have assumed it is explicitly listed as a dependency for
the application build).

I think these are different to what used to be the case with FlexMojos (see
'Scope options in Flexmojos' [1])
Also it seems that we don't do any of this in the framework project level
poms, so I assume
that true at
frameworks/projects/pom.xml is a 'brute-force' override, simulating
provided for each of the child framework projects' swc
dependencies, and avoiding them being merged in for each of the framework
swcs. I assume this might be another difference from [1] also, but I'm not
really sure as my only exposure to maven has been since FlexJS/Royale.


1.  https://www.adobe.com/devnet/flex/articles/flex-maven-flexmojos-pt3.html



On Tue, Jul 23, 2019 at 5:37 AM Josh Tynjala 
wrote:

> Thanks for posting that, Carlos. It reminded me of another rule that's
> important: All "typedefs" SWCs should always be added to the
> external-library-path. Even if you are building an app and not a library,
> typedefs must be external (because they are provided natively by the
> browser or using a 

Re: AMF and class aliases

2019-07-22 Thread Greg Dove
Andrew, you mentioned this was being 'deserialized', so I assume this is
coming from the server as an untyped (plain) Object?

In that case, it will be deserialized with the correct original field name
from the server ('RESULT_CODE' in this case), but there is no typed
reference to that in your local code, so as Alex says the release build is
renaming it, and as suggested there needs to be more 'clues' to prevent the
renaming. I believe Alex knows more about the rules for that than I do.

It seems that you have a way to make it work now, which is probably all you
want.

But for completeness: another option is to send it as a typed class using
public vars (not using any manual-coded getter/setter pair or Bindable).
class ResultCode { public var RESULT_CODE:String; }
You could then cast the result in the same way you mentioned in your first
post.

The difference here is that this will also likely rename the field access
in the release build in the same way that you saw with the original
problem, but amf deserialization will support that and it should therefore
match up with the renamed field name used in your release-build local code.
So it's probably an 'in-between' option to consider, for the future.



On Tue, Jul 23, 2019 at 4:11 PM Alex Harui  wrote:

> FWIW, AIUI, the property names of plain Objects and public vars will be
> renamed unless a quoted string of that property name is used "somewhere" in
> the JS code.
>
> It might have worked just to use JSON-style:
> {"RESULT_CODE": "OK"}
>
> Creating a class definition causes the compiler to generate an
> Object.defineProperties structure with the property name as a key in the
> object structure, thus preventing the rename.
>
> If you scan the js-debug output for RESULT_CODE, you should see where that
> string showed up and how having a variable "nc" would save bytes, but the
> name to use for a renamable property is independent of that, and I think
> properties are renamed before figuring out whether a local variable would
> further save bytes.
>
> So, that's roughly the answer to #1.  For #2, you "should" use classes
> with getter/setters instead of [Bindable] unless you need property change
> detection at runtime in order to get code-completion and compile-time
> checking that you didn't mis-type "RESULTCODE".   There is probably a
> trade-off of how many times you'll make mistakes like that vs the time to
> create the classes and the additional time to load the class definitions.
> It should be smaller to use [brackets] than load the classes.
>
> The new IDEs should consider a wizard to help generate those classes.
>
> HTH,
> -Alex
>
>
> On 7/22/19, 2:18 AM, "Frost, Andrew"  wrote:
>
> Hi again
>
> One extra question here: we have the AMF connection working fine now
> in Debug mode, but in Release mode the minifier is changing the property
> names of our JavaScript (compiled from ActionScript), but these are not
> being reflected in the objects that are deserialised.
>
> So for example, we are receiving an ArrayCollection, and accessing one
> element's property directly e.g.:
> var results : ArrayCollection = resultEvt.result as ArrayCollection;
> for (var i : uint = 0; i < results.length; i++)
> {
>   var resultCode : String =
> results[i].outputArray.source[0].RESULT_CODE;
> ...
>
> There are a couple of things going on:
> (a) each element in the main ArrayCollection has an "outputArray"
> property which is itself an ArrayCollection. We could cast it into an
> ArrayCollection variable I guess, but instead have just added "source" so
> that the JavaScript doesn't try adding the [] operator to the
> ArrayCollection object directly...
> (b) the contents of this ArrayCollection, in this particular case, is
> a simple object {RESULT_CODE: "OK"} - which I can see in the console when
> we add some trace. The js-debug file has the same structure as the
> ActionScript; but the js-release file has a mapping at the start
> "nc='RESULT_CODE'" and then accesses the data with "
> a.L(c).outputData.source[0].tP" (and that's even weirder as why is it 'tP'
> rather than 'nc'?!)
>
>
> I guess the questions I have are:
>
> 1) Is there a way to prevent the Google closure compiler from
> minifying a particular property name/string?
> or
> 2) Are we going to have to just declare classes for all of these and
> do a typecast e.g. along the lines of:
> class ResultCode { [Bindable]public var RESULT_CODE; }
> and then
> var resultCodeObj : ResultCode = results[i].outputArray.source[0];
> var resultCode : String = resultCodeObj.RESULT_CODE;
>
>
&

Re: Crux Branch

2019-07-16 Thread Greg Dove
Ok thanks for clarifying Carlos, I will merge into develop as-is (with
required updates following Josh's changes) later today.


On Tue, Jul 16, 2019 at 8:05 PM Carlos Rovira 
wrote:

> Hi Greg,
>
> agree with all you say.
>
> As a user of Swiz on Flex, I know Swiz was a "sub-framework" and used by a
> "subset" of teams and developers in the world. So in the end is a piece of
> software needed, for using Royale in big projects, but for migration from
> Flex I expect few devs/teams, since that implies they was using Swiz
> instead of Cairngorm/Parsley/PureMVC/RobotLegs/Mate or the miriad of other
> arquitecturas like this.
>
> For me Crux like Jewel is needed to do modern Royale development for the
> old and new devices (and after doing a first app and having to do lots of
> workarounds to solve organizational/structural issues as we growed).
>
> So for me is something to market with the rest of Royale (strand, beads,
> jewel,...) that we decided together to separate from the marketing of Flex.
>
> As Greg said my main point with renaming is to create other things like an
> icon, examples, and continue effort on website, but if folks think this is
> not important, then we can go with Swiz or SwizRoyale and let all like
> that, but certainly that will not be very appealing to me to invest time on
> creating material for something that is off the overall marketing effort.
>
> In exchange, I prefer completely something fresh like "Crux", for all the
> reasons I already exposed, but as I said, although I don't want
> "Swiz/SwizRoyale", I think it shouldn't be "Crux" 100%. I can understand
> folks here could want to propose other naming options and just have in mind
> things like meaning, shortness and other marketing things with what we can
> work in create material around this new Royale piece.
>
> In the end I think is more important to me to know if we (and I in
> concrete) are doing right investing time trying to make website / docs /
> examples / jewel themes ... with a design based on marketing guidelines to
> get some feeling of uniqueness or is useless or not valuable. Maybe I'm
> blinded by what I see and only I see it and in that case it would not make
> any sense so many hours chasing that kind of goal since it'll does not fit
> any community need out there.
>
> About Merging: Greg, I think you should not wait for that, since any
> decision we make can be done in develop in a new commit easily, either we
> decide to left as is, try to choose a new name or change it to
> Swiz/SwizRoyale options.
>
> Thanks
>
>
>
> El mar., 16 jul. 2019 a las 8:45, Greg Dove ()
> escribió:
>
> > Alex,
> >
> > I think that java framework is unlikely to be important for the same
> > reasons you give for 3rd party Basic or Jewel.
> > Firstly I don't think it has been widely used.
> > Although it is never a perfect assessment, I tend to look at things like
> > that by first checking how active they are (commits, issues etc as a
> > project) and also how popular they are (in the absence of more stringent
> > criteria, this is my same 'rule of thumb' for choosing an npm library
> these
> > days too)
> > That project does not appear to be active for at least 3 years (whatever
> > type of activity you look at), and has a low star-rating and fork count.
> > Secondly, and perhaps more importantly, iiuc that project is more of an
> > alternative to Royale than it is something that would be ported to
> Royale.
> > It looks to be a way to write web apps in java with xml-based component
> > definitions.
> > So (assuming that is correct), I do consider the risk of any confusion
> here
> > is extremely low based on how popular/active it is and also on (my
> > understanding of) what it does.
> >
> > In terms of effort etc...
> > I was only vaguely aware of Swiz before I worked with Carlos, I had only
> > used PureMVC, Parsley and Robotlegs previously. So I can say outright
> that
> > I approached this without any prior knowledge of Swiz.
> > Firstly, for the 'porting' aspect, we are only talking about the volume
> of
> > Swiz-based Flex apps that have not yet been migrated to some other
> > platform. We have no way of knowing how many that is. It may not be that
> > large, and I think Carlos is thinking more about the value of having
> 'Crux'
> > marketing to support future applications being built with Royale, to help
> > drive demand for Royale in general. Carlos will need to confirm that, but
> > it was my impression.
> > For people who are porting a legacy app, whether someone uses Crux in
> > Royale or Swiz in Flex i

Re: Crux Branch

2019-07-16 Thread Greg Dove
oyale, i.e Apache Royale Basic, Apache Royale Jewel,
>  just
> > a
> > convenient name to refer a concrete part of the Apache Royale
> ecosystem
> > with a bit of meaning and other bit of marketing (I plan to
> create some
> > icon for the web in the future as I did with Jewel, and we can
> do some
> > graphics and more when we reach a good point with the actual
> > documentation
> > effort). One important thing for me with the name is to make it
> > different
> > to Swiz to avoid confusion on that part: Swiz is for Flex, while
> Crux
> > is
> > for Royale. So if people talks about Swiz it will be clear that
> is
> > about
> > the project for Apache Flex, while if talks about Crux is clear
> that
> > is for
> > Apache Royale. The same happens at major level with Apache Flex
> and
> > Apache
> > Royale project.
> >
>     >     So for me it's all ok.
> >
> > Thanks for the hard work in this regard Greg!
> >
> > Carlos
> >
> >
> >
> >
> >
> >
> > El vie., 12 jul. 2019 a las 9:31, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>)
> > escribió:
> >
> > > Hi Greg,
> > >
> > > Thanks for update. I'm having again more important tasks and
> that is
> > why I
> > > didn't start release process yet. It looks like I will have
> for sure
> > 2 full
> > > working days to start process on upcoming Wednesday. If you
> make it
> > till
> > > that time it would be great, if not let's stay on the branch.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > pt., 12 lip 2019 o 07:26 Greg Dove 
> napisał(a):
> > >
> > > > Just a quick update...
> > > >
> > > > I just fixed the ant builds for the 3 simple crux examples
> in the
> > branch,
> > > > which were not working yet.
> > > >
> > > > There will continue to be improvements and fixes over time,
> but I
> > > actually
> > > > think it's at a state where it could be merged into develop.
> > Unless there
> > > > is a reason not to, I plan to do this by start of next week.
> > > > This should not impact anyone else because it is something
> new,
> > there are
> > > > no changes to anything already present.
> > > >
> > > > In terms of the name as 'Crux', so far I had feedback from
> one
> > person to
> > > > give the naming some more thought, mainly because of the
> > possibility for
> > > > name conflicts with other libraries.
> > > > Carlos suggested to me that we should always use 'Apache
> Royale
> > Crux' in
> > > > terms of a general reference or to introduce it for the first
> > time, and
> > > > then (iirc) 'Crux' by itself only in a very clear Apache
> Royale
> > context,
> > > > which avoids naming conflicts. As I understand it, this type
> of
> > issue is
> > > > similar to some other things from the past.
> > > >
> > > > So far I don't see anything holding back a merge. But please
> let
> > me know
> > > if
> > > > there is anything else.
> > > >
> > > > Thanks,
> > > > -Greg
> > > >
> > > >
> > > >
> > > > On Sat, Jul 6, 2019 at 3:35 AM Josh Tynjala <
> > joshtynj...@bowlerhat.dev>
> > > > wrote:
> > > >
> > > > > Interesting! I didn't know that the capture phase worked
> for
> > > non-bubbling
> > > > > events. Good to know. Thanks for looking into it and
> sharing your
> > > > findings,
> > > > > Greg.
> > > > >
> > > > > - Josh
> > > > >
> > > > >
> > > > > On Thu, Jul 4, 2019, 11:12 PM Greg Dove <

Re: AMF and class aliases

2019-07-15 Thread Greg Dove
Also, before I forget:

If your legacy flex app includes [Transient] metadata anywhere, don't
forget to include that in the keep-as3-metadata as part of the
configuration for your royale app version as well.
AMFBinaryData will ignore those members with Transient metadata in the amf
serialization, as it does for ByteArray in swf.



On Tue, Jul 16, 2019 at 8:25 AM Greg Dove  wrote:

> Hi Andrew, to answer specifically about:
> > - the AMF serialization for classes is taking their public properties. We
> > had removed the public properties and changed them into private
> properties
> > plus public get functions, in order to avoid the warning from the Google
> > Closure Compiler, but the serializer is only looking at traditional
> > properties rather than at accessors. Not sure whether this is something
> > that we should consider changing in the future within the framework..?
>
> It sounds to me like the issue here is that you are only creating public
> getters. This won't work (in swf or javascript) because AMF serialization
> requires matching public getter/setter pairs for the member to be included
> in the serialized amf representation of the class instance.
>
> You have a few options here:
> 1. If you are confident of the use of the (presumably VO ?) classes
> everywhere, you can suppress those warnings [1] (feel free to improve that
> documentation if you want, as it is preliminary)
> 2. If you want bindable classes, the easiest thing is to mark the class
> with [Bindable] metadata (note that this is 'easy' but because of the
> bindable support will create more code, and run slightly slower than (3)
> below.
> 3. You can manually create getter/setter support for each of the public
> vars.
>
> As another thing, if you ever want to test amf serialization, you can do
> that in the same way you do things with ByteArray in swf.
> var ba:AMFBinaryData = new AMFBinaryData();
> var instance:Object = {}; // try other things here, myVO etc )
> trace(instance); // inspect in browser console
> ba.writeObject(instance);
> ba.position = 0;
> instance = ba.readObject();
> trace(instance); // inspect in browser console
>  The above should perform the same type of deep-clone that you get when
> you do it in swf (so long as all the class aliases are defined for the
> instance's object tree when it is not a plain 'Object' like above)
>
> 1.
> https://apache.github.io/royale-docs/create-an-application/optimizations/doc-comment-directives.html#royalesuppresspublicvarwarning
>
> On Tue, Jul 16, 2019 at 2:45 AM Carlos Rovira 
> wrote:
>
>> Hi Andrew,
>>
>> El lun., 15 jul. 2019 a las 16:18, Frost, Andrew (<
>> andrew.fr...@harman.com>)
>> escribió:
>>
>> > Hi
>> >
>> > A custom bead for localization is a very good idea, yes. In this
>> instance,
>> > we're looking at a migration from Flex so trying to keep as much of the
>> > original code the same as possible; with a custom (albeit generic) bead
>> > we've managed to do this. Not sure whether their code was the most
>> > efficient form when looked at from a Flex perspective either..
>> >
>>
>> in jewel we are using Localization in Validator.as (through core
>> ILocalizedValuesImpl)
>> but the plan is remove that in the future since Alex pointed that we
>> should
>> not use localization in that way. In the future, validation should
>> separate
>> logic from view so the validation logic should check the VO, DTOs,
>> Pojos...
>> objects while the visuals could be changed from tooltips to static labels
>> or whatever the user wants to inject. And the same way for localizations
>>
>>
>> > In terms of the AMF stuff, we've found a few more gotchas:
>> > - not 100% sure if these are necessary, but we had been just setting the
>> > endpoint manually so that the connection could be made, but we also
>> need to
>> > have the 'destination' value set on the RemoteObject, and possibly the
>> ID
>> > as well. In Flex, it was only the 'destination' being set up, and the
>> > framework then went and got the ID and the endpoint from the
>> configuration
>> > file... we might look into adding support for that services
>> configuration
>> > file (in some form) to make this process a little simpler.
>> >
>>
>> in AMF/RO we have already are using "destination" (in fact we are setting
>> destination along with the ChannelSet), so if you're having problems maybe
>> it could be that you're using other RO implementation. I recommend you to
>> use MXRoyale RemoteObject implementation since is the closest to F

Re: AMF and class aliases

2019-07-15 Thread Greg Dove
gt; From: Alex Harui 
> > Sent: 15 July 2019 05:39
> > To: dev@royale.apache.org
> > Subject: [EXTERNAL] Re: AMF and class aliases
> >
> > IMO, localization may perform better with a custom bead or two.  Generic
> > binding must watch something for changes that might require that
> > getString() be called again, but in general, either bindings to locales
> are
> > set up early (so no change watcher is needed at all), or because of PAYG,
> > you should pay more to watch something like the locale changing.  But a
> > custom binding bead could know to watch whatever you are using to load
> > localized strings instead of using the generic watching rules.
> >
> > HTH,
> > -Alex
> >
> > On 7/12/19, 9:12 AM, "Frost, Andrew"  wrote:
> >
> > Thanks
> >
> > Yes, binding is one that we're definitely also having some fun with.
> > Wrote our own little binding bead for now but at some point I'll get
> round
> > to looking in depth to see if there's a way of doing this using the
> > 'proper' beads. In case you're that interested: it's for localisation
> where
> > we have an object assigned to the class and when a property of the object
> > is updated, it fires a "changed" event which we need to listen out for
> and
> > then re-load in all the bound details, which are function calls with
> > parameters i.e. this.localised.getString('id'). Tried a couple of binding
> > beads and investigated what was happening, they were able to detect when
> > the 'localised' variable was being changed i.e. a new one being added to
> > 'this', but that's not what we're looking for. I think the use of the
> basic
> > "changed" event rather than "ValueChangedEvent" might be confusing it..
> >
> > Anyway. Getting there. There is a response coming from the server now
> > although I'm not sure whether this is then getting handled properly and
> > what the next event is that's going out to the server, it's not working
> > fully yet. Trying to remotely debug without any access to this myself :-(
> >
> >
> > thanks
> >
> >Andrew
> >
> >
> >
> > -Original Message-
> > From: Carlos Rovira 
> > Sent: 12 July 2019 11:45
> > To: dev@royale.apache.org
> > Subject: [EXTERNAL] Re: AMF and class aliases
> >
> > Yeah! we are in production with AMF for around 4 months without any
> > issue!
> > So RO works great for Royale ;)
> >
> > this kind of problems where something is not working and is about a
> > missed bead are very typical to Royale.
> > Is the same with binding, statesbut our brains ends taking that
> > into account and soon you'll get to that process ;)
> >
> > Best
> >
> > Carlos
> >
> >
> >
> > El vie., 12 jul. 2019 a las 0:38, Greg Dove ()
> > escribió:
> >
> > > Yes, it should just work. There is at least one working example in
> > the
> > > examples set, and it should work with CommandMessage etc, without
> > any
> > > of the tweaks that you mentioned.
> > >
> > > Carlos is using amf extensively and it is currently in use in a
> > > production app.
> > >
> > > Let me know if you see any bugs.
> > >
> > > cheers,
> > > Greg
> > >
> > >
> > >
> > > On Fri, Jul 12, 2019 at 10:31 AM Frost, Andrew
> > > 
> > > wrote:
> > >
> > > > Oh it's that simple!
> > > >
> > > > Yes I just took a look, that does appear to go through it all and
> > > > set everything up...
> > > >
> > > > Thank you!  that saved us a bit of effort trying to update the
> > > > compiler
> > > ;-)
> > > >
> > > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: Greg Dove 
> > > > Sent: 11 July 2019 23:27
> > > > To: dev@royale.apache.org
> > > > Subject: [EXTERNAL] Re: AMF and class aliases
> > > >
> > > > Hi Andrew,
> > > > 'but I can't see anywhere that this list is accessed/used.'
> > > >
> > > > I think you need ClassAliasBead on your Application level, which
> > > > will process all the definitions.
> > > >

Re: library-path and external-library-path fixes

2019-07-15 Thread Greg Dove
Hi Josh, that sounds fantastic! Thanks for your work on that!
This is also more how I would intuitively expect things to work. I had
'wondered' why we were using 'library-path' instead of
'extenal-library-path' everywhere at different times, but I just followed
the existing pattern

I guess this might mean that for some apps, if B.swc was currently being
used in the app's library-path, then its (now) 'external' A.swc dependency
would now need to be added to app's library-path if its only use was in
('fat swc') B.swc in the past (to follow your explanation examples). But
iiuc, I expect this is aligned with how things worked in the past with flex.

I will update the crux branch with these changes today - thanks again!


On Tue, Jul 16, 2019 at 7:32 AM Josh Tynjala 
wrote:

> Hey folks,
>
> I just pushed some commits to royale-compiler and royale-asjs, and I wanted
> to add a little explanation, and some possible troubleshooting advice if
> anything seems to have broken in your apps.
>
> My work over the last week has been to fix an issue related to specifying
> dependencies when compiling libraries for JS. As you probably know, the
> compiler supports two options for adding libraries as dependencies,
> library-path and external-library-path. The library-path compiler option
> basically says "include all classes that I use from this SWC in the final
> output". It's typically what you use when compiling an app that uses a
> library. The external-library-path compiler option basically says "if I use
> anything from this SWC, check that I'm using the types correctly, but don't
> include any of classes from this SWC in the final output".
>
> If you're compiling an app, you typically use library-path for everything.
> You use external-library-path only for dependencies like
> playerglobal.swc/airglobal.swc in Flash or typedef SWCs in JS. Basically,
> for an app project, external-library-path is for classes that are provided
> natively by the Flash runtime or a web browser, like Chrome or Firefox.
>
> When compiling libraries, external-library-path is also used to prevent the
> compiler from creating a "fat" library that stuffs in all of the
> dependencies. Let's say that you have a library, A.swc. It provides some
> core functionality that is needed by both B.swc and C.swc. When we compile
> B.swc and C.swc, we don't want the classes from A.swc duplicated in both of
> them. So we add A.swc to the external-library-path when compiling B.swc or
> C.swc. Then, if you use those SWCs when compiling an app, you need to add
> A.swc, B.swc, and C.swc to the library-path.
>
> To put that in Royale terms, A.swc is something like LanguageJS.swc or
> CoreJS.swc. They're some of our lowest-level SWCs in the framework. B.swc
> and C.swc are more like BasicJS.swc or JewelJS.swc, and they tend to share
> multiple classes from the lower-level stuff.
>
> Up until now, library-path and external-library-path were a little quirky
> when compiling to JS. It was related to the goog.provide() and
> goog.require() calls that you might have seen in the generated JS. These
> are from the module system that we use in Royale. The compiler didn't know
> how to differentiate between classes that had goog.provide() and classes
> that were typedefs for JS libraries. It treated everything on the
> external-library-path as a typedef, and this led to missing goog.require()
> calls in the generated JS. To work around this, when we specified
> dependencies in our framework SWCs, we used library-path to ensure that
> goog.require() would be used.
>
> This workaround of using library-path led to "fat" SWCs that contained all
> of their dependencies. Low-level classes in SWCs like CoreJS were
> duplicated in higher-level SWCs. This led to the compiler getting confused
> about exactly where a class was defined.
>
> This has resulted in some minor issues here and there, but nothing too
> major until recently. However, Harbs noticed the other day that it caused
> the compiler to copy extra default CSS into apps from SWCs that you may not
> have been using. So, you might build an app with the Basic components, but
> you'd get extra CSS from Jewel or MaterialDesignLite. This could mess up
> your app's styling pretty dramatically.
>
> I updated the compiler to better detect when a class needs goog.require()
> and when it's a typedef. If that class comes from a SWC, the compiler knows
> to check for an included file like, js/out/com/example/MyClass.js. If the
> generated JS is there, goog.require() is necessary. If it's missing, it's
> treated as a typedef class instead. If the class is an .as source file
> instead, the compiler looks for the @externs asdoc tag to determine if it's
> a typedef class (and everything else needs goog.require() instead).
>
> By the way, if we ever support other module systems, it shouldn't be too
> difficult to extend this code to detect different SWC layouts for each
> module system.
>
> If your project is an app, this change 

Re: Crux Branch

2019-07-12 Thread Greg Dove
Hi Josh, it's great that you're working on this. Unless I'm mistaken, there
is currently a 'manual' way to do this, which you may have already seen,
using 'exclude-defaults-css-files'

in royale-config, I believe this type of approach works:

 
MXRoyaleJS.swc:defaults.css


(I saw Carlos did this at one point in his own project, somewhat different
via maven additionalCompilerOption, and did the same in ant for the Crux
examples)


I presume it might also work with
'JewelJS.swc:defaults.css' in there, for example (I
have not specifically tested).

Just mentioning this in case it helps with the work you are doing



On Sat, Jul 13, 2019 at 5:00 AM Josh Tynjala 
wrote:

> I'm working on a fix for the CSS issue that Harbs started a thread about.
> I'm almost ready, but I have some edge cases to finish up. I feel like it's
> an important one to get into the release because it injects a lot of Jewel
> CSS into non-Jewel apps (and CSS from *several* other SWCs too). However,
> my changes may also be a little disruptive if I missed something, so it may
> take a few days to smooth out any last minute issues as people try it out
> with their existing apps.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Fri, Jul 12, 2019 at 12:31 AM Piotr Zarzycki  >
> wrote:
>
> > Hi Greg,
> >
> > Thanks for update. I'm having again more important tasks and that is why
> I
> > didn't start release process yet. It looks like I will have for sure 2
> full
> > working days to start process on upcoming Wednesday. If you make it till
> > that time it would be great, if not let's stay on the branch.
> >
> > Thanks,
> > Piotr
> >
> > pt., 12 lip 2019 o 07:26 Greg Dove  napisał(a):
> >
> > > Just a quick update...
> > >
> > > I just fixed the ant builds for the 3 simple crux examples in the
> branch,
> > > which were not working yet.
> > >
> > > There will continue to be improvements and fixes over time, but I
> > actually
> > > think it's at a state where it could be merged into develop. Unless
> there
> > > is a reason not to, I plan to do this by start of next week.
> > > This should not impact anyone else because it is something new, there
> are
> > > no changes to anything already present.
> > >
> > > In terms of the name as 'Crux', so far I had feedback from one person
> to
> > > give the naming some more thought, mainly because of the possibility
> for
> > > name conflicts with other libraries.
> > > Carlos suggested to me that we should always use 'Apache Royale Crux'
> in
> > > terms of a general reference or to introduce it for the first time, and
> > > then (iirc) 'Crux' by itself only in a very clear Apache Royale
> context,
> > > which avoids naming conflicts. As I understand it, this type of issue
> is
> > > similar to some other things from the past.
> > >
> > > So far I don't see anything holding back a merge. But please let me
> know
> > if
> > > there is anything else.
> > >
> > > Thanks,
> > > -Greg
> > >
> > >
> > >
> > > On Sat, Jul 6, 2019 at 3:35 AM Josh Tynjala  >
> > > wrote:
> > >
> > > > Interesting! I didn't know that the capture phase worked for
> > non-bubbling
> > > > events. Good to know. Thanks for looking into it and sharing your
> > > findings,
> > > > Greg.
> > > >
> > > > - Josh
> > > >
> > > >
> > > > On Thu, Jul 4, 2019, 11:12 PM Greg Dove  wrote:
> > > >
> > > > > Hi Josh,
> > > > >
> > > > > For the addedToStage stuff:
> > > > > You made me look! Swiz does not actually use the ADDED event, it
> > > > definitely
> > > > > does use ADDED_TO_STAGE by default, but you're absolutely right,
> this
> > > > does
> > > > > not bubble.
> > > > >
> > > > > I did not pay too much attention to the 'bubbling' side of things
> > > > because I
> > > > > could see it working in flash and just assumed that's what was
> > > happening.
> > > > > But it is actually being listened to as a capture phase event. And
> > that
> > > > > does give the same outward impression (without looking too closely)
> > as
> > > if
> > > > > it were bubbling in this case.
> > > > >
> > > > > I even resorted to a quick test in Adobe Animate to verify:
>

Re: Crux Branch

2019-07-11 Thread Greg Dove
Just a quick update...

I just fixed the ant builds for the 3 simple crux examples in the branch,
which were not working yet.

There will continue to be improvements and fixes over time, but I actually
think it's at a state where it could be merged into develop. Unless there
is a reason not to, I plan to do this by start of next week.
This should not impact anyone else because it is something new, there are
no changes to anything already present.

In terms of the name as 'Crux', so far I had feedback from one person to
give the naming some more thought, mainly because of the possibility for
name conflicts with other libraries.
Carlos suggested to me that we should always use 'Apache Royale Crux' in
terms of a general reference or to introduce it for the first time, and
then (iirc) 'Crux' by itself only in a very clear Apache Royale context,
which avoids naming conflicts. As I understand it, this type of issue is
similar to some other things from the past.

So far I don't see anything holding back a merge. But please let me know if
there is anything else.

Thanks,
-Greg



On Sat, Jul 6, 2019 at 3:35 AM Josh Tynjala 
wrote:

> Interesting! I didn't know that the capture phase worked for non-bubbling
> events. Good to know. Thanks for looking into it and sharing your findings,
> Greg.
>
> - Josh
>
>
> On Thu, Jul 4, 2019, 11:12 PM Greg Dove  wrote:
>
> > Hi Josh,
> >
> > For the addedToStage stuff:
> > You made me look! Swiz does not actually use the ADDED event, it
> definitely
> > does use ADDED_TO_STAGE by default, but you're absolutely right, this
> does
> > not bubble.
> >
> > I did not pay too much attention to the 'bubbling' side of things
> because I
> > could see it working in flash and just assumed that's what was happening.
> > But it is actually being listened to as a capture phase event. And that
> > does give the same outward impression (without looking too closely) as if
> > it were bubbling in this case.
> >
> > I even resorted to a quick test in Adobe Animate to verify:
> >
> > import flash.display.Sprite;
> > import flash.events.Event;
> >
> > var sprite:Sprite = new Sprite();
> > sprite.name ='1';
> > function onAdded(event:Event):void{
> > trace('added' ,event.target.name)
> > }
> > function onRemoved(event:Event):void{
> > trace('removed' ,event.target.name)
> > }
> >
> > sprite.addEventListener(Event.ADDED_TO_STAGE, onAdded, true);
> > sprite.addEventListener(Event.REMOVED_FROM_STAGE, onRemoved, true);
> >
> > var sprite2:Sprite = new Sprite();
> > sprite2.name = '2'
> >
> > var sprite3:Sprite = new Sprite();
> > sprite3.name = '3'
> >
> > addChild(sprite);
> > sprite.addChild(sprite2)
> >
> >
> > sprite2.addChild(sprite3);
> >
> > //remove the child tree
> > sprite.removeChild(sprite2)
> >
> > /*
> > trace output:
> > added 2
> > added 3
> > removed 2
> > removed 3
> > */
> >
> > So I updated the stage events emulator to support this.
> 'removedFromStage'
> > now also works in capture phase on the strand that the bead is on for
> child
> > event targets that were removed.
> > In terms of the names of the events... that is quite easy to change. But
> > whatever we decide on, I just need to add as a  COMPILE::JS variation to
> > the 'default' setupEventType/teardownEventType in the Config class for
> Crux
> > to account for what would now be a difference between SWF and JS (which
> is
> > fine by me, I only started with the same names by trying to match how
> > things worked in swf as they were). So far it does work the same between
> > swf and js builds, although there is only one simple example that builds
> > for both which I have tested with.
> >
> > In terms of the name of the bead, also that can be whatever people think
> > makes sense. I put JS in the name because one of the builds works for
> both
> > swf and js. And seeing that a bead is for JS only is maybe helpful to
> > know.. although I have always wondered whether it would make sense to
> have
> > compiler switches in mxml - some sort of 'transparent' enclosing tag
> > similar to how a COMPILE::JS {  code here } compile block works in
> > actionscript. I don't know it that makes sense something like that
> > could mean that the swf build does not get the unnecessary bead (which
> does
> > nothing in swf anyway)
> >
> > Thanks heaps for the prompts on these things.
> >
> >
> > -Greg
> >
> >
> > On Fri, Jul 5, 2019 at 5:49 AM Carlos Rovira 
> > wrote:
> >
> >

Re: AMF and class aliases

2019-07-11 Thread Greg Dove
Yes, it should just work. There is at least one working example in the
examples set, and it should work with CommandMessage etc, without any of
the tweaks that you mentioned.

Carlos is using amf extensively and it is currently in use in a production
app.

Let me know if you see any bugs.

cheers,
Greg



On Fri, Jul 12, 2019 at 10:31 AM Frost, Andrew 
wrote:

> Oh it's that simple!
>
> Yes I just took a look, that does appear to go through it all and set
> everything up...
>
> Thank you!  that saved us a bit of effort trying to update the compiler ;-)
>
>
>
>
> -----Original Message-
> From: Greg Dove 
> Sent: 11 July 2019 23:27
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: AMF and class aliases
>
> Hi Andrew,
> 'but I can't see anywhere that this list is accessed/used.'
>
> I think you need ClassAliasBead on your Application level, which will
> process all the definitions.
>
>
>
>
>
>
> On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew 
> wrote:
>
> > Hi all
> >
> > We're trying to get a connection to work from our Royale-based code to
> > a LiveCycle back-end, and having to debug why the AMF message is
> > different between the Flex version and the Royale version (and trying
> > to work out why the server is rejecting our initial ping message..)
> >
> > One thing that's cropped up is that Flex embeds the name of the class
> > - or rather, the alias of this - when it writes the object:
> > [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
> >
> > In Royale, this capability exists in the
> > AMFBinaryData.writeObjectVariant() method where it's using the
> > "localTraits", and we have:
> > var alias:String = classInfo.alias;//
> > getAliasByClass(instance.constructor
> > as Class); //<- @todo possible optimization: registerClassAlias
> > implementation stores in the classInfo Object, access directly
> >
> > The commented-out code does exactly what the new code does, which is
> > that it accesses the ROYALE_CLASS_INFO structure:
> > var classInfo:Object =
> > instance.ROYALE_CLASS_INFO; so to make this work, we've added an extra
> > section at the end of the ROYALE_CLASS_INFO for the CommandMessage (in
> > the generated JavaScript, so this is not a proper solution!):
> >
> > mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = {
> > names: [{ name: 'CommandMessage', qName:
> > 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias:
> > 'flex.messaging.messages.CommandMessage' };
> >
> >
> > Interestingly, the compiler looks at all the [RemoteClass(alias="")]
> > tags, and outputs a list of these in the main application's .js file:
> > TestBackend.prototype.info = function() {
> >   return { "mixins": [mx.messaging.config.LoaderConfig,
> > mx.styles.StyleManagerImpl],
> > "remoteClassAliases": {"mx.messaging.messages.CommandMessage":
> > "flex.messaging.messages.CommandMessage", "org.apache.royale.net
> .remoting.messages.ActionMessage":
> > "flex.messaging.io.amf.ActionMessage", ... etc },
> > "compiledLocales": ["en_US"]}};
> >
> > but I can't see anywhere that this list is accessed/used.
> >
> >
> > So it looks to me like there's a discrepancy between how the compiler
> > is trying to make this work, and how the framework is expecting it to
> > be set up by the compiler. I was wondering if anyone know what had
> > been going on here and whether we should go for one way or another ..
> > and by preference I think, getting the compiler to add the alias
> > directly into the ROYALE_CLASS_INFO as that seems to be a better way of
> doing it I think..?
> >
> >
> > thanks
> >
> >Andrew
> >
> > p.s. we've had a few other issues with the AMF format, e.g. using
> > 'unknown length' and having this as +1 rather than -1; plus a single
> > message was being packaged as an array, whereas Flex/Flash Player
> > doesn't do that.. I'm wondering whether anyone has a problem if we try
> > to make the AMF messages generated from a Royale app to be as similar
> > as possible to how the Flash Player does it..?!
> >
> >
>


Re: AMF and class aliases

2019-07-11 Thread Greg Dove
Hi Andrew,
'but I can't see anywhere that this list is accessed/used.'

I think you need ClassAliasBead on your Application level, which will
process all the definitions.






On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew 
wrote:

> Hi all
>
> We're trying to get a connection to work from our Royale-based code to a
> LiveCycle back-end, and having to debug why the AMF message is different
> between the Flex version and the Royale version (and trying to work out why
> the server is rejecting our initial ping message..)
>
> One thing that's cropped up is that Flex embeds the name of the class - or
> rather, the alias of this - when it writes the object:
> [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
>
> In Royale, this capability exists in the
> AMFBinaryData.writeObjectVariant() method where it's using the
> "localTraits", and we have:
> var alias:String = classInfo.alias;// getAliasByClass(instance.constructor
> as Class); //<- @todo possible optimization: registerClassAlias
> implementation stores in the classInfo Object, access directly
>
> The commented-out code does exactly what the new code does, which is that
> it accesses the ROYALE_CLASS_INFO structure:
> var classInfo:Object =
> instance.ROYALE_CLASS_INFO;
> so to make this work, we've added an extra section at the end of the
> ROYALE_CLASS_INFO for the CommandMessage (in the generated JavaScript, so
> this is not a proper solution!):
>
> mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = {
> names: [{ name: 'CommandMessage', qName:
> 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias:
> 'flex.messaging.messages.CommandMessage' };
>
>
> Interestingly, the compiler looks at all the [RemoteClass(alias="")] tags,
> and outputs a list of these in the main application's .js file:
> TestBackend.prototype.info = function() {
>   return { "mixins": [mx.messaging.config.LoaderConfig,
> mx.styles.StyleManagerImpl],
> "remoteClassAliases": {"mx.messaging.messages.CommandMessage":
> "flex.messaging.messages.CommandMessage", 
> "org.apache.royale.net.remoting.messages.ActionMessage":
> "flex.messaging.io.amf.ActionMessage", ... etc },
> "compiledLocales": ["en_US"]}};
>
> but I can't see anywhere that this list is accessed/used.
>
>
> So it looks to me like there's a discrepancy between how the compiler is
> trying to make this work, and how the framework is expecting it to be set
> up by the compiler. I was wondering if anyone know what had been going on
> here and whether we should go for one way or another .. and by preference I
> think, getting the compiler to add the alias directly into the
> ROYALE_CLASS_INFO as that seems to be a better way of doing it I think..?
>
>
> thanks
>
>Andrew
>
> p.s. we've had a few other issues with the AMF format, e.g. using 'unknown
> length' and having this as +1 rather than -1; plus a single message was
> being packaged as an array, whereas Flex/Flash Player doesn't do that.. I'm
> wondering whether anyone has a problem if we try to make the AMF messages
> generated from a Royale app to be as similar as possible to how the Flash
> Player does it..?!
>
>


Re: Crux Branch

2019-07-05 Thread Greg Dove
Hi Josh,

For the addedToStage stuff:
You made me look! Swiz does not actually use the ADDED event, it definitely
does use ADDED_TO_STAGE by default, but you're absolutely right, this does
not bubble.

I did not pay too much attention to the 'bubbling' side of things because I
could see it working in flash and just assumed that's what was happening.
But it is actually being listened to as a capture phase event. And that
does give the same outward impression (without looking too closely) as if
it were bubbling in this case.

I even resorted to a quick test in Adobe Animate to verify:

import flash.display.Sprite;
import flash.events.Event;

var sprite:Sprite = new Sprite();
sprite.name ='1';
function onAdded(event:Event):void{
trace('added' ,event.target.name)
}
function onRemoved(event:Event):void{
trace('removed' ,event.target.name)
}

sprite.addEventListener(Event.ADDED_TO_STAGE, onAdded, true);
sprite.addEventListener(Event.REMOVED_FROM_STAGE, onRemoved, true);

var sprite2:Sprite = new Sprite();
sprite2.name = '2'

var sprite3:Sprite = new Sprite();
sprite3.name = '3'

addChild(sprite);
sprite.addChild(sprite2)


sprite2.addChild(sprite3);

//remove the child tree
sprite.removeChild(sprite2)

/*
trace output:
added 2
added 3
removed 2
removed 3
*/

So I updated the stage events emulator to support this. 'removedFromStage'
now also works in capture phase on the strand that the bead is on for child
event targets that were removed.
In terms of the names of the events... that is quite easy to change. But
whatever we decide on, I just need to add as a  COMPILE::JS variation to
the 'default' setupEventType/teardownEventType in the Config class for Crux
to account for what would now be a difference between SWF and JS (which is
fine by me, I only started with the same names by trying to match how
things worked in swf as they were). So far it does work the same between
swf and js builds, although there is only one simple example that builds
for both which I have tested with.

In terms of the name of the bead, also that can be whatever people think
makes sense. I put JS in the name because one of the builds works for both
swf and js. And seeing that a bead is for JS only is maybe helpful to
know.. although I have always wondered whether it would make sense to have
compiler switches in mxml - some sort of 'transparent' enclosing tag
similar to how a COMPILE::JS {  code here } compile block works in
actionscript. I don't know it that makes sense something like that
could mean that the swf build does not get the unnecessary bead (which does
nothing in swf anyway)

Thanks heaps for the prompts on these things.


-Greg


On Fri, Jul 5, 2019 at 5:49 AM Carlos Rovira 
wrote:

> Hi Andrew,
>
> good point! That's without doubt another new point to bring to :
>
> - Royale-docs: We can follow most of the documentation available here [1]
> - Examples: In this case I don't see a Tour app since the use cases are
> very direct and can be exposed in few examples.
> Greg already provide 3 examples that shows all the things currently
> developed here [2]. I think we'll need to do soon a blog example
> covering Crux too that could be one of those or a new one. For example TODO
> List example would be a good one to apply Crux ;)
>
> [1] https://swizframework.jira.com/wiki/spaces/SWIZ/overview
> [2] https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux
>
> So many work there too to make it all avaialble to Apache Royale users as
> easy as possible ;)
>
>
>
> El jue., 4 jul. 2019 a las 18:46, Andrew Wetmore ()
> escribió:
>
> > This is great.
> >
> > However, even with the original Swiz I found the documentation quite thin
> > and that it made a lot of assumptions about what a general developer
> might
> > know and need to know. This site [1] made an attempt about ten years ago
> to
> > improve on an intro to Swiz. What plans are in the works to not only
> > provide Crux, but make it welcoming and accessible? Tour de Crux??
> >
> > a
> >
> > [1] https://deshartman.wordpress.com/2010/02/07/first-swiz/
> >
> > On Thu, Jul 4, 2019 at 1:17 PM Josh Tynjala 
> > wrote:
> >
> > > Cool stuff, Greg and Carlos!
> > >
> > > One concern: In Flash, the "addedToStage" event does not bubble. It's
> > > actually the "added" event that bubbles and is used by frameworks like
> > > Swiz, Cairngorm, Robotlegs, etc.
> > >
> > > To avoid potential confusion for people migrating an existing app from
> > > Flex/Flash that might already listen for that event (and wouldn't
> expect
> > it
> > > to bubble), I'd recommend using a different name than "addedToStage".
> It
> > > could be "added", like Flash. Or it could even have a new nam

Crux Branch

2019-07-04 Thread Greg Dove
Hi all,

Just a quick advance notice that we are getting something very similar to
Swiz before too long.
There is a new branch called feature/Crux

We can still explore other possible ways to incorporate Swiz code in Royale
(we have looked at having the code donated in the past), but for now at
least it is as a derivative work, differentiated by name as 'Crux' and
hence the name of the branch. 'Crux' means a main or pivotal point -
something important - and a common English expression that can express that
is when someone says ""the crux of the matter" - it means an important
thing to focus on.

The name is what it is now - it is short and has a powerful meaning. But
certainly we can review that too.

The branch has the beginnings of the original Swiz functionality which
supports metadata driven Injection (including runtime Binding Injection),
EventHandlers, main Dispatcher etc.
Those things are already shown in 3 examples [1] in examples/crux in the
branch, (but I did not check the ant builds for those yet- I will get to
that). Beyond those features, I have not ventured far yet, and perhaps some
of the others may not be relevant for Royale.

In case it's useful elsewhere, there is also a new JSStageEvents  'stage
events' simulator bead which works from the main application level, and
provides bubbling 'addedToStage' events which Crux listens to at the top
level. These can be filtered (so not everything generates the events, for
example). Not sure if that might be useful for other things, just
mentioning it for now... It does dispatch 'removedFromStage' as well, but
too late for bubbling, so I will investigate if I can do something a bit
sneaky to see if I can make that work. Otherwise it is always possible to
add  removedFromStage  listeners directly to the target of interest inside
an 'addedToStage' listener.

I expect there will be bugs, and I of course there will be many things I
can continue to improve, so this is just an early announcement for your
awareness. Carlos sponsored a large chunk of my time on this, so you have
him to thank for that, but I have also contributed a lot of my own time,
and will continue to do so. Thanks also to Alex for recent guidance on
licencing issues, this was uncharted territory for me.

Anyhow, Carlos will, I am sure, provide more info, he is very familiar with
Swiz from the past.

-Greg


1. https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux


Re: [royale-asjs] 01/04: Fix for top-level reset variation in SimpleBinding

2019-07-03 Thread Greg Dove
It is when a top level item is reset

label text={myOtherthing.someValue}

if myOtherthing gets set to null elsewhere, the binding was not updating
before this, so the text was not set to empty. Setting to null works, not
sure about undefined... I can't see strict equality being used anywhere in
Bindings (expect in one typeof check where it should not make any
difference)


On Thu, Jul 4, 2019 at 5:56 AM Harbs  wrote:

> Not sure I’m understanding the reason for this, but would undefined be
> better than null?
>
> > On Jul 3, 2019, at 11:55 AM, gregd...@apache.org wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > gregdove pushed a commit to branch develop
> > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> >
> > commit cf410568241cbba9d6f55cb3aa73983d213a7cae
> > Author: greg-dove 
> > AuthorDate: Wed Jul 3 19:56:15 2019 +1200
> >
> >Fix for top-level reset variation in SimpleBinding
> > ---
> > .../Binding/src/main/royale/org/apache/royale/binding/SimpleBinding.as
> | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git
> a/frameworks/projects/Binding/src/main/royale/org/apache/royale/binding/SimpleBinding.as
> b/frameworks/projects/Binding/src/main/royale/org/apache/royale/binding/SimpleBinding.as
> > index 9ecfd96..8d6934d 100644
> > ---
> a/frameworks/projects/Binding/src/main/royale/org/apache/royale/binding/SimpleBinding.as
> > +++
> b/frameworks/projects/Binding/src/main/royale/org/apache/royale/binding/SimpleBinding.as
> > @@ -273,6 +273,8 @@ public class SimpleBinding implements IBead,
> IDocument, IBinding
> >   {
> >   dispatcher.addEventListener(eventName,
> changeHandler);
> >   destination[destinationPropertyName] =
> source[sourcePropertyName];
> > + } else {
> > + destination[destinationPropertyName] = null;
> >   }
> >   }
> > }
> >
>
>


Re: Compiler Performance (was Re: Problem with Vectors)

2019-07-03 Thread Greg Dove
gt; example,
> > > > when you use @royaleignorecoercion, you promise that no code
> paths
> > > will
> > > > actually depend on that coercion, you just added the coercion to
> > > keep the
> > > > compiler from complaining.  And if it turns out you needed it,
> > > you'll end
> > > > up with a bug.  We could do something similar now like
> > > > @royaleusetypedarrayforthisvector and if other code ends up
> turning
> > > off the
> > > > "fixed" property and push stuff you'll end up with a bug.  I
> think
> > > that
> > > > would only take someone a week or less.
> > > > > > >>>
> > > > > > >>> Or as I asked earlier, why can't folks just use
> > > Uint8Array?
> > > > > > >>>
> > > > > > >>> HTH,
> > > > > > >>> -Alex
> > > > > > >>>
> > > > > > >>> On 6/14/19, 11:08 AM, "Josh Tynjala" <
> > > joshtynj...@apache.org>
> > > > wrote:
> > > > > > >>>
> > > > > > >>>I definitely understand your concern about
> > potentially
> > > > missing edge cases, and having that cause problems in the future.
> > > That's
> > > > why I've been trying to make new language features disabled by
> > > default so
> > > > that folks need to knowingly opt in.
> > > > > > >>>
> > > > > > >>>In my opinion, we should have left abstract
> classes
> > > and
> > > > private constructors disabled by default for a while, until more
> > > people
> > > > could give them a try. These features haven't even been included
> in
> > > an
> > > > official release yet. While I have a pretty good set of unit
> tests
> > > for each
> > > > one, I'm sure that there are still some edge cases that I'll need
> > to
> > > > address in the future.
> > > > > > >>>
> > > > > > >>>- Josh
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>On 2019/06/14 17:39:53, Alex Harui
> > > 
> > > > wrote:
> > > > > > >>>> IMO, it will be a significant amount of work to
> > provide
> > > new
> > > > syntax around typed collections to ActionScript.  I cannot help
> > here
> > > > because I am not a language expert.  Having interacted briefly
> with
> > > the
> > > > ActionScript language team, I am certain I do not have the skills
> > to
> > > help
> > > > here and am concerned that we'll miss something and be sorry
> later.
> > > > > > >>>>
> > > > > > >>>> So, as long as folks are aware of that and still
> want
> > > to go
> > > > forward, I'm not going to stand in their way.  I am going to
> > suggest
> > > easier
> > > > ways that might save some time because I think there are bigger
> > fish
> > > to fry
> > > > with the limited folks we have contributing to Royale.  I'd
> rather
> > > see a
> > > > quick way of allowing folks to use TypedArrays to see how
> > > useful/important
> > > > it is and then see if we can make Royale successful and recruit
> > > someone
> > > > with language design experience.
> > > > > > >>>>
> > > > > > >>>> IOW, creating the general case implementation
> starting
> > > now
> > > > may not be in the best interests of the project.  I would rather
> we
> > > make
> > > > migrating Flex code easier/faster, and those folks may not have
> > time
> > > to
> > > > consider changing their code to switch to TypedArrays.
> > > > > > >>>>
> > > > > > >>>> Just from some quick thinking, I would say that
> > getting
> > > the
> > > > parser to handle some new syntax is only 25% of the work.
> An

Re: Vector coercion

2019-07-01 Thread Greg Dove
It's great that you found it. I don't think I ever used that setting yet,
but I have switched to ['forcedName'] for some things, sometimes.
Perhaps it is related to some other changes in the overall build for
whether the names are 'preserved' for dynamic access based on what other
classes use with 'known' member references (guessing only).


On Tue, Jul 2, 2019 at 9:03 AM Harbs  wrote:

> Adding js-dynamic-access-unknown-members fixed my problem, but I don’t
> know why I needed to add it to TLF all of the sudden.
>
> FWIW, the problem was the properties in the object lookup in
> SpacingLimitPropertyHandler being minified.
>
> > On Jul 1, 2019, at 11:18 PM, Greg Dove  wrote:
> >
> > By property, you mean getter/setter accessor?
> > If yes, I'm assuming that you've already inspected the js-debug
> annotations
> > to verify that they have not changed? (still have @lends with @export for
> > each )
> > Other than that, I think I'd have to find a way to repro it to help
> figure
> > it out. I'll keep an eye open for anything like that today.
> >
> >
> > On Tue, Jul 2, 2019 at 8:01 AM Harbs  wrote:
> >
> >> I’ve been doing a lot of that.
> >>
> >> Right now, I’m trying to figure out why an object has renamed properties
> >> when it didn’t used to.
> >>
> >> One thing I discovered is that initializing properties causes Google
> >> Closure to mess up renaming much more than uninitialized ones. Not sure
> why
> >> that is.
> >>
> >> Harbs
> >>
> >>> On Jul 1, 2019, at 10:19 PM, Greg Dove  wrote:
> >>>
> >>> 'The latests compiler changes have really taken a LOT of my time'
> >>>
> >>> Sorry to hear that, I have been there myself in the past. Can I check:
> is
> >>> this still related to Vector?
> >>> The docs also explain ways to switch off the other newer things (such
> as
> >>> the implicit casts: js-complex-implicit-coercions, for example), in
> case
> >>> that makes a difference.
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, Jul 2, 2019 at 6:53 AM Harbs  wrote:
> >>>
> >>>> Yes. Switching off the index checking seems to help. (partially. I’m
> >> still
> >>>> trying to track down why my app isn’t working)
> >>>>
> >>>> The latests compiler changes have really taken a LOT of my time… :-(
> >>>>
> >>>>> On Jul 1, 2019, at 9:46 PM, Greg Dove  wrote:
> >>>>>
> >>>>> ' Yes. Not sure how to reproduce t for you.'
> >>>>>
> >>>>> OK, thanks for confirming. Hopefully switching off the index checking
> >>>> works
> >>>>> for you for now. I will see if I can repro that either later today or
> >>>>> tomorrow.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Jul 2, 2019 at 6:44 AM Harbs  wrote:
> >>>>>
> >>>>>> Yes. Not sure how to reproduce t for you.
> >>>>>>
> >>>>>>> On Jul 1, 2019, at 8:37 PM, Greg Dove  wrote:
> >>>>>>>
> >>>>>>> Are you seeing the index checking code being generated with
> >>>>>>> '-js-vector-emulation-class=Array'  set for all your builds? If so,
> >>>>>> that's
> >>>>>>> a bug, and I'd be keen to repro it and fix.
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>


Re: Vector coercion

2019-07-01 Thread Greg Dove
By property, you mean getter/setter accessor?
If yes, I'm assuming that you've already inspected the js-debug annotations
to verify that they have not changed? (still have @lends with @export for
each )
Other than that, I think I'd have to find a way to repro it to help figure
it out. I'll keep an eye open for anything like that today.


On Tue, Jul 2, 2019 at 8:01 AM Harbs  wrote:

> I’ve been doing a lot of that.
>
> Right now, I’m trying to figure out why an object has renamed properties
> when it didn’t used to.
>
> One thing I discovered is that initializing properties causes Google
> Closure to mess up renaming much more than uninitialized ones. Not sure why
> that is.
>
> Harbs
>
> > On Jul 1, 2019, at 10:19 PM, Greg Dove  wrote:
> >
> > 'The latests compiler changes have really taken a LOT of my time'
> >
> > Sorry to hear that, I have been there myself in the past. Can I check: is
> > this still related to Vector?
> > The docs also explain ways to switch off the other newer things (such as
> > the implicit casts: js-complex-implicit-coercions, for example), in case
> > that makes a difference.
> >
> >
> >
> >
> > On Tue, Jul 2, 2019 at 6:53 AM Harbs  wrote:
> >
> >> Yes. Switching off the index checking seems to help. (partially. I’m
> still
> >> trying to track down why my app isn’t working)
> >>
> >> The latests compiler changes have really taken a LOT of my time… :-(
> >>
> >>> On Jul 1, 2019, at 9:46 PM, Greg Dove  wrote:
> >>>
> >>> ' Yes. Not sure how to reproduce t for you.'
> >>>
> >>> OK, thanks for confirming. Hopefully switching off the index checking
> >> works
> >>> for you for now. I will see if I can repro that either later today or
> >>> tomorrow.
> >>>
> >>>
> >>>
> >>> On Tue, Jul 2, 2019 at 6:44 AM Harbs  wrote:
> >>>
> >>>> Yes. Not sure how to reproduce t for you.
> >>>>
> >>>>> On Jul 1, 2019, at 8:37 PM, Greg Dove  wrote:
> >>>>>
> >>>>> Are you seeing the index checking code being generated with
> >>>>> '-js-vector-emulation-class=Array'  set for all your builds? If so,
> >>>> that's
> >>>>> a bug, and I'd be keen to repro it and fix.
> >>>>
> >>>>
> >>
> >>
>
>


Re: Vector coercion

2019-07-01 Thread Greg Dove
'The latests compiler changes have really taken a LOT of my time'

Sorry to hear that, I have been there myself in the past. Can I check: is
this still related to Vector?
The docs also explain ways to switch off the other newer things (such as
the implicit casts: js-complex-implicit-coercions, for example), in case
that makes a difference.




On Tue, Jul 2, 2019 at 6:53 AM Harbs  wrote:

> Yes. Switching off the index checking seems to help. (partially. I’m still
> trying to track down why my app isn’t working)
>
> The latests compiler changes have really taken a LOT of my time… :-(
>
> > On Jul 1, 2019, at 9:46 PM, Greg Dove  wrote:
> >
> > ' Yes. Not sure how to reproduce t for you.'
> >
> > OK, thanks for confirming. Hopefully switching off the index checking
> works
> > for you for now. I will see if I can repro that either later today or
> > tomorrow.
> >
> >
> >
> > On Tue, Jul 2, 2019 at 6:44 AM Harbs  wrote:
> >
> >> Yes. Not sure how to reproduce t for you.
> >>
> >>> On Jul 1, 2019, at 8:37 PM, Greg Dove  wrote:
> >>>
> >>> Are you seeing the index checking code being generated with
> >>> '-js-vector-emulation-class=Array'  set for all your builds? If so,
> >> that's
> >>> a bug, and I'd be keen to repro it and fix.
> >>
> >>
>
>


Re: Vector coercion

2019-07-01 Thread Greg Dove
' Yes. Not sure how to reproduce t for you.'

OK, thanks for confirming. Hopefully switching off the index checking works
for you for now. I will see if I can repro that either later today or
tomorrow.



On Tue, Jul 2, 2019 at 6:44 AM Harbs  wrote:

> Yes. Not sure how to reproduce t for you.
>
> > On Jul 1, 2019, at 8:37 PM, Greg Dove  wrote:
> >
> > Are you seeing the index checking code being generated with
> > '-js-vector-emulation-class=Array'  set for all your builds? If so,
> that's
> > a bug, and I'd be keen to repro it and fix.
>
>


Re: Vector coercion

2019-07-01 Thread Greg Dove
Hi Harbs,

To answer your question about vector index checking... please see docs:

https://apache.github.io/royale-docs/create-an-application/optimizations/compiler-configuration-settings.html#vector-index-checking


or
https://apache.github.io/royale-docs/create-an-application/optimizations/doc-comment-directives.html#royalesuppressvectorindexcheck


But I am concerned about a potential bug.

Are you seeing the index checking code being generated with
'-js-vector-emulation-class=Array'  set for all your builds? If so, that's
a bug, and I'd be keen to repro it and fix.





On Tue, Jul 2, 2019 at 5:31 AM Harbs  wrote:

> I’m using a custom build of TLF.
>
> I added that argument, but. I’m still getting:
>
> this._handlers[this._handlers[org.apache.royale.utils.Language.CHECK_INDEX](idx)]
> = handler;
>
> How do I get rid of the index checking?
>
> > On Jul 1, 2019, at 7:40 PM, Greg Dove  wrote:
> >
> > Harbs, I set TLF to be legacy vector-as-array in the framework, and
> tested
> > it with (iirc) the TLFEditor manual test.
> >
> > -js-vector-emulation-class=Array
> >
> > I suggest you check this first, by removing that setting in the build of
> > the TLF framework lib.
> > I only put the vector-as-array setting like that in TLF lib because it
> was
> > one of the framework libs which was using Vector, and the original
> approach
> > used, and figured it might be a good place to retain it, but it may not
> be
> > depending on the code. I did explain this at the time of the Vector
> > addition, but it was a minor point amongst many updates, so would have
> been
> > easily overlooked.
> > So you might want to remove that setting above from TLF build, or you if
> > not it sounds like you probably need to use the same setting everywhere
> > else in your external code.
> >
> > The problem with 'vectorEmulationClass' in general is that if a Vector is
> > exposed anywhere, it can be an incompatible type wtih how Vector is
> > represented in another build. If it is used in a library, the type should
> > never be exposed on a public api surface.
> > This sounds like exactly the sort of problem you are experiencing.
> >
> > In terms of tuning options for Vector performance, I did ask about
> > preferred options for that already in another thread started by Yishay.
> But
> > I guess that thread went to other topics and discussion stalled. I will
> > start a new thread later today, just focused on Vector optimizations.
> >
> >
> >
> >
> > On Tue, Jul 2, 2019 at 3:35 AM Harbs  wrote:
> >
> >> I just spent a few hours trying to track down why TLF is not working for
> >> me.
> >>
> >> It looks like it has something to do with runtime Vector type checking.
> >> TLF uses Vector.. That appears to be causing some values to be
> NaN
> >> for range checking. I have not traced the problem all the way down. I’d
> >> just like to turn off the runtime checking. I’m still not clear on how I
> >> turn that off.
> >>
> >> Any pointers?
> >> Harbs
>
>


Re: Vector coercion

2019-07-01 Thread Greg Dove
Harbs, I set TLF to be legacy vector-as-array in the framework, and tested
it with (iirc) the TLFEditor manual test.

 -js-vector-emulation-class=Array

I suggest you check this first, by removing that setting in the build of
the TLF framework lib.
I only put the vector-as-array setting like that in TLF lib because it was
one of the framework libs which was using Vector, and the original approach
used, and figured it might be a good place to retain it, but it may not be
depending on the code. I did explain this at the time of the Vector
addition, but it was a minor point amongst many updates, so would have been
easily overlooked.
So you might want to remove that setting above from TLF build, or you if
not it sounds like you probably need to use the same setting everywhere
else in your external code.

The problem with 'vectorEmulationClass' in general is that if a Vector is
exposed anywhere, it can be an incompatible type wtih how Vector is
represented in another build. If it is used in a library, the type should
never be exposed on a public api surface.
This sounds like exactly the sort of problem you are experiencing.

In terms of tuning options for Vector performance, I did ask about
preferred options for that already in another thread started by Yishay. But
I guess that thread went to other topics and discussion stalled. I will
start a new thread later today, just focused on Vector optimizations.




On Tue, Jul 2, 2019 at 3:35 AM Harbs  wrote:

> I just spent a few hours trying to track down why TLF is not working for
> me.
>
> It looks like it has something to do with runtime Vector type checking.
> TLF uses Vector.. That appears to be causing some values to be NaN
> for range checking. I have not traced the problem all the way down. I’d
> just like to turn off the runtime checking. I’m still not clear on how I
> turn that off.
>
> Any pointers?
> Harbs


Re: [royale-asjs] branch develop updated: Basic, Core, RoyaleUnit: re-enabled Ant tasks for JS

2019-06-28 Thread Greg Dove
Hey Josh, that sounds great!

FYI next week I do expect to swap the manualtests UnitTests project to
match the same assertion method signatures as RoyaleUnit.
Once I do that I will port more of the existing tests across to RoyaleUnit,
in their respective libraries.
I'll also change some of the class names inside the manualtests project to
avoid any confusion with RoyaleUnit itself.




On Sat, Jun 29, 2019 at 8:02 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> joshtynjala pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new 4cd6f31  Basic, Core, RoyaleUnit: re-enabled  Ant
> tasks for JS
> 4cd6f31 is described below
>
> commit 4cd6f31a0c81dc559967a3d7b42eb0c4fab71a38
> Author: Josh Tynjala 
> AuthorDate: Fri Jun 28 13:02:16 2019 -0700
>
> Basic, Core, RoyaleUnit: re-enabled  Ant tasks for JS
> ---
>  frameworks/projects/Basic/build.xml  | 3 +--
>  frameworks/projects/Core/build.xml   | 3 +--
>  frameworks/projects/RoyaleUnit/build.xml | 2 +-
>  3 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/frameworks/projects/Basic/build.xml
> b/frameworks/projects/Basic/build.xml
> index a126cd4..bca41bf 100644
> --- a/frameworks/projects/Basic/build.xml
> +++ b/frameworks/projects/Basic/build.xml
> @@ -65,8 +65,7 @@
>
>   unless="skip-tests">
>  
> -
> -
> +
>  
>
>  
> diff --git a/frameworks/projects/Core/build.xml
> b/frameworks/projects/Core/build.xml
> index 43b642a..d023b23 100644
> --- a/frameworks/projects/Core/build.xml
> +++ b/frameworks/projects/Core/build.xml
> @@ -66,8 +66,7 @@
>
>   unless="skip-tests">
>  
> -
> -
> +
>  
>
>  
> diff --git a/frameworks/projects/RoyaleUnit/build.xml
> b/frameworks/projects/RoyaleUnit/build.xml
> index 6d6d942..7a3b41e 100644
> --- a/frameworks/projects/RoyaleUnit/build.xml
> +++ b/frameworks/projects/RoyaleUnit/build.xml
> @@ -66,7 +66,7 @@
>
>   unless="skip-tests">
>  
> -
> +
>  
>
>  
>
>


Re: XML Problem with ignoreWhiteSpace=false

2019-06-26 Thread Greg Dove
Hi Yishay, thanks for letting me know that all is well in your project. I
was getting a little concerned that the changes might have impacted you, it
is something I have been through a few times in the past so I know what it
is like.

I will look into that new issue over my weekend if it is not urgent. I
might be able to get there sooner, but I am working on something else which
I need to finish up asap, so can't promise that.
My first thought would be that it should not be related to changes, but if
it wasn't happening before the changes then I definitely need to check that.

I would have expected that to be something handled by the native DomParser
because it seems like it is related to whitespace between attributes in the
same node, but I can't rule it out because I did add some changes to the
whitespace handling in general.
Before you addressed it with the change you made, were you able to verify
that it was happening in different browsers?
If you didn't, don't worry about doing that. I will check that aspect as
well if I need to when I look into it. I have been testing across the main
browsers on windows (mainly to include IE11/Edge which seem to be outliers
in terms of the native parsing results).
I have not yet tested on Safari/MacOS.




On Wed, Jun 26, 2019 at 10:12 PM Yishay Weiss 
wrote:

> Hi Greg,
>
>
>
> Our app is working with the latest XML fixes. Thanks for taking care of
> the issues. It was a headache but we actually found some bugs in our code
> in the process.
>
>
>
> If you have time, maybe take a look at this different issue [1]. Do you
> think it could be related to any of your changes?
>
>
>
> Thanks.
>
>
>
> [1]
> https://github.com/apache/royale-asjs/commit/4b87997aa14d60bba657356a3dd17b6c6a7a4d80
>
>
>
> 
> From: Greg Dove 
> Sent: Monday, June 24, 2019 6:59:09 AM
> To: dev@royale.apache.org
> Subject: Re: XML Problem with ignoreWhiteSpace=false
>
> Yishay, a few other issues became apparent as I worked on that. So I added
> tests for them and fixed them also.
>
> I can confirm that a lot of the older implementation was failing in many of
> the tests, because I reverted to the older implementation locally and
> checked against the same tests (which run in parallel with swf). So I do
> know that this represents progress.
> But what I cannot know is if there are other things that do not work after
> these changes outside of the current test coverage (which is why it is
> essential to enhance that coverage over time).
> However I also have no desire to cause many sudden changes needed in your
> project that we could let you manage more gradually if this is causing a
> problem, because I have a feeling that you and Harbs are the main users of
> XML at the moment.
> If you are still encountering problems after my latest changes then we
> could revert the XML project to how it was before all my recent changes and
> I could move everything to a branch.
> I haven't done that to date simply because in terms of what I can see in
> the tests so far, I can only consider it to be progress in terms of getting
> the implementation closer (than it was before) to the original as3
> XML/XMList. But as I said... that is only as good as the test coverage.
> Anyhow, let me know what you think... I have fingers crossed that the
> latest changes should address things for you.
> Greg
>
>
> On Mon, Jun 24, 2019 at 12:35 AM Greg Dove  wrote:
>
> > Hi Yishay, thanks for the new details. That's another bug. I have a local
> > fix for that now, and new tests to cover this and more variations of the
> > document level parsing.
> > It's late for me now, so I will check everything thoroughly and push the
> > fix in my morning.
> >
> >
> >
> > On Sun, Jun 23, 2019 at 9:57 PM Yishay Weiss 
> > wrote:
> >
> >> Hi Greg,
> >>
> >> I’m still having issues with xml that were not there before. Can you see
> >> why this [1] app, where my.xml is [2] is giving me an exception [3]?
> >>
> >>
> >>
> >> [1] https://paste.apache.org/ld1L
> >> [2] https://paste.apache.org/d6VX
> >> [3] https://paste.apache.org/qpub
> >>
> >> Yishay
> >>
> >
>


Re: Implicit casts for typedefs

2019-06-24 Thread Greg Dove
Hi Harbs,

I am keen to help find an easier solution.

@royalesuppresscompleximplicitcoercion  crypto.createDecipher

or for non-specific suppression, simply:
@royalesuppresscompleximplicitcoercion  true
or even
@royalesuppresscompleximplicitcoercion
(which defaults to 'true')

is another option, any of the above does not require writing the extra 'as'
code and then ignoring it. So it is only one addition instead of two. But
it obviously still requires some effort and would be better if that was not
needed.

I assume you want (as would I) something more automatic or something that
is recognizable in the typedefs to prevent this problem at all in these
cases.
I have not done anything with  typedefs yet, and need to look into that
more to learn about how they work and to see how the definitions may be
recognized in the compiler as being different, such as whether they can
have their own metadata or something distinctive like that.

I can understand why it is causing an issue in this case:
'The crypto.createDecipher() or crypto.createDecipheriv() methods are used
to create Decipher instances. Decipher objects are not to be created
directly using the new keyword.'

But I don't understand your statement that 'Constructors for typedefs will
**always** be undefined because they don’t exist at runtime'
Don't we also have many typedefs that represent normal constructors too?
For example, all the native javascript types - aren't these sort of like
playerglobal.swc is for avm?

if I do:
var array:Array = [new Map()]
var myMap:Map = array[0];

I think that should work as an implicit coercion. But, like I said, maybe I
am showing my ignorance in terms of what you mean by typedefs.
I will try to get my head into the typedefs side of things next week, to
understand more.




On Mon, Jun 24, 2019 at 9:59 PM Harbs  wrote:

> I have the following code in an app which uses Node.js:
>
> var cr:* = require('crypto');
> var decipher:Decipher = cr.createDecipher('aes-256-ctr',KEY);
>
> (The reason cr is untyped is because crypto.createDecipher is not
> recognized in the typedefs.)
>
> This used to work fine, but it currently gets compiled as:
>
>   var /** @type {*} */ cr = require('crypto');
>   var /** @type {crypto.Decipher} */ decipher = /* implicit cast */
> org.apache.royale.utils.Language.as(cr["createDecipher"]('aes-256-ctr',
> com.printui.utils.PrefUtils.KEY), crypto.Decipher, true);
>
> The Language.as cast fails because the rightOperand.constructor is
> undefined. Constructors for typedefs will **always** be undefined because
> they don’t exist at runtime, so implicit casts on typedef types like this
> will always fail.
>
> Presumably, I can use:
> var decipher:Decipher = cr.createDecipher('aes-256-ctr',KEY) as Decipher;
> and it’ll work as long as I ignore as coercions as a compiler option, but
> this feels like a step backwards.
>
> Thoughts?
> Harbs


Re: XML Problem with ignoreWhiteSpace=false

2019-06-23 Thread Greg Dove
Yishay, a few other issues became apparent as I worked on that. So I added
tests for them and fixed them also.

I can confirm that a lot of the older implementation was failing in many of
the tests, because I reverted to the older implementation locally and
checked against the same tests (which run in parallel with swf). So I do
know that this represents progress.
But what I cannot know is if there are other things that do not work after
these changes outside of the current test coverage (which is why it is
essential to enhance that coverage over time).
However I also have no desire to cause many sudden changes needed in your
project that we could let you manage more gradually if this is causing a
problem, because I have a feeling that you and Harbs are the main users of
XML at the moment.
If you are still encountering problems after my latest changes then we
could revert the XML project to how it was before all my recent changes and
I could move everything to a branch.
I haven't done that to date simply because in terms of what I can see in
the tests so far, I can only consider it to be progress in terms of getting
the implementation closer (than it was before) to the original as3
XML/XMList. But as I said... that is only as good as the test coverage.
Anyhow, let me know what you think... I have fingers crossed that the
latest changes should address things for you.
Greg


On Mon, Jun 24, 2019 at 12:35 AM Greg Dove  wrote:

> Hi Yishay, thanks for the new details. That's another bug. I have a local
> fix for that now, and new tests to cover this and more variations of the
> document level parsing.
> It's late for me now, so I will check everything thoroughly and push the
> fix in my morning.
>
>
>
> On Sun, Jun 23, 2019 at 9:57 PM Yishay Weiss 
> wrote:
>
>> Hi Greg,
>>
>> I’m still having issues with xml that were not there before. Can you see
>> why this [1] app, where my.xml is [2] is giving me an exception [3]?
>>
>>
>>
>> [1] https://paste.apache.org/ld1L
>> [2] https://paste.apache.org/d6VX
>> [3] https://paste.apache.org/qpub
>>
>> Yishay
>>
>


Re: XML Problem with ignoreWhiteSpace=false

2019-06-23 Thread Greg Dove
Hi Yishay, thanks for the new details. That's another bug. I have a local
fix for that now, and new tests to cover this and more variations of the
document level parsing.
It's late for me now, so I will check everything thoroughly and push the
fix in my morning.



On Sun, Jun 23, 2019 at 9:57 PM Yishay Weiss  wrote:

> Hi Greg,
>
> I’m still having issues with xml that were not there before. Can you see
> why this [1] app, where my.xml is [2] is giving me an exception [3]?
>
>
>
> [1] https://paste.apache.org/ld1L
> [2] https://paste.apache.org/d6VX
> [3] https://paste.apache.org/qpub
>
> Yishay
>


junit download failing in ant compiler build

2019-06-22 Thread Greg Dove
I am sure others will have seen this already... 502 error for junit jar
download in ant build.

I don't know whether search.maven.org will be fixed or not, but if anyone
needs to get the ant build 'working' quickly locally, I was able to do that
via the following change in the two downloads.xml/junit-download-jar inside
the compiler repo:


https://repo1.maven.org/maven2/junit/junit/4.10"/>

I have no idea what the 'correct' solution is here. I just used that to get
it working locally for me... sharing that in case it helps anyone else.


Re: Implicit casts and skipAsCercions

2019-06-20 Thread Greg Dove
Thanks for those details Yishay, I added your example to the testing and
got that working again. The stringified output is standardized on swf, but
because of variation in the supporting DOMParsers between browsers,
attribute and namespaces order can vary in javascript, so I simply used
string length as an expected common value in these new assertions for
stringified output.

Note that processing instructions are ignored outside a root tag in as3,
even when ignoreProcessingInstructions is false, I think because there is
no 'Document' specific XML class in as3.
I have in the past sometimes needed to write 'Document'-level XML support
to handle some of the things that as3 XML does not cover (but that it does
it need to in the majority of cases).

I would be surprised if there are not more issues uncovered with XML over
time. If you notice more issues I am happy to look into them. The more
tests we can add the better...



On Thu, Jun 20, 2019 at 8:19 PM Yishay Weiss  wrote:

> Try this [1] simple app with the following [2] xml.
>
>
>
> If you look at the console you'll notice that toString() outputs "", but
> after reverting 722f16599441be4fd0243d6fe9f2cd856f1a6b0b it outputs the xml.
>
>
>
> [1] https://paste.apache.org/pndA
>
> [2] https://paste.apache.org/u0Ji
>
>
>
> 
> From: Greg Dove 
> Sent: Thursday, June 20, 2019 9:37:28 AM
> To: dev@royale.apache.org
> Subject: Re: Implicit casts and skipAsCercions
>
> Thanks Yishay.
> fyi, you can see the XML tests I already added in these classes:
>
>
> https://github.com/apache/royale-asjs/tree/develop/manualtests/UnitTests/src/main/royale/flexUnitTests/xml
>
>
> If you provide a minimal example I will add a new test tomorrow and fix
> whatever is required to make sure it passes in both swf and javascript. Or
> if you feel adventurous, feel free to build manualtests/UnitTests and add
> the failing test yourself, then I can instantly see what I need to fix.
>
> You can build that with ant or maven.
> And if you use the top level UnitTests/testsview/index.html to view the
> build ouput, you can look at the results side by side with both javascript
> and flash (assuming you sort out the latest flash plugin hurdles in
> whatever browser you use).
>
> I have already ported some of the other tests to Josh's RoyaleUnit, but I
> plan to swap the manualtest assertion format to be the same setup as
> RoyaleUnit and will add the other remaining tests to RoyaleUnit next week.
>
>
>
>
>
>
>
> On Thu, Jun 20, 2019 at 5:32 PM Yishay Weiss 
> wrote:
>
> > Hi Greg,
> >
> >
> >
> > Thanks for outlining the options again. I’ll try to create a test case
> for
> > XML today.
> >
> >
> >
> > 
> > From: Greg Dove 
> > Sent: Wednesday, June 19, 2019 11:57:22 PM
> > To: dev@royale.apache.org
> > Subject: Re: Implicit casts and skipAsCercions
> >
> > Harbs,
> >
> > js-complex-implicit-coercions is on by default. The default behavior is
> > therefore now the same as swf. It is an optimization to turn it off.
> > You need to switch it off if you want to avoid it. But if you are seeing
> > runtime errors, then it is likely indicating something that would not
> work
> > at runtime in swf, so you may also want to review that first.
> >
> > If you want code to work as before, you need to do this:
> >
> > -js-complex-implicit-coercions=false;
> > -js-vector-index-checks=false;
> > -js-resolve-uncertain=false;
> >
> > or to add them to the -config.xml
> >
> > There is also the option to output Vector as Array, if you want the
> legacy
> > approach for Vectors. I outlined these in an earlier post, but I will add
> > something more detailed to docs this week.
> >
> > For XML, I'm sorry if something is not working right now. I did port a
> lot
> > of your adhoc tests to the manualtests project. And added quite a few
> more
> > new tests. The implementation was not working correctly for quite a few
> > things. So while I addressed some new issues,there is still a lot more to
> > do. It's entirely possible that I broke something that did not have a
> test
> > yet. Unless we focus more on test coverage, it will be easy to break
> things
> > as other things get fixed, particularly with something like XML, which is
> > reasonably complex. With inadequate test coverage, it can even be
> possible
> > to start relying on an implementation that does not work as it should.
> > Yishay: can you please give me a simple test case for the XML issue you
> are
> > seeing? I will loo

Re: Implicit casts and skipAsCercions

2019-06-20 Thread Greg Dove
Thanks Yishay.
fyi, you can see the XML tests I already added in these classes:

https://github.com/apache/royale-asjs/tree/develop/manualtests/UnitTests/src/main/royale/flexUnitTests/xml


If you provide a minimal example I will add a new test tomorrow and fix
whatever is required to make sure it passes in both swf and javascript. Or
if you feel adventurous, feel free to build manualtests/UnitTests and add
the failing test yourself, then I can instantly see what I need to fix.

You can build that with ant or maven.
And if you use the top level UnitTests/testsview/index.html to view the
build ouput, you can look at the results side by side with both javascript
and flash (assuming you sort out the latest flash plugin hurdles in
whatever browser you use).

I have already ported some of the other tests to Josh's RoyaleUnit, but I
plan to swap the manualtest assertion format to be the same setup as
RoyaleUnit and will add the other remaining tests to RoyaleUnit next week.







On Thu, Jun 20, 2019 at 5:32 PM Yishay Weiss  wrote:

> Hi Greg,
>
>
>
> Thanks for outlining the options again. I’ll try to create a test case for
> XML today.
>
>
>
> ____
> From: Greg Dove 
> Sent: Wednesday, June 19, 2019 11:57:22 PM
> To: dev@royale.apache.org
> Subject: Re: Implicit casts and skipAsCercions
>
> Harbs,
>
> js-complex-implicit-coercions is on by default. The default behavior is
> therefore now the same as swf. It is an optimization to turn it off.
> You need to switch it off if you want to avoid it. But if you are seeing
> runtime errors, then it is likely indicating something that would not work
> at runtime in swf, so you may also want to review that first.
>
> If you want code to work as before, you need to do this:
>
> -js-complex-implicit-coercions=false;
> -js-vector-index-checks=false;
> -js-resolve-uncertain=false;
>
> or to add them to the -config.xml
>
> There is also the option to output Vector as Array, if you want the legacy
> approach for Vectors. I outlined these in an earlier post, but I will add
> something more detailed to docs this week.
>
> For XML, I'm sorry if something is not working right now. I did port a lot
> of your adhoc tests to the manualtests project. And added quite a few more
> new tests. The implementation was not working correctly for quite a few
> things. So while I addressed some new issues,there is still a lot more to
> do. It's entirely possible that I broke something that did not have a test
> yet. Unless we focus more on test coverage, it will be easy to break things
> as other things get fixed, particularly with something like XML, which is
> reasonably complex. With inadequate test coverage, it can even be possible
> to start relying on an implementation that does not work as it should.
> Yishay: can you please give me a simple test case for the XML issue you are
> seeing? I will look into it today.
>
>
>
>
>
> On Thu, Jun 20, 2019 at 8:33 AM Harbs  wrote:
>
> > The code has /* implicit cast */ and we do not have the
> > complex-implicit-coresions set.
> >
> > FYI, XML is also broken due to empty nodes which did not used to be
> there,
> > but I’ll let Yishay comment on the details.
> >
> > > On Jun 19, 2019, at 11:29 PM, Greg Dove  wrote:
> > >
> > > Hi Yishay,
> > >
> > > If there's a problem with this I will address it asap.
> > > The setting was not working correctly before. I think it is now, so
> that
> > > may have affected the output, but perhaps there are some test cases I
> did
> > > not cover.
> > >
> > > skipAsCoercions only relates to explicit coercions, and should not have
> > an
> > > effect on the implicit coercions
> > >
> > > (But it does make me wonder if I have implemented the new config level
> > > option correctly, maybe it should be added as one of the
> > > -js-output-optimization options instead of being another top level
> > option.
> > > I can revisit this in another thread.)
> > >
> > > For now, the equivalent is
> > > false
> > >
> > > or
> > > -js-complex-implicit-coercions=false
> > >
> > > Do you have either of those set? If so then you should not see the
> > implicit
> > > coercions unless they are toggled on locally and therefore it is an
> error
> > >
> > > Can you please also use 'find in files' with your js-debug output,
> > > searching for the text:
> > > /* implicit cast */
> > > and inspect the site of the runtime error?
> > >
> > > Is it generating the right cast on the right

Re: Jewel Module not working on release mode when deferred the load

2019-06-19 Thread Greg Dove
Hi Carlos,

This was manifesting as a minification problem, but actually that was a bit
misleading as the root cause was a compiler bug with localId.
I will push a fix for that today which means the release build will work
the same as debug build for the module example.




On Thu, Jun 20, 2019 at 7:38 AM Carlos Rovira 
wrote:

> Hi,
>
> I continue working on the blog example for modules. I think is almost done
> but I have a final issue. It works on debug but not on release
>
> On release when I hit button and load the module I get the following error
> on console:
>
> [Error] TypeError: undefined is not an object (evaluating 'this.yh.ja')
> ja (MainJewelApp.js:393:142)
> pd (MainJewelApp.js:393:223)
> (función anónima)
> Wf (MainJewelApp.js:34:244)
> fg (MainJewelApp.js:43:281)
> Rf (MainJewelApp.js:36)
> (función anónima) (MainJewelApp.js:32)
>
> Do you have some hint about what could be wrong?
> I was thinking that this could be need due to some magnification problem so
> I tried for now -js-dynamic-access-unknown-members=true, but this does not
> make any change
>
> Until now, in Basic Modules, it was loading as the ModuleLoader is
> addedToParent, in Jewel ModuleLoader I put more control, since the user
> normally would want to load the module on demand.
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: Implicit casts and skipAsCercions

2019-06-19 Thread Greg Dove
Harbs,

js-complex-implicit-coercions is on by default. The default behavior is
therefore now the same as swf. It is an optimization to turn it off.
You need to switch it off if you want to avoid it. But if you are seeing
runtime errors, then it is likely indicating something that would not work
at runtime in swf, so you may also want to review that first.

If you want code to work as before, you need to do this:

-js-complex-implicit-coercions=false;
-js-vector-index-checks=false;
-js-resolve-uncertain=false;

or to add them to the -config.xml

There is also the option to output Vector as Array, if you want the legacy
approach for Vectors. I outlined these in an earlier post, but I will add
something more detailed to docs this week.

For XML, I'm sorry if something is not working right now. I did port a lot
of your adhoc tests to the manualtests project. And added quite a few more
new tests. The implementation was not working correctly for quite a few
things. So while I addressed some new issues,there is still a lot more to
do. It's entirely possible that I broke something that did not have a test
yet. Unless we focus more on test coverage, it will be easy to break things
as other things get fixed, particularly with something like XML, which is
reasonably complex. With inadequate test coverage, it can even be possible
to start relying on an implementation that does not work as it should.
Yishay: can you please give me a simple test case for the XML issue you are
seeing? I will look into it today.





On Thu, Jun 20, 2019 at 8:33 AM Harbs  wrote:

> The code has /* implicit cast */ and we do not have the
> complex-implicit-coresions set.
>
> FYI, XML is also broken due to empty nodes which did not used to be there,
> but I’ll let Yishay comment on the details.
>
> > On Jun 19, 2019, at 11:29 PM, Greg Dove  wrote:
> >
> > Hi Yishay,
> >
> > If there's a problem with this I will address it asap.
> > The setting was not working correctly before. I think it is now, so that
> > may have affected the output, but perhaps there are some test cases I did
> > not cover.
> >
> > skipAsCoercions only relates to explicit coercions, and should not have
> an
> > effect on the implicit coercions
> >
> > (But it does make me wonder if I have implemented the new config level
> > option correctly, maybe it should be added as one of the
> > -js-output-optimization options instead of being another top level
> option.
> > I can revisit this in another thread.)
> >
> > For now, the equivalent is
> > false
> >
> > or
> > -js-complex-implicit-coercions=false
> >
> > Do you have either of those set? If so then you should not see the
> implicit
> > coercions unless they are toggled on locally and therefore it is an error
> >
> > Can you please also use 'find in files' with your js-debug output,
> > searching for the text:
> > /* implicit cast */
> > and inspect the site of the runtime error?
> >
> > Is it generating the right cast on the right for the expected type on the
> > left if it is assignment?
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Jun 20, 2019 at 2:00 AM Yishay Weiss 
> wrote:
> >
> >> After updating the compiler we’re getting a runtime type coercion
> failure
> >> which didn’t exist before.
> >>
> >> A quick question: should ‘skipAsCoercions’ suppress implicit casts?
> Could
> >> the latest commit [1] have changed that?
> >>
> >> [1]
> >>
> https://github.com/apache/royale-compiler/commit/73caf20e03b72bb9e1717f2339c14cb79c6082b9
> >>
> >> Thanks.
> >>
>
>


Re: Implicit casts and skipAsCercions

2019-06-19 Thread Greg Dove
Hi Yishay,

If there's a problem with this I will address it asap.
The setting was not working correctly before. I think it is now, so that
may have affected the output, but perhaps there are some test cases I did
not cover.

skipAsCoercions only relates to explicit coercions, and should not have an
effect on the implicit coercions

(But it does make me wonder if I have implemented the new config level
option correctly, maybe it should be added as one of the
-js-output-optimization options instead of being another top level option.
I can revisit this in another thread.)

For now, the equivalent is
false

or
-js-complex-implicit-coercions=false

Do you have either of those set? If so then you should not see the implicit
coercions unless they are toggled on locally and therefore it is an error

Can you please also use 'find in files' with your js-debug output,
searching for the text:
/* implicit cast */
and inspect the site of the runtime error?

Is it generating the right cast on the right for the expected type on the
left if it is assignment?







On Thu, Jun 20, 2019 at 2:00 AM Yishay Weiss  wrote:

> After updating the compiler we’re getting a runtime type coercion failure
> which didn’t exist before.
>
> A quick question: should ‘skipAsCoercions’ suppress implicit casts? Could
> the latest commit [1] have changed that?
>
> [1]
> https://github.com/apache/royale-compiler/commit/73caf20e03b72bb9e1717f2339c14cb79c6082b9
>
> Thanks.
>


Re: Suggestion to request Royale addition to Facebook's 'flash migration recommendations'

2019-06-18 Thread Greg Dove
"Maybe the person who contacted you could help with that?"

Hi Alex,
To clarify, I did not get contacted by a 'person' - it was a facebook
broadcast email to all facebook developers. Or perhaps it might have been
filtered to target only those who were associated with flash deployments in
the past (I have worked on some of the Flex apps I referred to earlier,
although my main focus at the time was more on the mobile skus instead of
the web ones). The Flex app on web was using ExternalInterface and the FB
javascript sdk for integration with their platform, so I think that part
should be straightforward/easier with Royale.

I expect it might be easy enough to provide a minimal/basic facebook sdk
integration example, in the same way that it is possible for other
javascript sdks. That would be not exciting in itself, but would be
reassuring perhaps. I could look into this myself, but I am unlikely to get
there before sometime next month.
For now, I do think it's appropriate to request inclusion on the page as a
'flash to html5' migration technology. Hopefully Carlos's request will
result in someone at FB looking into that.

Beyond that, in terms of 'migrating' something substantial as an example, I
don't think that is realistic unless someone actually goes ahead and does a
real migration project and shares their experience.
Of course, I also reached out to my former client and recommended Royale,
but I am currently not aware that they have any plans to migrate those
specific apps to html5 via any route.
It might be easy to assume that these things don't have same levels of
complexity as a regular business-oriented Flex app, but that was definitely
not the case for the ones I worked on, so the migration task is on the same
scale.
There also tends to be a bigger focus on assets: animations, sounds along
with very customized re-skinning (so although it's a bit of a cliche: 'you
would never assume it was built in Flex by looking at it'). But I assume
some of the javascript libs mentioned on that page could help out there,
even more so if there were externs available for Royale. I expect there
would still be a reasonable amount of new work in a port, but it should be
concentrated more in the view stuff, just like with business apps.

Greg


On Wed, Jun 19, 2019 at 4:00 AM Alex Harui  wrote:

> Greg,
>
> Thanks for letting the rest of the community know about this.  It would be
> nice to find a volunteer to actual migrate something so we have proof, even
> if it is a getting started example for how to use Flex in FB.  Maybe the
> person who contacted you could help with that?
>
> -Alex
>
> On 6/18/19, 8:53 AM, "Carlos Rovira"  wrote:
>
> Thanks Greg,
>
> I tried to contact them via the pod bottom left to enter suggestions. I
> insert this message:
>
> "Hi, about Flash to HTML technologies another one very nice to
> consider is
> Apache Royale:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Froyale.apache.org%2Fdata=02%7C01%7Caharui%40adobe.com%7C0f9cc11ff5e34044687f08d6f4051328%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63696465357844sdata=w%2F1NheWybGepj3CX0UGtyIz6hw7XD%2FQ9hHJwESspN0U%3Dreserved=0
> Could you consider to include it?"
>
> El mar., 18 jun. 2019 a las 3:34, Greg Dove ()
> escribió:
>
> > fyi I got a ping today from Facebook today about flash migrations to
> html5.
> >
> > If anyone knows how to contact them internally to request that they
> update
> > their options, this page [1] could do with a Royale mention, I
> believe. In
> > case you're wondering, yes, I know of cases where Flex was used in
> the past
> > for Facebook games... but even if it is not simply for porting old
> Flex
> > apps, I think the possible use of some js externs for a game engine
> could
> > make Royale a good option for new facebook projects... Anyhow I'm
> just
> > sharing this in case someone knows how to influence updates to their
> > developer info page and we can get a Royale mention...
> >
> > 1.
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelopers.facebook.com%2Fdocs%2Fgames%2Fgamesonfacebook%2Fwebtechdata=02%7C01%7Caharui%40adobe.com%7C0f9cc11ff5e34044687f08d6f4051328%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63696465362837sdata=U3N1kNt%2BROkY2tyrbDE9PpBlNngysAzYIBlslMXlo54%3Dreserved=0
> >
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C0f9cc11ff5e34044687f08d6f4051328%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63696465362837sdata=PSddAniAXv8OMVz2rixdtWG%2BZ6bZNeRDLadSLN8Svq4%3Dreserved=0
>
>
>


Suggestion to request Royale addition to Facebook's 'flash migration recommendations'

2019-06-17 Thread Greg Dove
fyi I got a ping today from Facebook today about flash migrations to html5.

If anyone knows how to contact them internally to request that they update
their options, this page [1] could do with a Royale mention, I believe. In
case you're wondering, yes, I know of cases where Flex was used in the past
for Facebook games... but even if it is not simply for porting old Flex
apps, I think the possible use of some js externs for a game engine could
make Royale a good option for new facebook projects... Anyhow I'm just
sharing this in case someone knows how to influence updates to their
developer info page and we can get a Royale mention...

1. https://developers.facebook.com/docs/games/gamesonfacebook/webtech


Re: [royale-asjs] 04/04: suppress implicit coercions because we cheat and use JSON objects instead of actual instances

2019-06-17 Thread Greg Dove
Hi Alex,

My apologies, but I may have messed this directive up a bit with the
earlier change from 'negative' to 'positive' semantics in the config
settings. I just added compiler tests for the output variations and
adjusted the logic for these checks to make them pass, so now the following
should work properly:

@royalesuppresscompleximplicitcoercion false
means 'don't suppress the coercion' (the coercion is on by default). This
would be unusual to use, but could be to used to locally override a
compilation config setting which suppresses it everywhere, so that it is
still output inside a particular method, for example. It sounds like it is
the opposite of the intent in your commit comment, but I guess you tried
this because the boolean toggles were not working correctly/intuitively.


if you want it suppressed locally, you should be able to use 'true' or use
it with no additional specifier, otherwise you can also use it in a similar
way to @royaleignorecoercion with specific types. This should work
correctly now after my fix.

for example:
 var classData:ASDocClass = masterData["filterData"][className];

you can use:
@royalesuppresscompleximplicitcoercion ASDocClass

but the following should (after the fix) suppress all implicit coercions in
the annotated method scope  :
@royalesuppresscompleximplicitcoercion
@royalesuppresscompleximplicitcoercion true

If you want it off completely for the current build, it is best done via
the config setting for the compilation, and then you need no annotations
anywhere.
I did provide some information about the config settings recently in a
post, but I'm going to write this stuff up this week and add it to the
docs. Sorry I should have done that already. I will get it done this week.

Greg


On Tue, Jun 18, 2019 at 6:02 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> aharui pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>
> commit a09ea1e3a835226ea880ca2bfa7161e11ece22a5
> Author: Alex Harui 
> AuthorDate: Mon Jun 17 11:01:52 2019 -0700
>
> suppress implicit coercions because we cheat and use JSON objects
> instead of actual instances
> ---
>  examples/royale/ASDoc/src/main/royale/models/ASDocModel.as | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/examples/royale/ASDoc/src/main/royale/models/ASDocModel.as
> b/examples/royale/ASDoc/src/main/royale/models/ASDocModel.as
> index bb530d7..493b46e 100644
> --- a/examples/royale/ASDoc/src/main/royale/models/ASDocModel.as
> +++ b/examples/royale/ASDoc/src/main/royale/models/ASDocModel.as
> @@ -493,6 +493,9 @@ package models
>  }
>  }
>
> +/**
> + * @royalesuppresscompleximplicitcoercion false
> + */
>  private function addIfNeededAndMakeAttributes(arr:Array,
> data:ASDocClassEvents):void
>  {
> var n:int = arr.length;
> @@ -528,6 +531,9 @@ package models
> arr.push(data);
>  }
>
> +/**
> + * @royalesuppresscompleximplicitcoercion false
> + */
> private function addAttributes(dest:ASDocClassEvents,
> src:ASDocClassEvents):void
> {
> if (!src.tags) return;
> @@ -884,6 +890,9 @@ package models
>  filterPackageList();
>  }
>
> +/**
> + * @royalesuppresscompleximplicitcoercion false
> + */
>  public function filterByTags(className:String):Boolean
>  {
>  var classData:ASDocClass =
> masterData["filterData"][className];
>
>


Re: Problem with Vectors

2019-06-12 Thread Greg Dove
Alex, javascript TypeArrays are fixed length at construction, so I really
don't think that can work in general case for drop-in substitution of
numeric Vector without some sort of wrapper class that supports swapping
things out.
I really think that dedicated 'fast' numeric collection types will likely
need their own cross-target classes.
It would work for a Vector that has a fixed = true constructor arg and then
never changes its 'fixed' status (and therefore never changes its length
also) and also only uses index access and assignments (no push, pop etc),
but it's a pretty restrictive scenario. I did look at this already.
It might also be possible to map default Vector numeric types to 'faster'
versions for the 3 types, as an opt-in to the default implementation's
approach. I do plan to work on/investigate this later this month, because I
am keen to see performance-oriented options here too. But I was thinking
they would likely be separate, dedicated classes.


On Thu, Jun 13, 2019 at 11:27 AM Alex Harui 
wrote:

> FWIW, I would expect any syntax changes to be a significant amount of work
> especially where the BURM does the semantic checks.  New BURM patterns are
> probably required.  Or maybe it is time to get the BURM out of the
> semantic-check business for JS (and maybe SWF) output and figure out how to
> do the semantic checks from the JS AST walk.
>
> Did you out finding a way to indicate that some Vector. should be
> implemented as a TypedArray?
>
> -Alex
>
> On 6/12/19, 3:18 PM, "Josh Tynjala"  wrote:
>
> I plan to start out by supporting Array. syntax, similar to
> Vector.. Like you said, there are advantages to using the same syntax
> for all typed collections.
>
> Later, I'll see if I can figure out how to add T[] syntax as an
> alternative, since Harbs seems to like that better.
>
> - Josh
>
> On 2019/06/12 20:14:50, Greg Dove  wrote:
> > Hey Josh,
> >
> > Thanks for looking into that, I figured it could be a bit tricky!
> Good luck
> > with it.
> > I think you and Harbs were maybe leaning to towards Number[] and
> String[]
> > type declarations. I don't mind either way, but perhaps the Array.
> with
> > angle brackets approach that is used for Vectors could make it
> easier to
> > swap between typed Array and Vector if people consider refactoring
> (and
> > whatever IDE they're using won't support more automated changes).
> OTOH, the
> > first approach is definitely easier to type. You probably already
> thought
> > those things through though, I guess.
> >
> > If you end up with a remote branch for your work on this at some
> point and
> > want someone to help with testing or anything like that, I'm in,
> just let
> > me know.
> >
> >
> > On Thu, Jun 13, 2019 at 2:26 AM Josh Tynjala 
> wrote:
> >
> > > > I think your other proposal with Josh for the typed Arrays and
> their
> > > greater compile-time safety will be a better fit for many cases as
> well, so
> > > I hope that happens.
> > >
> > > I started working on typed arrays this week. It may be a while
> before I
> > > can merge, though. It's definitely more complex than private
> constructors
> > > and abstract classes.
> > >
> > > - Josh
> > >
> > > On 2019/06/12 04:21:18, Greg Dove  wrote:
> > > > Hi Harbs - just in reply to your specific questions:
> > > > As I mentioned elsewhere it is easy to have full speed index
> access and
> > > > also full speed pop() and unshift() methods
> > > > If you switch off the first 3 settings I outlined in the post
> titled
> > > > 'Language/Reflection improvements details' you will have that.
> Those
> > > > settings are switchable locally with doc directives as well. I
> will do a
> > > > full write-up this coming weekend for docs. Hopefully I can
> harvest a lot
> > > > of what I already wrote elsewhere for that.
> > > > BTW I switched TLF to use the legacy Vector-as-Array approach by
> > > default, I
> > > > am not sure what you want there, you could undo that if you
> prefer.
> > > >
> > > > Beyond the above mentioned approaches for (mainly index level)
> > > > optimization, I have a preference for two more approaches, but
> I'd rather
> > > > limit the overall number of options to be what people definitely
> need
> > > > instead of adding too many option

Re: Problem with Vectors

2019-06-12 Thread Greg Dove
Hey Josh,

Thanks for looking into that, I figured it could be a bit tricky! Good luck
with it.
I think you and Harbs were maybe leaning to towards Number[] and String[]
type declarations. I don't mind either way, but perhaps the Array. with
angle brackets approach that is used for Vectors could make it easier to
swap between typed Array and Vector if people consider refactoring (and
whatever IDE they're using won't support more automated changes). OTOH, the
first approach is definitely easier to type. You probably already thought
those things through though, I guess.

If you end up with a remote branch for your work on this at some point and
want someone to help with testing or anything like that, I'm in, just let
me know.


On Thu, Jun 13, 2019 at 2:26 AM Josh Tynjala  wrote:

> > I think your other proposal with Josh for the typed Arrays and their
> greater compile-time safety will be a better fit for many cases as well, so
> I hope that happens.
>
> I started working on typed arrays this week. It may be a while before I
> can merge, though. It's definitely more complex than private constructors
> and abstract classes.
>
> - Josh
>
> On 2019/06/12 04:21:18, Greg Dove  wrote:
> > Hi Harbs - just in reply to your specific questions:
> > As I mentioned elsewhere it is easy to have full speed index access and
> > also full speed pop() and unshift() methods
> > If you switch off the first 3 settings I outlined in the post titled
> > 'Language/Reflection improvements details' you will have that. Those
> > settings are switchable locally with doc directives as well. I will do a
> > full write-up this coming weekend for docs. Hopefully I can harvest a lot
> > of what I already wrote elsewhere for that.
> > BTW I switched TLF to use the legacy Vector-as-Array approach by
> default, I
> > am not sure what you want there, you could undo that if you prefer.
> >
> > Beyond the above mentioned approaches for (mainly index level)
> > optimization, I have a preference for two more approaches, but I'd rather
> > limit the overall number of options to be what people definitely need
> > instead of adding too many options (which could create confusion). I
> think
> > your other proposal with Josh for the typed Arrays and their greater
> > compile-time safety will be a better fit for many cases as well, so I
> hope
> > that happens. If I have time to help out in any way with that, I would be
> > happy to do so as well, because it sounds like something I would use a
> lot.
> > Anyhow, I do want to support more optimizations with this implementation.
> > Can you say what your main concerns would be for optimization? Is it
> mainly
> > for 'push'  (and unshift) ? Those would be mine...
> >
> > I would personally like to see the following:
> >
> > 1. A global optimization setting that affects all instances in all code
> > including pre-built library code. This would avoid certain runtime checks
> > and would also result in a lighter implementation. This is something the
> > final application developer decides, not anything dictated by a library
> > developer (but a library developer could advertise their public swc as
> > being compatible/safe with this type of optimization). This approach
> could
> > include perhaps 2 levels: one to remove any code paths related to fixed
> > length Vectors (which I think you said you never used) for example. Then
> > another possibly removing all element level type-checking as another
> level.
> > Adding this should not be too difficult I think and would be determined
> via
> > a goog define (which might be driven by a compiler setting, I did not
> look
> > at how easy this is yet). The thing I like about this approach is that it
> > is not 'baked-in' to any instance and the application developer makes the
> > ultimate decision and owns the associated risk (as opposed to having it
> > imposed on them by a library developer, for example). I think the removal
> > of support for 'fixed' Vectors could probably be made to generate
> > (debug-only) errors if there is code that runs that sets fixed to true on
> > any Vector instance  - to provide some reassurance of no side effects
> when
> > choosing this option.
> >
> > 2. Compilation scoped optimizations.
> > By 'compilation-scoped' I mean configurable in the same way as the
> > vector-index-check suppression: An over-arching config setting for the
> > current compilation that can be overridden locally with doc comment
> > directives. This affects code sites (or all current compilation scope if
> > set in the config) and not specific instances. I would hope this might be
> >

Re: Problem with Vectors

2019-06-11 Thread Greg Dove
Hi Harbs - just in reply to your specific questions:
As I mentioned elsewhere it is easy to have full speed index access and
also full speed pop() and unshift() methods
If you switch off the first 3 settings I outlined in the post titled
'Language/Reflection improvements details' you will have that. Those
settings are switchable locally with doc directives as well. I will do a
full write-up this coming weekend for docs. Hopefully I can harvest a lot
of what I already wrote elsewhere for that.
BTW I switched TLF to use the legacy Vector-as-Array approach by default, I
am not sure what you want there, you could undo that if you prefer.

Beyond the above mentioned approaches for (mainly index level)
optimization, I have a preference for two more approaches, but I'd rather
limit the overall number of options to be what people definitely need
instead of adding too many options (which could create confusion). I think
your other proposal with Josh for the typed Arrays and their greater
compile-time safety will be a better fit for many cases as well, so I hope
that happens. If I have time to help out in any way with that, I would be
happy to do so as well, because it sounds like something I would use a lot.
Anyhow, I do want to support more optimizations with this implementation.
Can you say what your main concerns would be for optimization? Is it mainly
for 'push'  (and unshift) ? Those would be mine...

I would personally like to see the following:

1. A global optimization setting that affects all instances in all code
including pre-built library code. This would avoid certain runtime checks
and would also result in a lighter implementation. This is something the
final application developer decides, not anything dictated by a library
developer (but a library developer could advertise their public swc as
being compatible/safe with this type of optimization). This approach could
include perhaps 2 levels: one to remove any code paths related to fixed
length Vectors (which I think you said you never used) for example. Then
another possibly removing all element level type-checking as another level.
Adding this should not be too difficult I think and would be determined via
a goog define (which might be driven by a compiler setting, I did not look
at how easy this is yet). The thing I like about this approach is that it
is not 'baked-in' to any instance and the application developer makes the
ultimate decision and owns the associated risk (as opposed to having it
imposed on them by a library developer, for example). I think the removal
of support for 'fixed' Vectors could probably be made to generate
(debug-only) errors if there is code that runs that sets fixed to true on
any Vector instance  - to provide some reassurance of no side effects when
choosing this option.

2. Compilation scoped optimizations.
By 'compilation-scoped' I mean configurable in the same way as the
vector-index-check suppression: An over-arching config setting for the
current compilation that can be overridden locally with doc comment
directives. This affects code sites (or all current compilation scope if
set in the config) and not specific instances. I would hope this might be
the only other 'Vector' specific config option like this, simply to avoid
confusion with too many options.
So I personally think the important things here are the push and unshift
methods, because they're the ones that are also most often used in loops
when index level access or assignment is not being used (in the loop). But
I'm keen to hear more about what people want in case it's different to how
I think. And I will add support for what best represents the needs of the
community. While index level access is best for large loops (just as it is
for 'Array'), push could be preferred in small loops because it does not
require a 'get' for length to establish the upper bound of the loop or the
next acceptable index to set (for non-fixed Vectors). The optimization for
push in this case would be to bypass runtime typechecking and just do a
regular Array.push into the underlying Vector representation, which is
still actually an Array in terms of how javascript sees it. Adding this
option is easy also, but rather than just forging ahead with it, I am keen
to get input from others first.

I consider that specific instance level optimizations (in general) are
'dangerous' because even if the code is 'safe' when it is originally
written, subsequent changes to the overall codebase (possibly by different
developers) can mean that an instance ends up elsewhere in code where it
behaves differently from other instances of the same type.  Code-site
optimizations could also create an unusual internal state for an instance,
but most often they should not, because the code site where the
optimization is used should be validated in terms of the optimization by
its original developer (e.g. no runtime type checking at a particular usage
site because it is never needed in the context of that 

Re: 0.9.6 Release

2019-06-11 Thread Greg Dove
Thanks for clarifying Piotr. That one at least worked it seems.
I saw the problem elsewhere and first time it was because the compiler
build had required changes and did not complete before the framework.
The others have some issues, but I don't think it is related to my latest
changes , because it seems to be the same issue as previous fails. I will
try to figure those out tomorrow some time if I can.

On Tue, Jun 11, 2019 at 5:08 PM Piotr Zarzycki 
wrote:

> Greg,
>
> I was thinking about ant build on Jenkins [1]. I didn't check Maven build
> in a while.
>
> [1]
>
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/changes
>
> Thanks,
> Piotr
>
>
> On Tue, Jun 11, 2019, 6:48 AM Greg Dove  wrote:
>
> > Piotr, I hope I addressed the issue, but waiting to see...
> > It looks like it has been unstable for last 7 days , am I reading that
> > right? https://builds.apache.org/job/Royale-asjs/
> >
> >
> > On Tue, Jun 11, 2019 at 4:30 PM Greg Dove  wrote:
> >
> > > Working on it!
> > >
> > >
> > > On Tue, Jun 11, 2019 at 4:29 PM Piotr Zarzycki <
> > piotrzarzyck...@gmail.com>
> > > wrote:
> > >
> > >> Hi Greg,
> > >>
> > >> After your merge the goal should be that build on Jenkins is working
> > fine.
> > >> Please make sure that is happen.
> > >>
> > >> Thanks,
> > >> Piotr
> > >>
> > >> On Tue, Jun 11, 2019, 5:32 AM Greg Dove  wrote:
> > >>
> > >> > I will stick with the plan of single commit, I think it should be
> > easier
> > >> > for you if there are any conflicts.
> > >> > Last build testing is running now in local develop. I will push
> after
> > >> > that...
> > >> >
> > >> > On Tue, Jun 11, 2019 at 3:15 PM Greg Dove 
> > wrote:
> > >> >
> > >> > >
> > >> > > Thanks Alex, I was planning to merge this as a single squashed
> > commit,
> > >> > > because it isolates all the changes to a single commit (but this
> > will
> > >> > mean
> > >> > > there are many changes in one hit).
> > >> > > Do you have a preference in terms of how easy it will make things
> > for
> > >> > you?
> > >> > >
> > >> > >
> > >> > > On Tue, Jun 11, 2019 at 3:07 PM Alex Harui
>  > >
> > >> > > wrote:
> > >> > >
> > >> > >> OK, I will wait to see your commit emails.  I will do some other
> > >> things
> > >> > >> like the wiki doc.
> > >> > >>
> > >> > >> -Alex
> > >> > >>
> > >> > >> On 6/10/19, 8:06 PM, "Greg Dove"  wrote:
> > >> > >>
> > >> > >> Hi Alex, I guess you might be back on Royale about now. Just
> a
> > >> heads
> > >> > >> up: I
> > >> > >> am about 20-30 mins max from merging in what I have. Hope
> > that's
> > >> > still
> > >> > >> ok... please let me know if not.
> > >> > >> Thanks,
> > >> > >> -Greg
> > >> > >>
> > >> > >>
> > >> > >> On Tue, Jun 11, 2019 at 7:51 AM Greg Dove <
> greg.d...@gmail.com
> > >
> > >> > >> wrote:
> > >> > >>
> > >> > >> >
> > >> > >> > Thanks Alex - I'll try to hit the window, much appreciated!
> > >> > >> >
> > >> > >> >
> > >> > >> > On Tue, Jun 11, 2019 at 6:57 AM Alex Harui
> > >> >  > >> > >> >
> > >> > >> > wrote:
> > >> > >> >
> > >> > >> >> Hi Greg,
> > >> > >> >>
> > >> > >> >> It turns out I have a "split shift" today.  I'm stopping
> > work
> > >> for
> > >> > >> the
> > >> > >> >> next 7 or 8 hours then will get around to the merge.  So
> if
> > >> you
> > >> > >> can get
> > >> > >> >> your changes merged in that amount of time, then I will
> wait
> > >>

Language/Reflection improvements details

2019-06-11 Thread Greg Dove
Hi all,

Just a quick summary of things merged in via recent commit.  See below for
"How do I get things 'how they were' ?" if you want to switch off any of
the new stuff.

More reliable actionscript support.
The new settings provide greater compatibility. But they can also be tuned
out (Hello world is a good example, and it is smaller now in gzipped format
for release build, than it was before)
-More things will 'just work' when porting from older actionscript libs.
Vector behaviour is virtually identical to swf, other types of implicit
type coercions are generated by default (but avoidable by config), and
certain uses of int, uint and Class are more reliable and avoid compiler or
runtime errors compared to before.
Reflection now has PAYG/opt-in support for including top level as3 types
(Array, Number, int, Vector etc). These roughly match the results you see
with reflection in swf (actually reflection info for these swf items quite
light). This is via a plugin style setup that is only included in release
build if you use it. See here:
https://github.com/apache/royale-asjs/blob/c6379b85d8aa9d164d49b09402a23f30cb4aee3a/frameworks/projects/Reflection/src/main/royale/org/apache/royale/reflection/ExtraData.as#L127
This same approach could be used with externs reflection data if it could
be generated in a similar format, e.g. to provide possible reflection pack
support for sets of javascript native classes.
I plan to use the same ExtraData class to add support for Vector to
AMFBinaryData, Vector is a low level type that has its own serialization
rules. In this way there will also be no hard dependency on vector support
in AMFBinaryData and it is therefore opt-in/PAYG via the ExtraData class.

How do I get things 'how they were' ?
maven (via additionalCompilerOptions):
-js-complex-implicit-coercions=false;
-js-vector-index-checks=false;
-js-resolve-uncertain=false;
-js-vector-emulation-class=Array;
(note that you should also now be able to have these on separate lines in
the pom - I find this much easier to read)

ant:
in compile-js-config.xml example
[js-complex-implicit-coercions]false[/js-complex-implicit-coercions]
[js-resolve-uncertain]false[/js-resolve-uncertain]
[js-vector-index-checks]false[/js-vector-index-checks]
[js-vector-emulation-class]Array[/js-vector-emulation-class]
(angle brackets are substituted here with square brackets above in case
they mess with some email clients)

The first 3 options above have doc comment directives (@royalesuppress... )
so they can be tuned off or on inside method definitions also.

Fixes
Vector-as-Array emulation now supports insertAt/removeAt (same as Array)
vectorEmulationClass receives the fully qualified name as the string
parameter for the elementType


Other
-Added a lot of compiler tests for the vector emulation options and default
vector implementation
-RoyaleUnit: I ported a start of the manualtest unit tests to RoyaleUnit.
@josh... these are actually language tests, but I thought they could not
run in the Language project because it does not have all dependencies to
run the tests themselves, perhaps I am wrong about that? I put them in Core
for now, and they do run correctly in both swf and JS. But please tell me
what you prefer for these (maybe they do need to go in Language...). Also I
made some small changes in the js ant scripts for tests to correctly clean
the test folder.
-Added more reflection unit tests (manualtests)
-Started to collate unit tests for XML and updated code to fix some
observed issues (compiler and framework).
-Hello world is approx 600 bytes smaller after gzip compression than it was
before

I might have forgotten some things, I will add extra info tomorrow if I
recall more. Please ask questions if you have them.


Re: 0.9.6 Release

2019-06-10 Thread Greg Dove
Piotr, I hope I addressed the issue, but waiting to see...
It looks like it has been unstable for last 7 days , am I reading that
right? https://builds.apache.org/job/Royale-asjs/


On Tue, Jun 11, 2019 at 4:30 PM Greg Dove  wrote:

> Working on it!
>
>
> On Tue, Jun 11, 2019 at 4:29 PM Piotr Zarzycki 
> wrote:
>
>> Hi Greg,
>>
>> After your merge the goal should be that build on Jenkins is working fine.
>> Please make sure that is happen.
>>
>> Thanks,
>> Piotr
>>
>> On Tue, Jun 11, 2019, 5:32 AM Greg Dove  wrote:
>>
>> > I will stick with the plan of single commit, I think it should be easier
>> > for you if there are any conflicts.
>> > Last build testing is running now in local develop. I will push after
>> > that...
>> >
>> > On Tue, Jun 11, 2019 at 3:15 PM Greg Dove  wrote:
>> >
>> > >
>> > > Thanks Alex, I was planning to merge this as a single squashed commit,
>> > > because it isolates all the changes to a single commit (but this will
>> > mean
>> > > there are many changes in one hit).
>> > > Do you have a preference in terms of how easy it will make things for
>> > you?
>> > >
>> > >
>> > > On Tue, Jun 11, 2019 at 3:07 PM Alex Harui 
>> > > wrote:
>> > >
>> > >> OK, I will wait to see your commit emails.  I will do some other
>> things
>> > >> like the wiki doc.
>> > >>
>> > >> -Alex
>> > >>
>> > >> On 6/10/19, 8:06 PM, "Greg Dove"  wrote:
>> > >>
>> > >> Hi Alex, I guess you might be back on Royale about now. Just a
>> heads
>> > >> up: I
>> > >> am about 20-30 mins max from merging in what I have. Hope that's
>> > still
>> > >> ok... please let me know if not.
>> > >> Thanks,
>> > >> -Greg
>> > >>
>> > >>
>> > >> On Tue, Jun 11, 2019 at 7:51 AM Greg Dove 
>> > >> wrote:
>> > >>
>> > >> >
>> > >> > Thanks Alex - I'll try to hit the window, much appreciated!
>> > >> >
>> > >> >
>> > >> > On Tue, Jun 11, 2019 at 6:57 AM Alex Harui
>> > > > >> >
>> > >> > wrote:
>> > >> >
>> > >> >> Hi Greg,
>> > >> >>
>> > >> >> It turns out I have a "split shift" today.  I'm stopping work
>> for
>> > >> the
>> > >> >> next 7 or 8 hours then will get around to the merge.  So if
>> you
>> > >> can get
>> > >> >> your changes merged in that amount of time, then I will wait
>> for
>> > >> you and
>> > >> >> deal with any merge conflicts (there are almost certain to be
>> > >> some).
>> > >> >>
>> > >> >> -Alex
>> > >> >>
>> > >> >> On 6/10/19, 11:46 AM, "Greg Dove" 
>> wrote:
>> > >> >>
>> > >> >> Alex, slightly OT, but in terms of coordination: fyi I am
>> > also
>> > >> very
>> > >> >> close
>> > >> >> to merging the language improvements branch into develop.
>> As
>> > I
>> > >> already
>> > >> >> mentioned elsewhere, I was hoping to do that a couple of
>> days
>> > >> back,
>> > >> >> but
>> > >> >> some recent things also took me a little longer than
>> expected
>> > >> (I have
>> > >> >> additional local changes/fixes not yet in remote branch)
>> . I
>> > >> was
>> > >> >> planning
>> > >> >> to merge that today also.
>> > >> >>
>> > >> >> However, I will wait until after your merge, so I'm hoping
>> > you
>> > >> can get
>> > >> >> yours in today (if not, I will wait). I will probably put
>> > mine
>> > >> in as a
>> > >> >> squashed commit after yours.
>> > >> >>
>> > >

Re: 0.9.6 Release

2019-06-10 Thread Greg Dove
Working on it!


On Tue, Jun 11, 2019 at 4:29 PM Piotr Zarzycki 
wrote:

> Hi Greg,
>
> After your merge the goal should be that build on Jenkins is working fine.
> Please make sure that is happen.
>
> Thanks,
> Piotr
>
> On Tue, Jun 11, 2019, 5:32 AM Greg Dove  wrote:
>
> > I will stick with the plan of single commit, I think it should be easier
> > for you if there are any conflicts.
> > Last build testing is running now in local develop. I will push after
> > that...
> >
> > On Tue, Jun 11, 2019 at 3:15 PM Greg Dove  wrote:
> >
> > >
> > > Thanks Alex, I was planning to merge this as a single squashed commit,
> > > because it isolates all the changes to a single commit (but this will
> > mean
> > > there are many changes in one hit).
> > > Do you have a preference in terms of how easy it will make things for
> > you?
> > >
> > >
> > > On Tue, Jun 11, 2019 at 3:07 PM Alex Harui 
> > > wrote:
> > >
> > >> OK, I will wait to see your commit emails.  I will do some other
> things
> > >> like the wiki doc.
> > >>
> > >> -Alex
> > >>
> > >> On 6/10/19, 8:06 PM, "Greg Dove"  wrote:
> > >>
> > >> Hi Alex, I guess you might be back on Royale about now. Just a
> heads
> > >> up: I
> > >> am about 20-30 mins max from merging in what I have. Hope that's
> > still
> > >> ok... please let me know if not.
> > >> Thanks,
> > >> -Greg
> > >>
> > >>
> > >> On Tue, Jun 11, 2019 at 7:51 AM Greg Dove 
> > >> wrote:
> > >>
> > >> >
> > >> > Thanks Alex - I'll try to hit the window, much appreciated!
> > >> >
> > >> >
> > >> > On Tue, Jun 11, 2019 at 6:57 AM Alex Harui
> >  > >> >
> > >> > wrote:
> > >> >
> > >> >> Hi Greg,
> > >> >>
> > >> >> It turns out I have a "split shift" today.  I'm stopping work
> for
> > >> the
> > >> >> next 7 or 8 hours then will get around to the merge.  So if you
> > >> can get
> > >> >> your changes merged in that amount of time, then I will wait
> for
> > >> you and
> > >> >> deal with any merge conflicts (there are almost certain to be
> > >> some).
> > >> >>
> > >> >> -Alex
> > >> >>
> > >> >> On 6/10/19, 11:46 AM, "Greg Dove"  wrote:
> > >> >>
> > >> >> Alex, slightly OT, but in terms of coordination: fyi I am
> > also
> > >> very
> > >> >> close
> > >> >> to merging the language improvements branch into develop.
> As
> > I
> > >> already
> > >> >> mentioned elsewhere, I was hoping to do that a couple of
> days
> > >> back,
> > >> >> but
> > >> >> some recent things also took me a little longer than
> expected
> > >> (I have
> > >> >> additional local changes/fixes not yet in remote branch) .
> I
> > >> was
> > >> >> planning
> > >> >> to merge that today also.
> > >> >>
> > >> >> However, I will wait until after your merge, so I'm hoping
> > you
> > >> can get
> > >> >> yours in today (if not, I will wait). I will probably put
> > mine
> > >> in as a
> > >> >> squashed commit after yours.
> > >> >>
> > >> >>
> > >> >> On Tue, Jun 11, 2019 at 6:05 AM Piotr Zarzycki <
> > >> >> piotrzarzyck...@gmail.com>
> > >> >> wrote:
> > >> >>
> > >> >> > Hi Alex,
> > >> >> >
> > >> >> > Many thanks for that! I will try to be RM. I will have
> some
> > >> >> dedicated time
> > >> >> > for that. I will wait for your instruction and merge to
> > >> develop.
> > >> >> >
> > >> >> > Thanks,
> > >> >> > Pio

Re: 0.9.6 Release

2019-06-10 Thread Greg Dove
I will stick with the plan of single commit, I think it should be easier
for you if there are any conflicts.
Last build testing is running now in local develop. I will push after
that...

On Tue, Jun 11, 2019 at 3:15 PM Greg Dove  wrote:

>
> Thanks Alex, I was planning to merge this as a single squashed commit,
> because it isolates all the changes to a single commit (but this will mean
> there are many changes in one hit).
> Do you have a preference in terms of how easy it will make things for you?
>
>
> On Tue, Jun 11, 2019 at 3:07 PM Alex Harui 
> wrote:
>
>> OK, I will wait to see your commit emails.  I will do some other things
>> like the wiki doc.
>>
>> -Alex
>>
>> On 6/10/19, 8:06 PM, "Greg Dove"  wrote:
>>
>> Hi Alex, I guess you might be back on Royale about now. Just a heads
>> up: I
>> am about 20-30 mins max from merging in what I have. Hope that's still
>> ok... please let me know if not.
>> Thanks,
>> -Greg
>>
>>
>> On Tue, Jun 11, 2019 at 7:51 AM Greg Dove 
>> wrote:
>>
>> >
>> > Thanks Alex - I'll try to hit the window, much appreciated!
>> >
>> >
>> > On Tue, Jun 11, 2019 at 6:57 AM Alex Harui > >
>> > wrote:
>> >
>> >> Hi Greg,
>> >>
>> >> It turns out I have a "split shift" today.  I'm stopping work for
>> the
>> >> next 7 or 8 hours then will get around to the merge.  So if you
>> can get
>> >> your changes merged in that amount of time, then I will wait for
>> you and
>> >> deal with any merge conflicts (there are almost certain to be
>> some).
>> >>
>> >> -Alex
>> >>
>> >> On 6/10/19, 11:46 AM, "Greg Dove"  wrote:
>> >>
>> >> Alex, slightly OT, but in terms of coordination: fyi I am also
>> very
>> >> close
>> >> to merging the language improvements branch into develop. As I
>> already
>> >> mentioned elsewhere, I was hoping to do that a couple of days
>> back,
>> >> but
>> >> some recent things also took me a little longer than expected
>> (I have
>> >> additional local changes/fixes not yet in remote branch) . I
>> was
>> >> planning
>> >> to merge that today also.
>> >>
>> >> However, I will wait until after your merge, so I'm hoping you
>> can get
>> >> yours in today (if not, I will wait). I will probably put mine
>> in as a
>> >> squashed commit after yours.
>> >>
>> >>
>> >> On Tue, Jun 11, 2019 at 6:05 AM Piotr Zarzycki <
>> >> piotrzarzyck...@gmail.com>
>> >> wrote:
>> >>
>> >> > Hi Alex,
>> >> >
>> >> > Many thanks for that! I will try to be RM. I will have some
>> >> dedicated time
>> >> > for that. I will wait for your instruction and merge to
>> develop.
>> >> >
>> >> > Thanks,
>> >> > Piotr
>> >> >
>> >> >
>> >> > On Mon, Jun 10, 2019, 7:31 PM Alex Harui
>> 
>> >> wrote:
>> >> >
>> >> > > Well, that turned out to be much more time-consuming than I
>> >> expected, but
>> >> > > we can now create identical release artifacts on Mac and
>> Win.  I
>> >> am
>> >> > hopeful
>> >> > > this effort will pay off not only now in having other folks
>> >> generate
>> >> > > releases, but also in the future if signed binaries become
>> a
>> >> requirement.
>> >> > >
>> >> > > There continues to be a lot of distractions in my life
>> that can
>> >> cause
>> >> > > delays, but I hope to merge the release_practice branches
>> into
>> >> develop
>> >> > over
>> >> > > the next day or two and figure out where in the wiki to
>> document
>> >> the
>> >> > > release process.  So, now is the time for one or more
&

  1   2   3   >