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

2019-10-15 Thread Josh Tynjala
Thanks, Greg!

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Oct 14, 2019 at 5:08 PM Greg Dove  wrote:

> 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/Collect

Re: Broken royale-config in JS only build of released Apache Royale SDK 0.9.6

2019-10-09 Thread Josh Tynjala
You were probably using the JS-only version of 0.9.4. As I said, the
JS-only version does not require Ant or npm.

You're not missing any new requirements/dependencies that were added
between 0.9.4 and 0.9.6. *The JS-only version of 0.9.6 is simply broken.*
Something in the build went wrong, and we failed to discover it during the
release process. If I were to guess, it's probably because nightly builds
were always working correctly, and we didn't do enough manual testing of
the release candidate. Anyway, this is obviously a critical issue that we
need to get fixed ASAP.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Oct 9, 2019 at 3:21 PM Andrew Wetmore  wrote:

> I recently had a hard drive crash, so I have a new hard drive without many
> past artifacts, a virgin system. I was using 0.9.4 in Moonshine before the
> crash without, as far as I know, any Ant or npm magic. Have things changed
> significantly between that release and this one?
>
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> Virus-free.
> www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, Oct 9, 2019 at 6:40 PM Andrew Wetmore  wrote:
>
> > Instructions that require Ant or npm are not, in my humble opinion,
> > entry-level instructions. I should not have to be an SDK constructor in
> > order to use Royale to build the apps I want to build.
> >
> > The instructions need to be a TON clearer, and more obvious from the
> > typical entry points where a new user would encounter Royale. We should
> > possibly also add qualifiers to any statements that an IDE like Moonshine
> > supports Royale. It does not support Royale as we deliver it, but only
> > after it has been tweaked by processes that are obvious to those
> developing
> > Royale but not to the world at large.
> >
> > Sorry if I sound irked, but consider that my reaction may mirror that of
> > many who want to try Royale out but trip over the starting line.
> >
> > Andrew
> >
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> Virus-free.
> > www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > <#m_-6424551647352680386_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > On Wed, Oct 9, 2019 at 5:52 PM Josh Tynjala 
> > wrote:
> >
> >> The main royale-asjs README mentions the Adobe stuff as optional
> >> dependencies, but the instructions seem to be aimed at contributors:
> >>
> >>
> >>
> https://github.com/apache/royale-asjs#additional-prerequisites-for-swf-output
> >>
> >> What a non-contributor user is expected to do appears to be mentioned on
> >> this page (it requires running the InstallAdobeSDKs.xml Ant script):
> >>
> >> https://apache.github.io/royale-docs/get-started/download-royale
> >>
> >> I recall that if you install the npm version of Royale, it will ask to
> >> download the Adobe dependencies for you. That's probably the easiest way
> >> for a new user to get started.
> >>
> >> --
> >> Josh Tynjala
> >> Bowler Hat LLC <https://bowlerhat.dev>
> >>
> >>
> >> On Wed, Oct 9, 2019 at 1:44 PM Andrew Wetmore 
> >> wrote:
> >>
> >> > Thanks @Josh Tynjala  . Do we say that
> >> > anywhere in the instructions where a new user would run into it?
> >> >
> >> >
> >> > <
> >>
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> >> Virus-free.
> >> > www.avast.com
> >> > <
> >>
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >> >
> >> > <#m_-3106823410389824051_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >> >
> >> > On Wed, Oct 9, 2019 at 5:27 PM Josh Tynjala <
> joshtynj...@bowlerhat.dev>
> >> > wrote:
> >> >
> >> >> If you downloaded the js-swf binary distribution, you need to add the
> >> >> Adobe
> >> >> dependencies manually. We cannot distribute them.
> >> >>
> >> >> The playerglobal.swc in the js-only version is not the real one from
> >> >> Adobe.
>

Re: Broken royale-config in JS only build of released Apache Royale SDK 0.9.6

2019-10-09 Thread Josh Tynjala
Node/npm is pretty normal prerequisite for most JS development these days,
but I understand your point.

Ideally, we should be encouraging developers to start with the JS-only
version, which doesn't require any of those special dependencies (other
than Java, which is necessary to run the compiler).

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Oct 9, 2019 at 2:41 PM Andrew Wetmore  wrote:

> Instructions that require Ant or npm are not, in my humble opinion,
> entry-level instructions. I should not have to be an SDK constructor in
> order to use Royale to build the apps I want to build.
>
> The instructions need to be a TON clearer, and more obvious from the
> typical entry points where a new user would encounter Royale. We should
> possibly also add qualifiers to any statements that an IDE like Moonshine
> supports Royale. It does not support Royale as we deliver it, but only
> after it has been tweaked by processes that are obvious to those developing
> Royale but not to the world at large.
>
> Sorry if I sound irked, but consider that my reaction may mirror that of
> many who want to try Royale out but trip over the starting line.
>
> Andrew
>
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> Virus-free.
> www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, Oct 9, 2019 at 5:52 PM Josh Tynjala 
> wrote:
>
> > The main royale-asjs README mentions the Adobe stuff as optional
> > dependencies, but the instructions seem to be aimed at contributors:
> >
> >
> >
> https://github.com/apache/royale-asjs#additional-prerequisites-for-swf-output
> >
> > What a non-contributor user is expected to do appears to be mentioned on
> > this page (it requires running the InstallAdobeSDKs.xml Ant script):
> >
> > https://apache.github.io/royale-docs/get-started/download-royale
> >
> > I recall that if you install the npm version of Royale, it will ask to
> > download the Adobe dependencies for you. That's probably the easiest way
> > for a new user to get started.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Wed, Oct 9, 2019 at 1:44 PM Andrew Wetmore 
> wrote:
> >
> > > Thanks @Josh Tynjala  . Do we say that
> > > anywhere in the instructions where a new user would run into it?
> > >
> > >
> > > <
> >
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > Virus-free.
> > > www.avast.com
> > > <
> >
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> > >
> > > <#m_-3106823410389824051_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >
> > > On Wed, Oct 9, 2019 at 5:27 PM Josh Tynjala  >
> > > wrote:
> > >
> > >> If you downloaded the js-swf binary distribution, you need to add the
> > >> Adobe
> > >> dependencies manually. We cannot distribute them.
> > >>
> > >> The playerglobal.swc in the js-only version is not the real one from
> > >> Adobe.
> > >> It's just a placeholder to make certain IDEs happy. I think it's just
> a
> > >> copy of js.swc.
> > >>
> > >> --
> > >> Josh Tynjala
> > >> Bowler Hat LLC <https://bowlerhat.dev>
> > >>
> > >>
> > >> On Wed, Oct 9, 2019 at 1:16 PM Andrew Wetmore 
> > >> wrote:
> > >>
> > >> > I wiped out the previous project and tried again with the Royale
> > JS-SWF
> > >> > version. When I try to compile the project in Moonshine for either
> JS
> > or
> > >> > Flash, I see this error message: "This SDK does not contains
> > >> > playerglobal.swc in frameworks\libs\player\11.7\playerglobal.swc.
> > >> Download
> > >> > playerglobal here". When I look in the package for the JS-only
> > version,
> > >> > playerglobal is there. I do not see it in the JS_SWF version.
> > >> >
> > >> > <
> > >> >
> > >>
> >
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> > >> > >
> > >> > Virus-free.
> > >> > www.avast.com
> > >> > <
>

Re: Broken royale-config in JS only build of released Apache Royale SDK 0.9.6

2019-10-09 Thread Josh Tynjala
The main royale-asjs README mentions the Adobe stuff as optional
dependencies, but the instructions seem to be aimed at contributors:

https://github.com/apache/royale-asjs#additional-prerequisites-for-swf-output

What a non-contributor user is expected to do appears to be mentioned on
this page (it requires running the InstallAdobeSDKs.xml Ant script):

https://apache.github.io/royale-docs/get-started/download-royale

I recall that if you install the npm version of Royale, it will ask to
download the Adobe dependencies for you. That's probably the easiest way
for a new user to get started.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Oct 9, 2019 at 1:44 PM Andrew Wetmore  wrote:

> Thanks @Josh Tynjala  . Do we say that
> anywhere in the instructions where a new user would run into it?
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> <#m_-3106823410389824051_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, Oct 9, 2019 at 5:27 PM Josh Tynjala 
> wrote:
>
>> If you downloaded the js-swf binary distribution, you need to add the
>> Adobe
>> dependencies manually. We cannot distribute them.
>>
>> The playerglobal.swc in the js-only version is not the real one from
>> Adobe.
>> It's just a placeholder to make certain IDEs happy. I think it's just a
>> copy of js.swc.
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC <https://bowlerhat.dev>
>>
>>
>> On Wed, Oct 9, 2019 at 1:16 PM Andrew Wetmore 
>> wrote:
>>
>> > I wiped out the previous project and tried again with the Royale JS-SWF
>> > version. When I try to compile the project in Moonshine for either JS or
>> > Flash, I see this error message: "This SDK does not contains
>> > playerglobal.swc in frameworks\libs\player\11.7\playerglobal.swc.
>> Download
>> > playerglobal here". When I look in the package for the JS-only version,
>> > playerglobal is there. I do not see it in the JS_SWF version.
>> >
>> > <
>> >
>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
>> > >
>> > Virus-free.
>> > www.avast.com
>> > <
>> >
>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
>> > >
>> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> >
>> > On Wed, Oct 9, 2019 at 3:07 PM Alex Harui 
>> > wrote:
>> >
>> > > When you build with AIR_HOME (which is required to create release
>> > > artifacts, since we want to produce both jsonly and js-swf in one
>> run), a
>> > > different target called "jsonly-package" run and tries to muck with
>> some
>> > > files before packaging the js-only artifacts.  It could be that the
>> > > jsonly-package needs updating now that SWF SWCs are listed in
>> > > royale-config.xml.  That means we've had this bug for months and
>> nobody
>> > > noticed until now.
>> > >
>> > > -Alex
>> > >
>> > > On 10/9/19, 9:38 AM, "Josh Tynjala" 
>> wrote:
>> > >
>> > > It looks like the Ant target that updates the library-path for the
>> > > JS-only
>> > > build is called tweak-for-jsonly. Copied here for convenience:
>> > >
>> > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fasn0idata=02%7C01%7Caharui%40adobe.com%7C972794372a8a4037148008d74cd72cc9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637062359364655836sdata=7h3ZHxgGsfZqP8kE22amKQYDr7%2BNyQa7EpoG86147uU%3Dreserved=0
>> > >
>> > > I see that it has unless="env.AIR_HOME", which means that this
>> target
>> > > is
>> > > skipped if the AIR_HOME environment variable is set. With that in
>> > > mind, I'm
>> > > guessing that AIR_HOME needs to be set for the js-swf build, but
>> > > cleared
>> > > for the js-only build.
>> > >
>> > > --
>> > > Josh Tynjala
>> > > Bowler Hat LLC <
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C972794372a8a4037148008d74cd72cc9%7Cfa7b1b5a7b34438794a

Re: Broken royale-config in JS only build of released Apache Royale SDK 0.9.6

2019-10-09 Thread Josh Tynjala
If you downloaded the js-swf binary distribution, you need to add the Adobe
dependencies manually. We cannot distribute them.

The playerglobal.swc in the js-only version is not the real one from Adobe.
It's just a placeholder to make certain IDEs happy. I think it's just a
copy of js.swc.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Oct 9, 2019 at 1:16 PM Andrew Wetmore  wrote:

> I wiped out the previous project and tried again with the Royale JS-SWF
> version. When I try to compile the project in Moonshine for either JS or
> Flash, I see this error message: "This SDK does not contains
> playerglobal.swc in frameworks\libs\player\11.7\playerglobal.swc. Download
> playerglobal here". When I look in the package for the JS-only version,
> playerglobal is there. I do not see it in the JS_SWF version.
>
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> Virus-free.
> www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, Oct 9, 2019 at 3:07 PM Alex Harui 
> wrote:
>
> > When you build with AIR_HOME (which is required to create release
> > artifacts, since we want to produce both jsonly and js-swf in one run), a
> > different target called "jsonly-package" run and tries to muck with some
> > files before packaging the js-only artifacts.  It could be that the
> > jsonly-package needs updating now that SWF SWCs are listed in
> > royale-config.xml.  That means we've had this bug for months and nobody
> > noticed until now.
> >
> > -Alex
> >
> > On 10/9/19, 9:38 AM, "Josh Tynjala"  wrote:
> >
> > It looks like the Ant target that updates the library-path for the
> > JS-only
> > build is called tweak-for-jsonly. Copied here for convenience:
> >
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fasn0idata=02%7C01%7Caharui%40adobe.com%7C972794372a8a4037148008d74cd72cc9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637062359364655836sdata=7h3ZHxgGsfZqP8kE22amKQYDr7%2BNyQa7EpoG86147uU%3Dreserved=0
> >
> > I see that it has unless="env.AIR_HOME", which means that this target
> > is
> > skipped if the AIR_HOME environment variable is set. With that in
> > mind, I'm
> > guessing that AIR_HOME needs to be set for the js-swf build, but
> > cleared
> > for the js-only build.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C972794372a8a4037148008d74cd72cc9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637062359364655836sdata=Ih2P7zf2c%2BLPn5ktks02EE7k6s24RKcabVem7VqjWeg%3Dreserved=0
> > >
> >
> >
> > On Wed, Oct 9, 2019 at 6:52 AM Piotr Zarzycki <
> > piotrzarzyck...@gmail.com>
> > wrote:
> >
> > > Hi Guys,
> > >
> > > It looks like we have broken royale-config in released SDK. Andrew
> > raised
> > > in Moonshine GitHub issue that he couldn't build Hello World
> > project. I
> > > tried Moonshine and downloaded JS-only version of SDK. I get
> > following
> > > error [1].
> > > I downloaded JS-SWF version and tried compile project again - this
> > time it
> > > went fine.
> > >
> > > JS-only version of released 0.9.6 contains in section
> >  -
> > > list of swc. - Those swc doesn't exists in JS-only.
> > >
> > > Fragment of config
> > >
> > > > 
> > > >  libs/Basic.swc
> > > >  libs/Binding.swc
> > > >  libs/Charts.swc
> > > >  libs/Collections.swc
> > > >  libs/Core.swc
> > > > 
> > >
> > >
> > > JS-only nightly build of 0.9.7 - doesn't contains in that section
> > anything
> > >
> > > >   
> > > >   
> > >
> > >
> > > [1]
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2F2lgvkdata=02%7C01%7Caharui%40adobe.com%7C972794372a8a4037148008d74cd72cc9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637062359364655836sdata=IebVohnQGkmg%2BAO2RJCS2LRTdP3LQE0NoQ%2BUt7xlOJI%3Dreserved=0
> > >
> > > Thanks,
&

Re: RoyaleUnit testing - swf player version used for testing

2019-10-09 Thread Josh Tynjala
Yeah, I think it would make a lot of sense to update our build scripts to
use this environment variable when launching RoyaleUnit tests. I'm pretty
sure that it is already set on the CI server for Mustella tests, so we
should have the build consistently use the same version for everything.

As a bonus, setting the default program for .swf files won't be necessary
anymore.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Oct 9, 2019 at 11:46 AM Greg Dove  wrote:

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


Re: RoyaleUnit testing - swf player version used for testing

2019-10-09 Thread Josh Tynjala
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.
>


Re: Broken royale-config in JS only build of released Apache Royale SDK 0.9.6

2019-10-09 Thread Josh Tynjala
It looks like the Ant target that updates the library-path for the JS-only
build is called tweak-for-jsonly. Copied here for convenience:

https://paste.apache.org/asn0i

I see that it has unless="env.AIR_HOME", which means that this target is
skipped if the AIR_HOME environment variable is set. With that in mind, I'm
guessing that AIR_HOME needs to be set for the js-swf build, but cleared
for the js-only build.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Oct 9, 2019 at 6:52 AM Piotr Zarzycki 
wrote:

> Hi Guys,
>
> It looks like we have broken royale-config in released SDK. Andrew raised
> in Moonshine GitHub issue that he couldn't build Hello World project. I
> tried Moonshine and downloaded JS-only version of SDK. I get following
> error [1].
> I downloaded JS-SWF version and tried compile project again - this time it
> went fine.
>
> JS-only version of released 0.9.6 contains in section   -
> list of swc. - Those swc doesn't exists in JS-only.
>
> Fragment of config
>
> > 
> >  libs/Basic.swc
> >  libs/Binding.swc
> >  libs/Charts.swc
> >  libs/Collections.swc
> >  libs/Core.swc
> > 
>
>
> JS-only nightly build of 0.9.7 - doesn't contains in that section anything
>
> >   
> >   
>
>
> [1] https://paste.apache.org/2lgvk
>
> Thanks,
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>


Re: Nightly Build Server going offline

2019-10-09 Thread Josh Tynjala
Well, the build made it a bit further after I set the default app for .swf
files. However, it seems that Flash Player is not picking up the trust file
that the RoyaleUnit Ant Task is creating. Based on the console log, the
Jenkins job seems to be creating it here:

C:\windows\system32\config\systemprofile\AppData\Roaming\Macromedia\Flash
Player\#Security\FlashPlayerTrust\royaleUnit.cfg

Looking at Jenkins emails from the old server, it used to be in the user
folder instead

C:\Users\apacheroyale\AppData\Roaming\Macromedia\Flash
Player\#Security\FlashPlayerTrust\royaleUnit.cfg

I guess that would be C:\Users\ApacheRoyaleCI\ on the new server. It looks
like royaleUnit.cfg exists in the user folder too, but I'm guessing that's
from when I ran the tests manually. So maybe that's an interesting clue? Is
the Jenkins job running as the ApacheRoyaleCI user, or could it be a
different user account that can't access C:\Users\ApacheRoyaleCI\? I don't
really know Jenkins, so I'm just throwing out ideas here.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Oct 9, 2019 at 8:21 AM Josh Tynjala 
wrote:

> I logged into the server and discovered that js-swf build was failing
> because there was no default program for .swf files. I set the
> flashplayerdebugger.exe that you downloaded as the default, and I was able
> to successfully run the tests in a PowerShell window. I started a new build
> in Jenkins, so we should hopefully see how it goes in a few minutes.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Oct 9, 2019 at 8:08 AM Alex Harui 
> wrote:
>
>> I sent an email to private@ with the new credentials and URL.  I don't
>> know how to get the old URL back at this point in time.  The JSOnly build
>> succeeded.  I'm trying to get the JS-SWF build to succeed.
>>
>> http://apacheroyaleci2.westus2.cloudapp.azure.com:8080
>>
>> We should update all links to use the new URL.  Having someone else do
>> what would be appreciated.
>>
>>
>> -Alex
>>
>> On 10/9/19, 6:23 AM, "Carlos Rovira"  wrote:
>>
>> Hope Alex can let us know what he thinks about timing
>> We can do a quick change directly in production if needed and then
>> revert
>> when needed to not mesh with pre for something punctual...
>>
>> El mié., 9 oct. 2019 a las 9:50, Piotr Zarzycki (<
>> piotrzarzyck...@gmail.com>)
>> escribió:
>>
>> > Hi,
>> >
>> > If we are going to stay for a longer time with nightly build
>> offline we
>> > should also update link to nightly build on our website. If it's
>> only for
>> > couple of days no problem.
>> >
>> > Thanks,
>> > Piotr
>> >
>> > wt., 8 paź 2019 o 20:04 Carlos Rovira 
>> > napisał(a):
>> >
>> > > 爛
>> > >
>> > > :)
>> > >
>> > > El mar., 8 oct. 2019 a las 18:12, Alex Harui
>> (> > >)
>> > > escribió:
>> > >
>> > > > I am definitely planning to start rebuilding the server today.
>> Keep
>> > your
>> > > > fingers crossed.
>> > > >
>> > > > -Alex
>> > > >
>> > > > On 10/7/19, 8:47 AM, "Alex Harui" 
>> wrote:
>> > > >
>> > > > I think the merge happened, so I am going to try to do the
>> rebuild
>> > > > this week, probably on my Tuesday if I can finish up some fixes
>> to
>> > > > releasecandidate.xml needed for Windows today.
>> > > >
>> > > > -Alex
>> > > >
>> > > > On 10/7/19, 12:39 AM, "Carlos Rovira" <
>> carlosrov...@apache.org>
>> > > wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > don't think a day be a problem. When can better warn in
>> social
>> > > > networks
>> > > > about that 24h unavailability.
>> > > > Other option is to store in pre web server (
>> > > Royale.codeoscopic.com).
>> > > > You
>> > > > have credentials and can upload to Wordpress and then
>> we can
>> > > share
>> > > > that
>> > > > link.
>> > > > Whatever option could be fine, but for a day, I d

Re: Broken royale-config in JS only build of released Apache Royale SDK 0.9.6

2019-10-09 Thread Josh Tynjala
I just installed @apache-royale/royale-js from npm, and I'm seeing the same
errors.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Oct 9, 2019 at 6:52 AM Piotr Zarzycki 
wrote:

> Hi Guys,
>
> It looks like we have broken royale-config in released SDK. Andrew raised
> in Moonshine GitHub issue that he couldn't build Hello World project. I
> tried Moonshine and downloaded JS-only version of SDK. I get following
> error [1].
> I downloaded JS-SWF version and tried compile project again - this time it
> went fine.
>
> JS-only version of released 0.9.6 contains in section   -
> list of swc. - Those swc doesn't exists in JS-only.
>
> Fragment of config
>
> > 
> >  libs/Basic.swc
> >  libs/Binding.swc
> >  libs/Charts.swc
> >  libs/Collections.swc
> >  libs/Core.swc
> > 
>
>
> JS-only nightly build of 0.9.7 - doesn't contains in that section anything
>
> >   
> >   
>
>
> [1] https://paste.apache.org/2lgvk
>
> Thanks,
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>


Re: Nightly Build Server going offline

2019-10-09 Thread Josh Tynjala
I logged into the server and discovered that js-swf build was failing
because there was no default program for .swf files. I set the
flashplayerdebugger.exe that you downloaded as the default, and I was able
to successfully run the tests in a PowerShell window. I started a new build
in Jenkins, so we should hopefully see how it goes in a few minutes.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Oct 9, 2019 at 8:08 AM Alex Harui  wrote:

> I sent an email to private@ with the new credentials and URL.  I don't
> know how to get the old URL back at this point in time.  The JSOnly build
> succeeded.  I'm trying to get the JS-SWF build to succeed.
>
> http://apacheroyaleci2.westus2.cloudapp.azure.com:8080
>
> We should update all links to use the new URL.  Having someone else do
> what would be appreciated.
>
>
> -Alex
>
> On 10/9/19, 6:23 AM, "Carlos Rovira"  wrote:
>
> Hope Alex can let us know what he thinks about timing
> We can do a quick change directly in production if needed and then
> revert
> when needed to not mesh with pre for something punctual...
>
> El mié., 9 oct. 2019 a las 9:50, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>)
> escribió:
>
> > Hi,
> >
> > If we are going to stay for a longer time with nightly build offline
> we
> > should also update link to nightly build on our website. If it's
> only for
> > couple of days no problem.
> >
> > Thanks,
> > Piotr
> >
> > wt., 8 paź 2019 o 20:04 Carlos Rovira 
> > napisał(a):
> >
> > > 爛
> > >
> > > :)
> > >
> > > El mar., 8 oct. 2019 a las 18:12, Alex Harui
> ( > >)
> > > escribió:
> > >
> > > > I am definitely planning to start rebuilding the server today.
> Keep
> > your
> > > > fingers crossed.
> > > >
> > > > -Alex
> > > >
> > > > On 10/7/19, 8:47 AM, "Alex Harui" 
> wrote:
> > > >
> > > > I think the merge happened, so I am going to try to do the
> rebuild
> > > > this week, probably on my Tuesday if I can finish up some fixes
> to
> > > > releasecandidate.xml needed for Windows today.
> > > >
> > > > -Alex
> > > >
> > > > On 10/7/19, 12:39 AM, "Carlos Rovira" <
> carlosrov...@apache.org>
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > don't think a day be a problem. When can better warn in
> social
> > > > networks
> > > > about that 24h unavailability.
> > > > Other option is to store in pre web server (
> > > Royale.codeoscopic.com).
> > > > You
> > > > have credentials and can upload to Wordpress and then we
> can
> > > share
> > > > that
> > > > link.
> > > > Whatever option could be fine, but for a day, I don't
> think we
> > > > should
> > > > invest much time.
> > > >
> > > > thanks!
> > > >
> > > >
> > > >
> > > > El dom., 6 oct. 2019 a las 9:28, Harbs (<
> harbs.li...@gmail.com
> > >)
> > > > escribió:
> > > >
> > > > > Seems fine to me.
> > > > >
> > > > > > On Oct 6, 2019, at 1:33 AM, Alex Harui
> > > >  wrote:
> > > > > >
> > > > > > I was only thinking about temporary distribution of
> the
> > > > nightly build
> > > > > while the CI server is offline.  I'm not sure it makes
> sense
> > to
> > > > always copy
> > > > > the nightly build somewhere else.  I think the
> bandwidth
> > would
> > > > add up.
> > > > > >
> > > > > > I'm mainly asking if anyone thinks it would be a
> problem if
> > > > the nightly
> > > > > builds were unavailable for a day (hopefully only a
> day).
> > > > > >
> > > > > > -Alex
> > > > > 

Re: Pay as You Go (PAYG) Suggestion

2019-10-08 Thread Josh Tynjala
It is worth mentioning that Royale uses Google's Closure compiler when
creating release builds. Closure compiler does very advanced JavaScript
code analysis that eliminates unused code from the final output, so it has
a very similar effect to tree shaking.

The ability to integrate into a webpack build pipeline would be really
nice, though, since webpack is such a popular tool in the JS ecosystem.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Oct 8, 2019 at 1:00 AM Chris Velevitch 
wrote:

> If the whole point of PAYG is to eliminate unused code from being
> included in the final app distribution, then I'd like to suggest that
> we take advantage of the tools the JavaScript ecosystem already has
> for eliminating unused code.
>
> I think we should take a look at Webpack [1] and create a compilation
> pipeline that feeds into Webpack to create the final compacted
> distributable app.
>
>
>
> [1] https://webpack.js.org/guides/tree-shaking/
>


Re: [DISCUSS] Discuss Release Apache Royale 0.9.6 RC3

2019-09-26 Thread Josh Tynjala
Thank you, Alex! I tried your changes with adobe/royale artifacts deleted
from .m2, and I was able to get through both js and js-swf builds
successfully.

Carlos, I think that these changes will allow you to get through the
process now too.

For everyone's convenience, here's a link to the latest ApproveRoyale.xml
script for 0.9.6:

https://github.com/apache/royale-asjs/blob/release/0.9.6/ApproveRoyale.xml

Use this one instead of the one linked from the [VOTE] thread. Just to be
clear, since ApproveRoyale.xml is a convenience script for PMC members to
aid with the release voting process, and not something that end users or
potential contributors need to use, these latest changes to
ApproveRoyale.xml don't require the creation of a new RC.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Thu, Sep 26, 2019 at 11:34 AM Alex Harui 
wrote:

> Yeah, I just saw that myself.  That's because I didn't merge in my changes
> correctly.  I just pushed one that seems to be working better.
>
> -Alex
>
> On 9/26/19, 10:27 AM, "Josh Tynjala"  wrote:
>
> Thanks, Alex. The ApproveRoyale.mxml from the latest release/0.9.6 is
> working for me if I delete all adobe/royale artifacts from my .m2, and
> if I
> omit -Duse-flash=true. However, with -Duse-flash=true, I'm seeing
> compiler
> errors when Maven tries to build the SWF version of Binding.swc.
>
> A couple of examples of the errors (there are many more):
>
>
> /Users/joshtynjala/Desktop/royale/apache-royale-0.9.6-maven-src/royale-asjs/frameworks/projects/Binding/src/main/royale/org/apache/royale/binding/ApplicationDataBinding.as(23):
> col: 12 Warning: Definition org.apache.royale.core.IBinding could not
> be
> found.
>
> import org.apache.royale.core.IBinding;
>^
>
>
> /Users/joshtynjala/Desktop/royale/apache-royale-0.9.6-maven-src/royale-asjs/frameworks/projects/Binding/src/main/royale/org/apache/royale/binding/ApplicationDataBinding.as(27):
> col: 12 Warning: Definition org.apache.royale.core.IBead could not be
> found.
>
> import org.apache.royale.core.IBead;
>^
>
> Could it be because you removed the asjs_mvn_defines from
> ApproveRoyale.xml
> in your new commit that added inputstring="Yes"? I added that back in,
> and
> my change seemed to allow me to finish the script successfully with
> -Duse-flash=true.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cafc4989b7d61427d849a08d742a6bc57%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637051156201507168sdata=aZr5SvuHu%2Fo%2BWc1EF7MRosekWVMeAqC9yudOoLTe3uo%3Dreserved=0
> >
>
>
> On Thu, Sep 26, 2019 at 12:47 AM Alex Harui 
> wrote:
>
> > Looks like I missed a commit.  I just pushed the ApproveRoyale.xml I
> was
> > using to the release branch.
> >
> > Try that one and see if it works better.  It shouldn't require the
> > workaround you used.
> >
> > Thanks,
> > -Alex
> >
> > On 9/25/19, 4:16 PM, "Josh Tynjala" 
> wrote:
> >
> > To get the system property working with ApproveRoyale.xml, I
> added the
> > following line to each of the mvn commands in my local copy of
> > ApproveRoyale.xml:
> >
> >  >
> >
> value="-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=499700b6"/>
>     >
> > This should work for anyone using Bash's yes command to quickly
> > approve the
> > license headers (after you've already done it once manually, of
> > course).
> >
> > yes | ant -e -f ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cafc4989b7d61427d849a08d742a6bc57%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637051156201507168sdata=aZr5SvuHu%2Fo%2BWc1EF7MRosekWVMeAqC9yudOoLTe3uo%3Dreserved=0
> > >
> >
> >
> > On Wed, Sep 25, 2019 at 2:58 PM Josh Tynjala <
> > joshtynj...@bowlerhat.dev>
> > wrote:
> >
> > > I deleted all com.adobe artifacts in my Maven .m2 folder, and
> I can
> > see
> > > the prompt to accept the license for the Adobe dependencies.
> > >
> > > The build output suggests that y

Re: [DISCUSS] Discuss Release Apache Royale 0.9.6 RC3

2019-09-26 Thread Josh Tynjala
Thanks, Alex. The ApproveRoyale.mxml from the latest release/0.9.6 is
working for me if I delete all adobe/royale artifacts from my .m2, and if I
omit -Duse-flash=true. However, with -Duse-flash=true, I'm seeing compiler
errors when Maven tries to build the SWF version of Binding.swc.

A couple of examples of the errors (there are many more):

/Users/joshtynjala/Desktop/royale/apache-royale-0.9.6-maven-src/royale-asjs/frameworks/projects/Binding/src/main/royale/org/apache/royale/binding/ApplicationDataBinding.as(23):
col: 12 Warning: Definition org.apache.royale.core.IBinding could not be
found.

import org.apache.royale.core.IBinding;
   ^

/Users/joshtynjala/Desktop/royale/apache-royale-0.9.6-maven-src/royale-asjs/frameworks/projects/Binding/src/main/royale/org/apache/royale/binding/ApplicationDataBinding.as(27):
col: 12 Warning: Definition org.apache.royale.core.IBead could not be found.

import org.apache.royale.core.IBead;
   ^

Could it be because you removed the asjs_mvn_defines from ApproveRoyale.xml
in your new commit that added inputstring="Yes"? I added that back in, and
my change seemed to allow me to finish the script successfully with
-Duse-flash=true.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Thu, Sep 26, 2019 at 12:47 AM Alex Harui 
wrote:

> Looks like I missed a commit.  I just pushed the ApproveRoyale.xml I was
> using to the release branch.
>
> Try that one and see if it works better.  It shouldn't require the
> workaround you used.
>
> Thanks,
> -Alex
>
> On 9/25/19, 4:16 PM, "Josh Tynjala"  wrote:
>
> To get the system property working with ApproveRoyale.xml, I added the
> following line to each of the mvn commands in my local copy of
> ApproveRoyale.xml:
>
> 
> value="-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=499700b6"/>
>
> This should work for anyone using Bash's yes command to quickly
> approve the
> license headers (after you've already done it once manually, of
> course).
>
> yes | ant -e -f ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C69e4a3028e3e420535f808d7420e5b3a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637050501738714087sdata=hMkPguiNL2bdcHRmml%2Fjk0nEDkcn9TIaT%2BjcNV%2F7c5k%3Dreserved=0
> >
>
>
> On Wed, Sep 25, 2019 at 2:58 PM Josh Tynjala <
> joshtynj...@bowlerhat.dev>
> wrote:
>
> > I deleted all com.adobe artifacts in my Maven .m2 folder, and I can
> see
> > the prompt to accept the license for the Adobe dependencies.
> >
> > The build output suggests that you can set a system property to
> accept the
> > agreement, so I tried adding that property to my command, like this:
> >
> > ant -e -f ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3
> >
> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=
> >
> > (Where  is replaced by my real system ID)
> >
> > However, it still asked me to accept the agreement. Perhaps this
> system
> > property isn't getting inherited by the Maven build.
> >
> > I am using the RC3 ApproveRoyale.xml linked from the Vote thread,
> and not
> > an older one.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C69e4a3028e3e420535f808d7420e5b3a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637050501738724087sdata=oUzKXHUA9cU7gL5o09ultnH%2Bj7KnC%2FynBhv2J%2BNo%2FFg%3Dreserved=0
> >
> >
> >
> > On Wed, Sep 25, 2019 at 11:25 AM Carlos Rovira <
> carlosrov...@apache.org>
> > wrote:
> >
> >> Hi
> >> I tried in the meanwhile with your settings and enter in the
> endless loop
> >> as in RC2
> >>
> >> I'll try to run now adding that to the command and report back
> >>
> >>
> >> El mié., 25 sept. 2019 a las 18:59, Piotr Zarzycki (<
> >> piotrzarzyck...@gmail.com>) escribió:
> >>
> >> > The same issue as it was previously. You are missing playerglobal
> - I
> >> don't
> >> > know why at all. You can try to switch to my settings - don't
> forget
> >> update
> >> > link to maven artifacts in it.
> >> >
> >> > I'm

Re: [DISCUSS] Discuss Release Apache Royale 0.9.6 RC3

2019-09-25 Thread Josh Tynjala
To get the system property working with ApproveRoyale.xml, I added the
following line to each of the mvn commands in my local copy of
ApproveRoyale.xml:



This should work for anyone using Bash's yes command to quickly approve the
license headers (after you've already done it once manually, of course).

yes | ant -e -f ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Sep 25, 2019 at 2:58 PM Josh Tynjala 
wrote:

> I deleted all com.adobe artifacts in my Maven .m2 folder, and I can see
> the prompt to accept the license for the Adobe dependencies.
>
> The build output suggests that you can set a system property to accept the
> agreement, so I tried adding that property to my command, like this:
>
> ant -e -f ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3
> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=
>
> (Where  is replaced by my real system ID)
>
> However, it still asked me to accept the agreement. Perhaps this system
> property isn't getting inherited by the Maven build.
>
> I am using the RC3 ApproveRoyale.xml linked from the Vote thread, and not
> an older one.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Sep 25, 2019 at 11:25 AM Carlos Rovira 
> wrote:
>
>> Hi
>> I tried in the meanwhile with your settings and enter in the endless loop
>> as in RC2
>>
>> I'll try to run now adding that to the command and report back
>>
>>
>> El mié., 25 sept. 2019 a las 18:59, Piotr Zarzycki (<
>> piotrzarzyck...@gmail.com>) escribió:
>>
>> > The same issue as it was previously. You are missing playerglobal - I
>> don't
>> > know why at all. You can try to switch to my settings - don't forget
>> update
>> > link to maven artifacts in it.
>> >
>> > I'm not sure also but maybe you should try to run approve script with
>> this
>> > one: -Dgenerate.swf.swcs=true and -DskipTests=true.
>> >
>> > śr., 25 wrz 2019 o 18:41 Carlos Rovira 
>> > napisał(a):
>> >
>> > > Hi,
>> > >
>> > > sorry to report that my try failed. I tried with clean .m2 and my own
>> > > settings.xml. Maybe I need to switch to the settings Piotr send to me?
>> > >
>> > > as well I used the instruction provided in email: ant -e -f
>> > > ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3
>> > >
>> > >
>> > > ache.org/maven2/org/antlr/antlr/3.4/antlr-3.4.jar (1.1 MB at 2.7
>> > > MB/s)[INFO]
>> > >
>> 
>> > >
>> > > [INFO] Reactor Build Order:
>> > >
>> > > [INFO]
>> > >
>> > > [INFO] Apache Royale: Compiler: Parent
>> > > [pom]
>> > >
>> > > [INFO] Apache Royale: Compiler: Compiler-Common
>> > > [jar]
>> > >
>> > > [INFO] Apache Royale: Compiler: Test Utils
>> > > [jar]
>> > >
>> > > [INFO] Apache Royale: Compiler: Externc
>> > > [jar]
>> > >
>> > > [INFO] Apache Royale: Compiler: Compiler
>> > > [jar]
>> > >
>> > > [INFO] Apache Royale: Compiler: Compiler-JX
>> > > [jar]
>> > >
>> > > [INFO] Apache Royale: Compiler: SWFUtils
>> > > [jar]
>> > >
>> > > [INFO] Apache Royale: Compiler: Debugger
>> > > [jar]
>> > >
>> > > [INFO] Apache Royale: Compiler: OEM Layer
>> > > [jar]
>> > >
>> > > [INFO] Apache Royale: Royale Ant Tasks
>> > > [jar]
>> > >
>> > > [INFO] Apache Royale: RoyaleUnit Ant Tasks
>> > > [jar]
>> > >
>> > > [INFO] Apache Royale: Royale Maven Plugin
>> > > [maven-plugin]
>> > >
>> > > [INFO]
>> > >
>> > > [INFO] -< org.apache.royale.compiler:royale-compiler-parent
>> > > >--
>> > >
>> > > [INFO] Building Apache Royale: Compiler: Parent 0.9.6
>> > > [1/12]
>> > >
>> > > [INFO] [ pom
>> > > ]-
>> > >
>> > > Downloading from apache-release:
>> > >
>> > >
>> >
>> https://repository.apache.org/content/repositories/releases/com/adobe/flash/framework/playerglobal/20.0/playerglobal-20.0.

Re: [DISCUSS] Discuss Release Apache Royale 0.9.6 RC3

2019-09-25 Thread Josh Tynjala
I deleted all com.adobe artifacts in my Maven .m2 folder, and I can see the
prompt to accept the license for the Adobe dependencies.

The build output suggests that you can set a system property to accept the
agreement, so I tried adding that property to my command, like this:

ant -e -f ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3
-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=

(Where  is replaced by my real system ID)

However, it still asked me to accept the agreement. Perhaps this system
property isn't getting inherited by the Maven build.

I am using the RC3 ApproveRoyale.xml linked from the Vote thread, and not
an older one.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Sep 25, 2019 at 11:25 AM Carlos Rovira 
wrote:

> Hi
> I tried in the meanwhile with your settings and enter in the endless loop
> as in RC2
>
> I'll try to run now adding that to the command and report back
>
>
> El mié., 25 sept. 2019 a las 18:59, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > The same issue as it was previously. You are missing playerglobal - I
> don't
> > know why at all. You can try to switch to my settings - don't forget
> update
> > link to maven artifacts in it.
> >
> > I'm not sure also but maybe you should try to run approve script with
> this
> > one: -Dgenerate.swf.swcs=true and -DskipTests=true.
> >
> > śr., 25 wrz 2019 o 18:41 Carlos Rovira 
> > napisał(a):
> >
> > > Hi,
> > >
> > > sorry to report that my try failed. I tried with clean .m2 and my own
> > > settings.xml. Maybe I need to switch to the settings Piotr send to me?
> > >
> > > as well I used the instruction provided in email: ant -e -f
> > > ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3
> > >
> > >
> > > ache.org/maven2/org/antlr/antlr/3.4/antlr-3.4.jar (1.1 MB at 2.7
> > > MB/s)[INFO]
> > >
> 
> > >
> > > [INFO] Reactor Build Order:
> > >
> > > [INFO]
> > >
> > > [INFO] Apache Royale: Compiler: Parent
> > > [pom]
> > >
> > > [INFO] Apache Royale: Compiler: Compiler-Common
> > > [jar]
> > >
> > > [INFO] Apache Royale: Compiler: Test Utils
> > > [jar]
> > >
> > > [INFO] Apache Royale: Compiler: Externc
> > > [jar]
> > >
> > > [INFO] Apache Royale: Compiler: Compiler
> > > [jar]
> > >
> > > [INFO] Apache Royale: Compiler: Compiler-JX
> > > [jar]
> > >
> > > [INFO] Apache Royale: Compiler: SWFUtils
> > > [jar]
> > >
> > > [INFO] Apache Royale: Compiler: Debugger
> > > [jar]
> > >
> > > [INFO] Apache Royale: Compiler: OEM Layer
> > > [jar]
> > >
> > > [INFO] Apache Royale: Royale Ant Tasks
> > > [jar]
> > >
> > > [INFO] Apache Royale: RoyaleUnit Ant Tasks
> > > [jar]
> > >
> > > [INFO] Apache Royale: Royale Maven Plugin
> > > [maven-plugin]
> > >
> > > [INFO]
> > >
> > > [INFO] -< org.apache.royale.compiler:royale-compiler-parent
> > > >--
> > >
> > > [INFO] Building Apache Royale: Compiler: Parent 0.9.6
> > > [1/12]
> > >
> > > [INFO] [ pom
> > > ]-
> > >
> > > Downloading from apache-release:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/releases/com/adobe/flash/framework/playerglobal/20.0/playerglobal-20.0.pom
> > >
> > > Downloading from central:
> > >
> > >
> >
> https://repo.maven.apache.org/maven2/com/adobe/flash/framework/playerglobal/20.0/playerglobal-20.0.pom
> > >
> > > [WARNING] The POM for com.adobe.flash.framework:playerglobal:swc:20.0
> is
> > > missing, no dependency information available
> > >
> > > Downloading from apache-release:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/releases/com/adobe/flash/framework/playerglobal/20.0/playerglobal-20.0.swc
> > >
> > > Downloading from central:
> > >
> > >
> >
> https://repo.maven.apache.org/maven2/com/adobe/flash/framework/playerglobal/20.0/playerglobal-20.0.swc
> > >
> > > [INFO]
> > >
> 
> > >
> > > [

Re: [VOTE] Release Apache Royale 0.9.6 RC3

2019-09-25 Thread Josh Tynjala
+1 (Binding)
Package
https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc3/apache-royale-0.9.6-src.tar.gz
Java 1.8
OS: Mac OS X x86_64 10.14.6
Source kit signatures match: y
Source kit builds: y
README is ok: y
RELEASE_NOTES is ok: y
NOTICE is ok: y
LICENSE is ok: y
No unapproved licenses or archives: y
No unapproved binaries: y

Package
https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc3/binaries/apache-royale-0.9.6-bin-js-swf.tar.gz
Binary kit signatures match: y
NOTICE is ok: y
LICENSE is ok: y
No unapproved licenses or archives in binary package: y
No unapproved binaries in binary package: y

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Sep 25, 2019 at 7:23 AM Apache Royale CI Server <
apacheroyal...@gmail.com> wrote:

> Hi,
>
> This is the vote for the 0.9.6 release of Apache Royale.
>
> The release candidate can be found here;
> https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc3/
>
> Before voting please review the section,'What are the ASF requirements on
> approving a release?', at:
> http://www.apache.org/dev/release.html#approving-a-release
>
> At a minimum you would be expected to check that:
> - SHA and signed packages are correct
> - README, RELEASE_NOTES, NOTICE and LICENSE files are all fine
> - That the build script completes successfully
> - That you can compile and cross-compile a simple example using the SDK.
>
> The KEYS file is at https://dist.apache.org/repos/dist/release/royale/KEYS
>
> The source package is a combination of the 3 main Royale repos.
>
> To use the binary package, unzip it into a folder.  The -js package is
> ready-to-use in an IDE or command-line.  If you need SWF output, use the
> -js-swf package and use Apache Ant to run the InstallAdobeSDKs script via:
>   ant -f InstallAdobeSDKs.xml
>
> You may also get the binary packages via NPM.  The -js package can be
> installed via:
>
> npm install
> https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc3/binaries/apache-royale-0.9.6-bin-js.tar.gz
> -g
>
> The full package with SWF support can be installed via:
>
> npm install
> https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc3/binaries/apache-royale-0.9.6-bin-js-swf.tar.gz
> -g
>
> Maven artifacts are staged here:
> https://repository.apache.org/content/repositories/orgapacheroyale-1058
>
> Please vote to approve this release:
> +1 Approve the release
> -1 Disapprove the release (please provide specific comments to why)
>
> This vote will be open for 72 hours or until a result can be called.
>
> The vote passes if there is:
> - At least 3 +1 votes from the PMC
> - More positive votes than negative votes
>
> Remember that this is a 'beta-quality' release so expect there
> will be many bugs found.  IMO the goal is not to try to find and fix bugs
> in the RC, but to make sure we have the packaging right, and enough
> functionality that folks will have some success trying to use it.
>
> People who are not in PMC are also encouraged to test out the release and
> vote, although their votes will not be binding, they can influence how the
> PMC votes.
>
> When voting please indicate what OS, IDE, Flash Player version and AIR
> version you tested with.
>
> For your convenience, there is an ant script that automates the common
> steps to validate a release.  Instead of individually downloading the
> package and signature files, unzipping, etc, you can instead:
> 1) create an empty folder,
> 2) download into that folder this file:
> https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc3/ApproveRoyale.xml
> 3) run the script:
>ant -e -f ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3
>If you want to test SWF support during the approval, use:
>ant -e -f ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3
> -Duse-flash=true
>
> You are not required to use this script, and more testing of the packages
> and build results are always encouraged.
>
> Please put all discussion about this release in the DISCUSSION thread not
> this VOTE thread.
>
> Thanks,
> Piotr


Re: [DISCUSS] Discuss Release Apache Royale 0.9.6 RC3

2019-09-25 Thread Josh Tynjala
Carlos,

Can you check to see if the AIR_HOME environment variable is set or not?

If I'm understanding the logic in ApproveRoyale.xml, then you need to
ensure that AIR_HOME is *NOT* set, unless you include -Duse-flash=true in
your command. If AIR_HOME is set, then you should clear it. It may also be
a good idea to clear both PLAYERGLOBAL_HOME and FLASHPLAYER_DEBUGGER too,
just to be safe.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Sep 25, 2019 at 9:41 AM Carlos Rovira 
wrote:

> Hi,
>
> sorry to report that my try failed. I tried with clean .m2 and my own
> settings.xml. Maybe I need to switch to the settings Piotr send to me?
>
> as well I used the instruction provided in email: ant -e -f
> ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=3
>
>
> ache.org/maven2/org/antlr/antlr/3.4/antlr-3.4.jar (1.1 MB at 2.7
> MB/s)[INFO]
> 
>
> [INFO] Reactor Build Order:
>
> [INFO]
>
> [INFO] Apache Royale: Compiler: Parent
> [pom]
>
> [INFO] Apache Royale: Compiler: Compiler-Common
> [jar]
>
> [INFO] Apache Royale: Compiler: Test Utils
> [jar]
>
> [INFO] Apache Royale: Compiler: Externc
> [jar]
>
> [INFO] Apache Royale: Compiler: Compiler
> [jar]
>
> [INFO] Apache Royale: Compiler: Compiler-JX
> [jar]
>
> [INFO] Apache Royale: Compiler: SWFUtils
> [jar]
>
> [INFO] Apache Royale: Compiler: Debugger
> [jar]
>
> [INFO] Apache Royale: Compiler: OEM Layer
> [jar]
>
> [INFO] Apache Royale: Royale Ant Tasks
> [jar]
>
> [INFO] Apache Royale: RoyaleUnit Ant Tasks
> [jar]
>
> [INFO] Apache Royale: Royale Maven Plugin
> [maven-plugin]
>
> [INFO]
>
> [INFO] -< org.apache.royale.compiler:royale-compiler-parent
> >--
>
> [INFO] Building Apache Royale: Compiler: Parent 0.9.6
> [1/12]
>
> [INFO] [ pom
> ]-
>
> Downloading from apache-release:
>
> https://repository.apache.org/content/repositories/releases/com/adobe/flash/framework/playerglobal/20.0/playerglobal-20.0.pom
>
> Downloading from central:
>
> https://repo.maven.apache.org/maven2/com/adobe/flash/framework/playerglobal/20.0/playerglobal-20.0.pom
>
> [WARNING] The POM for com.adobe.flash.framework:playerglobal:swc:20.0 is
> missing, no dependency information available
>
> Downloading from apache-release:
>
> https://repository.apache.org/content/repositories/releases/com/adobe/flash/framework/playerglobal/20.0/playerglobal-20.0.swc
>
> Downloading from central:
>
> https://repo.maven.apache.org/maven2/com/adobe/flash/framework/playerglobal/20.0/playerglobal-20.0.swc
>
> [INFO]
> 
>
> [INFO] Reactor Summary for Apache Royale: Compiler: Parent 0.9.6:
>
> [INFO]
>
> [INFO] Apache Royale: Compiler: Parent  FAILURE [
> 0.982 s]
>
> [INFO] Apache Royale: Compiler: Compiler-Common ... SKIPPED
>
> [INFO] Apache Royale: Compiler: Test Utils  SKIPPED
>
> [INFO] Apache Royale: Compiler: Externc ... SKIPPED
>
> [INFO] Apache Royale: Compiler: Compiler .. SKIPPED
>
> [INFO] Apache Royale: Compiler: Compiler-JX ... SKIPPED
>
> [INFO] Apache Royale: Compiler: SWFUtils .. SKIPPED
>
> [INFO] Apache Royale: Compiler: Debugger .. SKIPPED
>
> [INFO] Apache Royale: Compiler: OEM Layer . SKIPPED
>
> [INFO] Apache Royale: Royale Ant Tasks  SKIPPED
>
> [INFO] Apache Royale: RoyaleUnit Ant Tasks  SKIPPED
>
> [INFO] Apache Royale: Royale Maven Plugin . SKIPPED
>
> [INFO]
> 
>
> [INFO] BUILD FAILURE
>
> [INFO]
> 
>
> [INFO] Total time:  8.438 s
>
> [INFO] Finished at: 2019-09-25T18:35:49+02:00
>
> [INFO]
> 
>
> [ERROR] Failed to execute goal on project royale-compiler-parent: Could not
> resolve dependencies for project
> org.apache.royale.compiler:royale-compiler-parent:pom:0.9.6: Could not find
> artifact com.adobe.flash.framework:playerglobal:swc:20.0 in apache-release
> (
> https://repository.apache.org/content/repositories/releases) -> [Help 1]
>
> [ERROR]
>
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
>
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>

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

2019-09-22 Thread Josh Tynjala
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>


[DISCUSS] Release Apache Royale 0.9.6 RC2

2019-09-22 Thread Josh Tynjala
That was my original assumption, but it sounds like Carlos had issues
trying that.

- Josh

On Sunday, September 22, 2019, Piotr Zarzycki 
wrote:
> Josh,
>
> Are you saying that settings-template from repository should be enough to
> get stuff working for Carlos? I'm confused right now.
>
> Thanks,
> Piotr
>
> On Sun, Sep 22, 2019, 1:43 AM Josh Tynjala 
> wrote:
>
>> I'm guessing that the settings template isn't supposed to be required for
>> JS-only builds, similar to the other things discussed in this thread (or
>> the previous RC thread).
>>
>> I know that this file is needed to download the proprietary Adobe bits
>> (since Maven doesn't know where to find them by default), and that seemed
>> to be where your build failed.
>>
>> - Josh
>>
>> On Saturday, September 21, 2019, Carlos Rovira 
>> wrote:
>> > Thanks Josh,
>> >
>> > I just tried with Approve xml and get similar results (I copy here)
>> > I'll try using the setting, I forgot completely about it.. But this
means
>> > the instructions to build are wrong right?
>> >
>> >
>> > Here's my console output after try with the Approve xml script (mostly
>> the
>> > same as trying to build with maven):
>> >
>> > [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
>> > compiler-externc ---
>> >
>> > [INFO] Installing
>> >
>>
>>
/Users/carlosrovira/Downloads/testrc2/apache-royale-0.9.6-maven-src/royale-compiler/compiler-externc/target/compiler-externc-0.9.6.jar
>> > to
>> >
>>
>>
/Users/carlosrovira/.m2/repository/org/apache/royale/compiler/compiler-externc/0.9.6/compiler-externc-0.9.6.jar
>> >
>> > [INFO] Installing
>> >
>>
>>
/Users/carlosrovira/Downloads/testrc2/apache-royale-0.9.6-maven-src/royale-compiler/compiler-externc/pom.xml
>> > to
>> >
>>
>>
/Users/carlosrovira/.m2/repository/org/apache/royale/compiler/compiler-externc/0.9.6/compiler-externc-0.9.6.pom
>> >
>> > [INFO] Installing
>> >
>>
>>
/Users/carlosrovira/Downloads/testrc2/apache-royale-0.9.6-maven-src/royale-compiler/compiler-externc/target/compiler-externc-0.9.6-tests.jar
>> > to
>> >
>>
>>
/Users/carlosrovira/.m2/repository/org/apache/royale/compiler/compiler-externc/0.9.6/compiler-externc-0.9.6-tests.jar
>> >
>> > [INFO]
>> >
>> > [INFO] < org.apache.royale.compiler:compiler
>> >>-
>> >
>> > [INFO] Building Apache Royale: Compiler: Compiler 0.9.6
>> > [5/12]
>> >
>> > [INFO] [ jar
>> > ]-
>> >
>> > [WARNING] The POM for com.adobe.flash.framework:playerglobal:swc:20.0
is
>> > missing, no dependency information available
>> >
>> > [INFO]
>> >

>> >
>> > [INFO] Reactor Summary for Apache Royale: Compiler: Parent 0.9.6:
>> >
>> > [INFO]
>> >
>> > [INFO] Apache Royale: Compiler: Parent  SUCCESS [
>> > 2.102 s]
>> >
>> > [INFO] Apache Royale: Compiler: Compiler-Common ... SUCCESS [
>> > 4.555 s]
>> >
>> > [INFO] Apache Royale: Compiler: Test Utils  SUCCESS [
>> > 0.431 s]
>> >
>> > [INFO] Apache Royale: Compiler: Externc ... SUCCESS [
>> > 9.225 s]
>> >
>> > [INFO] Apache Royale: Compiler: Compiler .. FAILURE [
>> > 0.052 s]
>> >
>> > [INFO] Apache Royale: Compiler: Compiler-JX ... SKIPPED
>> >
>> > [INFO] Apache Royale: Compiler: SWFUtils .. SKIPPED
>> >
>> > [INFO] Apache Royale: Compiler: Debugger .. SKIPPED
>> >
>> > [INFO] Apache Royale: Compiler: OEM Layer . SKIPPED
>> >
>> > [INFO] Apache Royale: Royale Ant Tasks  SKIPPED
>> >
>> > [INFO] Apache Royale: RoyaleUnit Ant Tasks  SKIPPED
>> >
>> > [INFO] Apache Royale: Royale Maven Plugin . SKIPPED
>> >
>> > [INFO]
>> >

>> >
>> > [INFO] BUILD FAILURE
>> >
>> > [INFO]
>> >

>> >
>&

[DISCUSS] Release Apache Royale 0.9.6 RC2

2019-09-21 Thread Josh Tynjala
I'm guessing that the settings template isn't supposed to be required for
JS-only builds, similar to the other things discussed in this thread (or
the previous RC thread).

I know that this file is needed to download the proprietary Adobe bits
(since Maven doesn't know where to find them by default), and that seemed
to be where your build failed.

- Josh

On Saturday, September 21, 2019, Carlos Rovira 
wrote:
> Thanks Josh,
>
> I just tried with Approve xml and get similar results (I copy here)
> I'll try using the setting, I forgot completely about it.. But this means
> the instructions to build are wrong right?
>
>
> Here's my console output after try with the Approve xml script (mostly the
> same as trying to build with maven):
>
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> compiler-externc ---
>
> [INFO] Installing
>
/Users/carlosrovira/Downloads/testrc2/apache-royale-0.9.6-maven-src/royale-compiler/compiler-externc/target/compiler-externc-0.9.6.jar
> to
>
/Users/carlosrovira/.m2/repository/org/apache/royale/compiler/compiler-externc/0.9.6/compiler-externc-0.9.6.jar
>
> [INFO] Installing
>
/Users/carlosrovira/Downloads/testrc2/apache-royale-0.9.6-maven-src/royale-compiler/compiler-externc/pom.xml
> to
>
/Users/carlosrovira/.m2/repository/org/apache/royale/compiler/compiler-externc/0.9.6/compiler-externc-0.9.6.pom
>
> [INFO] Installing
>
/Users/carlosrovira/Downloads/testrc2/apache-royale-0.9.6-maven-src/royale-compiler/compiler-externc/target/compiler-externc-0.9.6-tests.jar
> to
>
/Users/carlosrovira/.m2/repository/org/apache/royale/compiler/compiler-externc/0.9.6/compiler-externc-0.9.6-tests.jar
>
> [INFO]
>
> [INFO] < org.apache.royale.compiler:compiler
>>-
>
> [INFO] Building Apache Royale: Compiler: Compiler 0.9.6
> [5/12]
>
> [INFO] [ jar
> ]-
>
> [WARNING] The POM for com.adobe.flash.framework:playerglobal:swc:20.0 is
> missing, no dependency information available
>
> [INFO]
> 
>
> [INFO] Reactor Summary for Apache Royale: Compiler: Parent 0.9.6:
>
> [INFO]
>
> [INFO] Apache Royale: Compiler: Parent  SUCCESS [
> 2.102 s]
>
> [INFO] Apache Royale: Compiler: Compiler-Common ... SUCCESS [
> 4.555 s]
>
> [INFO] Apache Royale: Compiler: Test Utils  SUCCESS [
> 0.431 s]
>
> [INFO] Apache Royale: Compiler: Externc ... SUCCESS [
> 9.225 s]
>
> [INFO] Apache Royale: Compiler: Compiler .. FAILURE [
> 0.052 s]
>
> [INFO] Apache Royale: Compiler: Compiler-JX ... SKIPPED
>
> [INFO] Apache Royale: Compiler: SWFUtils .. SKIPPED
>
> [INFO] Apache Royale: Compiler: Debugger .. SKIPPED
>
> [INFO] Apache Royale: Compiler: OEM Layer . SKIPPED
>
> [INFO] Apache Royale: Royale Ant Tasks  SKIPPED
>
> [INFO] Apache Royale: RoyaleUnit Ant Tasks  SKIPPED
>
> [INFO] Apache Royale: Royale Maven Plugin . SKIPPED
>
> [INFO]
> 
>
> [INFO] BUILD FAILURE
>
> [INFO]
> 
>
> [INFO] Total time:  16.690 s
>
> [INFO] Finished at: 2019-09-21T15:33:35+02:00
>
> [INFO]
> 
>
> [ERROR] Failed to execute goal on project compiler: Could not resolve
> dependencies for project org.apache.royale.compiler:compiler:jar:0.9.6:
> Failure to find com.adobe.flash.framework:playerglobal:swc:20.0 in
> https://repository.apache.org/content/repositories/releases was cached in
> the local repository, resolution will not be reattempted until the update
> interval of apache-release has elapsed or updates are forced -> [Help 1]
>
> [ERROR]
>
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
-e
> switch.
>
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
> [ERROR]
>
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
>
> [ERROR] [Help 1]
>
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
>
> [ERROR]
>
> [ERROR] After correcting the problems, you can resume the build with the
> command
>
> [ERROR]   mvn  -rf :compiler
>
>
> BUILD FAILED
>
> /Users/carlosrovira/Downloads/testrc2/ApproveRoyale.xml:778: The following
> error occurred while executing this line:
>
> /Users/carlosrovira/Downloads/testrc2/ApproveRoyale.xml:789: exec
returned:
> 1
>
>
> Total time: 25 minutes 57 seconds
>
> macbookpro:testrc2 carlosrovira$
>

-- 
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


Re: [VOTE] Release Apache Royale 0.9.6 RC2

2019-09-21 Thread Josh Tynjala
You need to use settings-template.xml to get the Adobe stuff when building
the compiler with Maven.

- Josh

On Saturday, September 21, 2019, Carlos Rovira 
wrote:
> Hi,
>
> having the time to try RC2. I'm having the following issues. In RC1 I
tried
> ANT and all went ok. Know as Piotr suggest I'm trying to build with Maven
> with a clean(empty) .m2.
>
> packaged to test in RC2 is: apache-royale-0.9.6-src.tar.gz
>
> Instructions in src are the following:
>
> Building Royale With Apache Maven
>
> =
>
>
> Royale requires Maven 3.3.9 or greater to be installed on your computer.
>
>
> To build Royale with Apache Maven, run Maven in the 3 folders as follows:
>
>
> royale-compiler:  mvn clean install -P -main,utils
>
> royale-compiler:  mvn clean install
>
> royale-typedefs:  mvn clean install
>
> royale-asjs:  mvn clean install
>
>
> When complete, you should be able to use the Maven archetypes in
> royale-asjs/archetypes
>
> to build Royale applications.
>
>
>
>  from downloaded src/royale-compiler folder I run first:
>
> mvn clean install -P -main,utils
>
> This was ok
>
> Then in the same compiler folder run:
>
> mvn clean install
>
> This time I get this error:
>
>
> [*INFO*]
> **
>
> [*INFO*] *Reactor Summary for Apache Royale: Compiler: Parent 0.9.6:*
>
> [*INFO*]
>
> [*INFO*] Apache Royale: Compiler: Parent  *SUCCESS* [
> 1.763 s]
>
> [*INFO*] Apache Royale: Compiler: Compiler-Common ... *SUCCESS*
> [01:07 min]
>
> [*INFO*] Apache Royale: Compiler: Test Utils  *SUCCESS* [
> 2.307 s]
>
> [*INFO*] Apache Royale: Compiler: Externc ... *SUCCESS* [
> 49.839 s]
>
> [*INFO*] Apache Royale: Compiler: Compiler .. *FAILURE* [
> 8.878 s]
>
> [*INFO*] Apache Royale: Compiler: Compiler-JX ... *SKIPPED*
>
> [*INFO*] Apache Royale: Compiler: SWFUtils .. *SKIPPED*
>
> [*INFO*] Apache Royale: Compiler: Debugger .. *SKIPPED*
>
> [*INFO*] Apache Royale: Compiler: OEM Layer . *SKIPPED*
>
> [*INFO*] Apache Royale: Royale Ant Tasks  *SKIPPED*
>
> [*INFO*] Apache Royale: RoyaleUnit Ant Tasks  *SKIPPED*
>
> [*INFO*] Apache Royale: Royale Maven Plugin . *SKIPPED*
>
> [*INFO*]
> **
>
> [*INFO*] *BUILD FAILURE*
>
> [*INFO*]
> **
>
> [*INFO*] Total time:  02:18 min
>
> [*INFO*] Finished at: 2019-09-21T12:51:06+02:00
>
> [*INFO*]
> **
>
> [*ERROR*] Failed to execute goal on project compiler: *Could not resolve
> dependencies for project org.apache.royale.compiler:compiler:jar:0.9.6:
> Could not find artifact com.adobe.flash.framework:playerglobal:swc:20.0 in
> apache-release (
https://repository.apache.org/content/repositories/releases
> <https://repository.apache.org/content/repositories/releases>)* -> *[Help
> 1]*
>
> [*ERROR*]
>
> [*ERROR*] To see the full stack trace of the errors, re-run Maven with the
> *-e* switch.
>
> [*ERROR*] Re-run Maven using the *-X* switch to enable full debug logging.
>
>
>
>
>
>
> El vie., 20 sept. 2019 a las 18:24, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
>> Yes sure. I would like to hear from others what they think.
>>
>> Personally much worst to me is the fact that we didn't release SDK in
>> several months. I would rather spend 5 minutes on writing email to
instruct
>> user who has problem with building SDK than spend another 4 hours on
>> preparing and testing another RC - even if someone is paying me for that.
>>
>> Let's hear from others.
>>
>> Thanks,
>> Piotr
>>
>> pt., 20 wrz 2019 o 18:18 Alex Harui 
napisał(a):
>>
>> > I don't know.  Would be nice to get other's opinions.  We make these
>> > attempts to lower the effort to get the source and work with it, so
when
>> > that workflow isn't working it doesn't make us look good.  FWIW, if you
>> > clone the repo and try to build without the Adobe stuff, that should
>> > probably fail the same way.
>> >
>> > -Alex
>> >
>> > On 9/19/19, 11:21 PM, "Piotr Zarzycki" 
>> wrote:
>> >
>> > Hi Alex,
>> >
>> > I'm m

Re: [VOTE] Release Apache Royale 0.9.6 RC2

2019-09-20 Thread Josh Tynjala
I thought about pushing it before Piotr even asked, but I figured that a
solution more like yours was necessary. I could tell that my change would
require SWF, and I know that we want a JS-only option too.

- Josh

On Friday, September 20, 2019, Alex Harui  wrote:
> Correct.  ApproveRoyale.xml is not even in the source package.   I just
didn't want Josh to push that change.
>
> -Alex
>
> On 9/20/19, 9:16 AM, "Piotr Zarzycki"  wrote:
>
> Alex,
>
> Second issue is a blocker only for someone who wanted to developing
Royale
> SDK, from my perspective it is not a blocker for a release.
>
> Thanks,
> Piotr
>
> pt., 20 wrz 2019 o 18:13 Alex Harui 
napisał(a):
>
> > Specifically, requiring the profile generate-swcs-for-swf will fail
when
> > running ApproveRoyale.xml in a js-only configuration.
> >
> > My commit last night detects env.AIR_HOME and selects the set of
profiles
> > to use.  I saw it work for both js-only and js-swf configurations.
> >
> > -Alex
> >
> > On 9/20/19, 9:02 AM, "Piotr Zarzycki" 
wrote:
> >
> > What won't work exactly ? Build ? Or Royale for user IDE ?
> >
> > pt., 20 wrz 2019 o 17:57 Alex Harui 
> > napisał(a):
> >
> > > Please don't commit that.  It won't work for js-only.
> > >
> > > I pushed a solution for both last night.
> > >
> > > Thanks,
> > > -Alex
> > >
> > > On 9/19/19, 11:20 PM, "Piotr Zarzycki" <
piotrzarzyck...@gmail.com>
> > wrote:
> > >
> > > Hi Josh,
> > >
> > > Maybe you could commit that to develop?
> > >
> > > Thanks,
> > > Piotr
> > >
> > > czw., 19 wrz 2019 o 18:19 Josh Tynjala <
> > joshtynj...@bowlerhat.dev>
> > > napisał(a):
> > >
> > > > If anyone else has problems with the Maven build when
running
> > the
> > > > ApproveRoyale.xml script, I was able to fix it by
modifying
> > this
> >     > section
> > > > where the framework is built:
> > > >
> > > >  > > > dir="${basedir}/${maven.package.url.name}/royale-asjs"
> > > > failonerror="true">
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > > > --
> > > > Josh Tynjala
> > > > Bowler Hat LLC <
> > >
> >
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C295afd2376244230fd8c08d73de5f4ac%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637045930174281142sdata=B8zm7Zv%2FWJGSSdLUH9bQo%2FgDnGRBHfy5ULTxufNqE5Q%3Dreserved=0
> > > >
> > > >
> > > >
> > > > On Thu, Sep 19, 2019 at 1:08 AM Apache Royale CI Server
<
> > > > apacheroyal...@gmail.com> wrote:
> > > >
> > > > > This is the discussion thread.
> > > > >
> > > > > Thanks,
> > > > > Piotr
> > > >
> > >
> > >
> > > --
> > >
> > > Piotr Zarzycki
> > >
> > > Patreon: *
> > >
> >
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzyckidata=02%7C01%7Caharui%40adobe.com%7C295afd2376244230fd8c08d73de5f4ac%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637045930174281142sdata=sRFTeemaBdq%2BS83rK52vAIuAmWMmZJ42Agi9YDAjyQI%3Dreserved=0
> > > <
> > >
> >
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzyckidata=02%7C01%7Caharui%40adobe.com%7C295afd2376244230fd8c08d73de5f4ac%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637045930174281142sdata=sRFTeemaBdq%2BS83rK52vAIuAmWMmZJ42Agi9YDAjyQI%3Dreserved=0
> > > >*
> > >
> > >
> > >
> >
> > --
> >
>

[DISCUSS] Release Apache Royale 0.9.6 RC2

2019-09-19 Thread Josh Tynjala
If anyone else has problems with the Maven build when running the
ApproveRoyale.xml script, I was able to fix it by modifying this section
where the framework is built:








--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Thu, Sep 19, 2019 at 1:08 AM Apache Royale CI Server <
apacheroyal...@gmail.com> wrote:

> This is the discussion thread.
>
> Thanks,
> Piotr


[VOTE] Release Apache Royale 0.9.6 RC2

2019-09-19 Thread Josh Tynjala
+1 (binding)
Package
https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc2/apache-royale-0.9.6-src.tar.gz
Java 1.8
OS: Mac OS X x86_64 10.14.6
Source kit signatures match: y
Source kit builds: y
README is ok: y
RELEASE_NOTES is ok: y
NOTICE is ok: y
LICENSE is ok: y
No unapproved licenses or archives: y
No unapproved binaries: y

Package
https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc2/binaries/apache-royale-0.9.6-bin-js-swf.tar.gz
Binary kit signatures match: y
NOTICE is ok: y
LICENSE is ok: y
No unapproved licenses or archives in binary package: y
No unapproved binaries in binary package: y

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Thu, Sep 19, 2019 at 1:08 AM Apache Royale CI Server <
apacheroyal...@gmail.com> wrote:

> Hi,
>
> This is the vote for the 0.9.6 release of Apache Royale.
>
> The release candidate can be found here;
> https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc2/
>
> Before voting please review the section,'What are the ASF requirements on
> approving a release?', at:
> http://www.apache.org/dev/release.html#approving-a-release
>
> At a minimum you would be expected to check that:
> - SHA and signed packages are correct
> - README, RELEASE_NOTES, NOTICE and LICENSE files are all fine
> - That the build script completes successfully
> - That you can compile and cross-compile a simple example using the SDK.
>
> The KEYS file is at https://dist.apache.org/repos/dist/release/royale/KEYS
>
> The source package is a combination of the 3 main Royale repos.
>
> To use the binary package, unzip it into a folder.  The -js package is
> ready-to-use in an IDE or command-line.  If you need SWF output, use the
> -js-swf package and use Apache Ant to run the InstallAdobeSDKs script via:
>   ant -f InstallAdobeSDKs.xml
>
> You may also get the binary packages via NPM.  The -js package can be
> installed via:
>
> npm install
> https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc2/binaries/apache-royale-0.9.6-bin-js.tar.gz
> -g
>
> The full package with SWF support can be installed via:
>
> npm install
> https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc2/binaries/apache-royale-0.9.6-bin-js-swf.tar.gz
> -g
>
> Maven artifacts are staged here:
> https://repository.apache.org/content/repositories/orgapacheroyale-1057
>
> Please vote to approve this release:
> +1 Approve the release
> -1 Disapprove the release (please provide specific comments to why)
>
> This vote will be open for 72 hours or until a result can be called.
>
> The vote passes if there is:
> - At least 3 +1 votes from the PMC
> - More positive votes than negative votes
>
> Remember that this is a 'beta-quality' release so expect there
> will be many bugs found.  IMO the goal is not to try to find and fix bugs
> in the RC, but to make sure we have the packaging right, and enough
> functionality that folks will have some success trying to use it.
>
> People who are not in PMC are also encouraged to test out the release and
> vote, although their votes will not be binding, they can influence how the
> PMC votes.
>
> When voting please indicate what OS, IDE, Flash Player version and AIR
> version you tested with.
>
> For your convenience, there is an ant script that automates the common
> steps to validate a release.  Instead of individually downloading the
> package and signature files, unzipping, etc, you can instead:
> 1) create an empty folder,
> 2) download into that folder this file:
> https://dist.apache.org/repos/dist/dev/royale/0.9.6/rc2/ApproveRoyale.xml
> 3) run the script:
>ant -e -f ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=2
>If you want to test SWF support during the approval, use:
>ant -e -f ApproveRoyale.xml -Drelease.version=0.9.6 -Drc=2
> -Duse-flash=true
>
> You are not required to use this script, and more testing of the packages
> and build results are always encouraged.
>
> Please put all discussion about this release in the DISCUSSION thread not
> this VOTE thread.
>
> Thanks,
> Piotr


New RoyaleUnit commits on develop should not go into release/0.9.6

2019-09-18 Thread Josh Tynjala
I'm starting to add support for asynchronous tests to RoyaleUnit in the
develop branch. It's still a work in progress, and things may be unstable.
Please do not cherry pick any of these RoyaleUnit commits into release/
0.9.6. Thanks!

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


Re: [DISCUSS] Release Apache Royale 0.9.6 RC1

2019-09-18 Thread Josh Tynjala
Maven with -X:

https://paste.apache.org/ffq08

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Sep 18, 2019 at 8:44 AM Piotr Zarzycki 
wrote:

> Thanks Josh. In logs there isn't any url from which you are downloading
> artifacts. It means probably you are using cached one. One option is to
> remove cached artifacts and run build, the second is run build with -X.
> It doesn't have to be full build - it's the matter of see what actually
> maven do.
>
> śr., 18 wrz 2019 o 16:40 Josh Tynjala 
> napisał(a):
>
> > Here's the console output from the Maven section of the build:
> >
> > https://paste.apache.org/cczye
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Tue, Sep 17, 2019 at 10:20 PM Alex Harui 
> > wrote:
> >
> > > I assume that wasn't the whole log.  I think we want to see the part
> > where
> > > it builds Core, we only see the last bit of Core.  Core looks like it
> > > thought it was in js-only config and didn't build a swf swc and/or
> > Binding
> > > thinks it is building swf swcs and is looking for Core's swf swc.
> > >
> > > FWIW, I am having a bunch of other build issues related to js-only for
> > Ant
> > > for the ASDoc example.  It worked in the past because I still had
> > > PLAYERGLOBAL_HOME set in the environment, but when I took that away a
> > bunch
> > > of new things cropped up.  Could be a  day or two of work.  We could
> > still
> > > approve the release and folks who want js-only will have to not build
> > ASDoc.
> > >
> > > -Alex
> > >
> > > On 9/17/19, 8:59 PM, "Piotr Zarzycki" 
> > wrote:
> > >
> > > Hi Josh,
> > >
> > >     Do you have in your Maven config setup link to Maven artifacts?
> Cause
> > > error
> > > is saying that it was attempt of downloading them from Snapshot.
> > > However
> > > Core build successfully, so I'm a bit confused.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > On Tue, Sep 17, 2019, 11:47 PM Josh Tynjala <
> > joshtynj...@bowlerhat.dev
> > > >
> > > wrote:
> > >
> > > > Unfortunately, I'm seeing that the Maven part of ApproveRoyale is
> > > failing
> > > > too. Here's the end of my console output:
> > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2F83mivdata=02%7C01%7Caharui%40adobe.com%7C5418ae5d4cb94b454ab208d73beca2c4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637043759850631985sdata=j%2FYDlKQ7Tx54p2PJfg2tEoGg2I5Mi19BMB5fFcZcKy4%3Dreserved=0
> > > >
> > > > --
> > > > Josh Tynjala
> > > > Bowler Hat LLC <
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C5418ae5d4cb94b454ab208d73beca2c4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637043759850631985sdata=%2BTdmGXZr5uiQaJ36dU8QeOQLGIpR8adX5ktk8%2FRo8ME%3Dreserved=0
> > > >
> > > >
> > > >
> > > > On Tue, Sep 17, 2019 at 2:22 PM Josh Tynjala <
> > > joshtynj...@bowlerhat.dev>
> > > > wrote:
> > > >
> > > > > Getting the following error when running the ApproveRoyale ant
> > > script...
> > > > >
> > > > > Error: unable to open
> > > > >
> > > >
> > >
> >
> '/Users/joshtynjala/Desktop/royale/apache-royale-0.9.6-src/royale-asjs/examples/royale/CreditCardValidatorExample/src/main/royale/App.mxml'.
> > > > >
> > > > > Seems to be caused by this line in build.xml from
> > > > > CreditCardValidatorExample:
> > > > >
> > > > > 
> > > > >
> > > > > There is no App.mxml, but there is a
> > > CreditCardValidatorExample.mxml, so
> > > > I
> > > > > think that the value is supposed to be
> > "CreditCardValidatorExample"
> > > > instead:
> > > > >
> > > > > 
> > > > >
> > > > > I just pushed a commit to develop to fix that for the next
> > release.
> > > > >
> > > > > I will locally adjust ApproveRoyale to skip the examples and
>

Re: [DISCUSS] Release Apache Royale 0.9.6 RC1

2019-09-18 Thread Josh Tynjala
Here's the console output from the Maven section of the build:

https://paste.apache.org/cczye

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Sep 17, 2019 at 10:20 PM Alex Harui 
wrote:

> I assume that wasn't the whole log.  I think we want to see the part where
> it builds Core, we only see the last bit of Core.  Core looks like it
> thought it was in js-only config and didn't build a swf swc and/or Binding
> thinks it is building swf swcs and is looking for Core's swf swc.
>
> FWIW, I am having a bunch of other build issues related to js-only for Ant
> for the ASDoc example.  It worked in the past because I still had
> PLAYERGLOBAL_HOME set in the environment, but when I took that away a bunch
> of new things cropped up.  Could be a  day or two of work.  We could still
> approve the release and folks who want js-only will have to not build ASDoc.
>
> -Alex
>
> On 9/17/19, 8:59 PM, "Piotr Zarzycki"  wrote:
>
> Hi Josh,
>
> Do you have in your Maven config setup link to Maven artifacts? Cause
> error
> is saying that it was attempt of downloading them from Snapshot.
> However
> Core build successfully, so I'm a bit confused.
>
> Thanks,
> Piotr
>
> On Tue, Sep 17, 2019, 11:47 PM Josh Tynjala  >
> wrote:
>
> > Unfortunately, I'm seeing that the Maven part of ApproveRoyale is
> failing
> > too. Here's the end of my console output:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2F83mivdata=02%7C01%7Caharui%40adobe.com%7C5418ae5d4cb94b454ab208d73beca2c4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637043759850631985sdata=j%2FYDlKQ7Tx54p2PJfg2tEoGg2I5Mi19BMB5fFcZcKy4%3Dreserved=0
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C5418ae5d4cb94b454ab208d73beca2c4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637043759850631985sdata=%2BTdmGXZr5uiQaJ36dU8QeOQLGIpR8adX5ktk8%2FRo8ME%3Dreserved=0
> >
> >
> >
> > On Tue, Sep 17, 2019 at 2:22 PM Josh Tynjala <
> joshtynj...@bowlerhat.dev>
> > wrote:
> >
> > > Getting the following error when running the ApproveRoyale ant
> script...
> > >
> > > Error: unable to open
> > >
> >
> '/Users/joshtynjala/Desktop/royale/apache-royale-0.9.6-src/royale-asjs/examples/royale/CreditCardValidatorExample/src/main/royale/App.mxml'.
> > >
> > > Seems to be caused by this line in build.xml from
> > > CreditCardValidatorExample:
> > >
> > > 
> > >
> > > There is no App.mxml, but there is a
> CreditCardValidatorExample.mxml, so
> > I
> > > think that the value is supposed to be "CreditCardValidatorExample"
> > instead:
> > >
> > > 
> > >
> > > I just pushed a commit to develop to fix that for the next release.
> > >
> > > I will locally adjust ApproveRoyale to skip the examples and
> finish the
> > > rest of the approval process. Assuming that everything else
> completes
> > > successfully, a broken example build script is not enough to
> prevent me
> > > from approving this release candidate.
> > >
> > > --
> > > Josh Tynjala
> > > Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C5418ae5d4cb94b454ab208d73beca2c4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637043759850631985sdata=%2BTdmGXZr5uiQaJ36dU8QeOQLGIpR8adX5ktk8%2FRo8ME%3Dreserved=0
> >
> > >
> > >
> > > On Tue, Sep 17, 2019 at 6:43 AM Apache Royale CI Server <
> > > apacheroyal...@gmail.com> wrote:
> > >
> > >> This is the discussion thread.
> > >>
> > >> Thanks,
> > >> Piotr
> > >
> > >
> >
>
>
>


Re: [DISCUSS] Release Apache Royale 0.9.6 RC1

2019-09-18 Thread Josh Tynjala
I don't know enough about Maven to answer your question, Piotr. All I can
say is that I have successfully run the ApproveRoyale script for previous
releases, and I don't think that I have changed any kind of global Maven
settings on this machine since then.

I can run it again and share the entire log, if that will help anyone,
though.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Sep 17, 2019 at 8:59 PM Piotr Zarzycki 
wrote:

> Hi Josh,
>
> Do you have in your Maven config setup link to Maven artifacts? Cause error
> is saying that it was attempt of downloading them from Snapshot. However
> Core build successfully, so I'm a bit confused.
>
> Thanks,
> Piotr
>
> On Tue, Sep 17, 2019, 11:47 PM Josh Tynjala 
> wrote:
>
> > Unfortunately, I'm seeing that the Maven part of ApproveRoyale is failing
> > too. Here's the end of my console output:
> >
> > https://paste.apache.org/83miv
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Tue, Sep 17, 2019 at 2:22 PM Josh Tynjala 
> > wrote:
> >
> > > Getting the following error when running the ApproveRoyale ant
> script...
> > >
> > > Error: unable to open
> > >
> >
> '/Users/joshtynjala/Desktop/royale/apache-royale-0.9.6-src/royale-asjs/examples/royale/CreditCardValidatorExample/src/main/royale/App.mxml'.
> > >
> > > Seems to be caused by this line in build.xml from
> > > CreditCardValidatorExample:
> > >
> > > 
> > >
> > > There is no App.mxml, but there is a CreditCardValidatorExample.mxml,
> so
> > I
> > > think that the value is supposed to be "CreditCardValidatorExample"
> > instead:
> > >
> > > 
> > >
> > > I just pushed a commit to develop to fix that for the next release.
> > >
> > > I will locally adjust ApproveRoyale to skip the examples and finish the
> > > rest of the approval process. Assuming that everything else completes
> > > successfully, a broken example build script is not enough to prevent me
> > > from approving this release candidate.
> > >
> > > --
> > > Josh Tynjala
> > > Bowler Hat LLC <https://bowlerhat.dev>
> > >
> > >
> > > On Tue, Sep 17, 2019 at 6:43 AM Apache Royale CI Server <
> > > apacheroyal...@gmail.com> wrote:
> > >
> > >> This is the discussion thread.
> > >>
> > >> Thanks,
> > >> Piotr
> > >
> > >
> >
>


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

2019-09-18 Thread Josh Tynjala
> 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 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
> > 

Re: [DISCUSS] Release Apache Royale 0.9.6 RC1

2019-09-17 Thread Josh Tynjala
Unfortunately, I'm seeing that the Maven part of ApproveRoyale is failing
too. Here's the end of my console output:

https://paste.apache.org/83miv

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Sep 17, 2019 at 2:22 PM Josh Tynjala 
wrote:

> Getting the following error when running the ApproveRoyale ant script...
>
> Error: unable to open
> '/Users/joshtynjala/Desktop/royale/apache-royale-0.9.6-src/royale-asjs/examples/royale/CreditCardValidatorExample/src/main/royale/App.mxml'.
>
> Seems to be caused by this line in build.xml from
> CreditCardValidatorExample:
>
> 
>
> There is no App.mxml, but there is a CreditCardValidatorExample.mxml, so I
> think that the value is supposed to be "CreditCardValidatorExample" instead:
>
> 
>
> I just pushed a commit to develop to fix that for the next release.
>
> I will locally adjust ApproveRoyale to skip the examples and finish the
> rest of the approval process. Assuming that everything else completes
> successfully, a broken example build script is not enough to prevent me
> from approving this release candidate.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Tue, Sep 17, 2019 at 6:43 AM Apache Royale CI Server <
> apacheroyal...@gmail.com> wrote:
>
>> This is the discussion thread.
>>
>> Thanks,
>> Piotr
>
>


Re: [DISCUSS] Release Apache Royale 0.9.6 RC1

2019-09-17 Thread Josh Tynjala
I'd rather not accidentally commit something to a release branch that
shouldn't go there, so to stay safe, I'll keep committing to develop first.
We can always cherry pick if needed.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Sep 17, 2019 at 2:29 PM Alex Harui  wrote:

> Hmm.  I thought I'd fixed that.  I swear I had all examples building.
>
> Anyway, fixes like these should be going in the release branch, not
> develop, IMO.
>
> Thanks,
> -Alex
>
> On 9/17/19, 2:22 PM, "Josh Tynjala"  wrote:
>
> Getting the following error when running the ApproveRoyale ant
> script...
>
> Error: unable to open
>
> '/Users/joshtynjala/Desktop/royale/apache-royale-0.9.6-src/royale-asjs/examples/royale/CreditCardValidatorExample/src/main/royale/App.mxml'.
>
> Seems to be caused by this line in build.xml from
> CreditCardValidatorExample:
>
> 
>
> There is no App.mxml, but there is a CreditCardValidatorExample.mxml,
> so I
> think that the value is supposed to be "CreditCardValidatorExample"
> instead:
>
> 
>
> I just pushed a commit to develop to fix that for the next release.
>
> I will locally adjust ApproveRoyale to skip the examples and finish the
> rest of the approval process. Assuming that everything else completes
> successfully, a broken example build script is not enough to prevent me
> from approving this release candidate.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C3a8e9e313e9744a4706a08d73bb525db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637043521555610433sdata=z%2BrnbF8mRz%2Bh%2Fe54Ta9HaAvaqh2rLiMVQPpcx0VPRUc%3Dreserved=0
> >
>
>
> On Tue, Sep 17, 2019 at 6:43 AM Apache Royale CI Server <
> apacheroyal...@gmail.com> wrote:
>
> > This is the discussion thread.
> >
> > Thanks,
> > Piotr
>
>
>


Re: [DISCUSS] Release Apache Royale 0.9.6 RC1

2019-09-17 Thread Josh Tynjala
Getting the following error when running the ApproveRoyale ant script...

Error: unable to open
'/Users/joshtynjala/Desktop/royale/apache-royale-0.9.6-src/royale-asjs/examples/royale/CreditCardValidatorExample/src/main/royale/App.mxml'.

Seems to be caused by this line in build.xml from
CreditCardValidatorExample:



There is no App.mxml, but there is a CreditCardValidatorExample.mxml, so I
think that the value is supposed to be "CreditCardValidatorExample" instead:



I just pushed a commit to develop to fix that for the next release.

I will locally adjust ApproveRoyale to skip the examples and finish the
rest of the approval process. Assuming that everything else completes
successfully, a broken example build script is not enough to prevent me
from approving this release candidate.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Sep 17, 2019 at 6:43 AM Apache Royale CI Server <
apacheroyal...@gmail.com> wrote:

> This is the discussion thread.
>
> Thanks,
> Piotr


Re: Release vote/discuss reply-to address

2019-09-17 Thread Josh Tynjala
Hmm... looking at the headers in Gmail seems to indicate that reply-to is
actually set to the dev list. I wonder why Gmail is ignoring it...

One thing that I see is that reply-to is showing up in the UI like this:

reply-to: dev@royale.apache.org, dev@royale.apache.org

Maybe Gmail is getting confused because it is set twice.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Sep 17, 2019 at 1:42 PM Josh Tynjala 
wrote:

> I just realized that several replies that I sent to the 0.9.6 discuss
> thread were lost because I was unexpectedly replying to
> apacheroyal...@gmail.com.
>
> When the server sends out vote/discuss threads, is it possible to set the
> reply-to address to dev@royale.apache.org?
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>


Re: [DISCUSS] Release Apache Royale 0.9.6 RC1

2019-09-17 Thread Josh Tynjala
I downloaded the KEYS file and imported it.

gpg --import KEYS

However, when I ran the ApproveRoyale.xml script after that, I got this
error:

gpg: Signature made 09/17/19 05:01:35 Pacific Daylight Time
gpg:using RSA key B0A9098B61A39B1E8D5B7C9976CF6A81D5C80F47
gpg: Can't check signature: No public key

Eventually, I figured out how to manually import Piotr's signature like
this, and then I could continue the approval script into later steps:

gpg --keyserver keys.gnupg.net --recv-keys D5C80F47

Not sure why it fails with the KEYS file, but maybe Piotr needs to update
his signature somewhere to fix the KEYS file?

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Sep 17, 2019 at 6:43 AM Apache Royale CI Server <
apacheroyal...@gmail.com> wrote:

> This is the discussion thread.
>
> Thanks,
> Piotr


Release vote/discuss reply-to address

2019-09-17 Thread Josh Tynjala
I just realized that several replies that I sent to the 0.9.6 discuss
thread were lost because I was unexpectedly replying to
apacheroyal...@gmail.com.

When the server sends out vote/discuss threads, is it possible to set the
reply-to address to dev@royale.apache.org?

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


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

2019-09-16 Thread Josh Tynjala
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://bowlerhat.dev>


On Mon, Sep 16, 2019 at 11:13 AM Josh Tynjala 
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://bowlerhat.dev>
>
>
> 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
>> perspective,
>> it looks like quoting the public variable's name is our best option.
>>
>> Similar to how we handle js-dynamic-access-unknown-members, we can
>> quote
>> the public variable's name when getting or setting it in JS:
>>
>> var foo = new Foo();
>> foo["bar"] = 2;
>> var baz = foo["bar"];
>>
>> In this case, we also need to quote the public variable's name when
>> declaring it on the prototype:
>>
>> Foo.prototype["bar"] = 3;
>>
>> I did some tests, and I can confirm that Closure will preserve the
>> public
>> variable's name, similar to how it preserves the names when we declare
>> public getters and setters. I'm going to make this change and turn off
>> warn-public-vars.
>>
>> (To be clear, I'm only going to change how the emitter handles public
>> variables specifically. Behavior for other types of property access
>> will
>> remain the same.)
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC <
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741705917sdata=oIgajcsJSzyrmkeIOX%2BcuPe9lVt7iukyGAhrLdlVmvY%3Dreserved=0
>> >
>>
>>
>> On Mon, Sep 16, 2019 at 10:06 AM Alex Harui > >
>> wrote:
>>
>> > Feel free to revisit.  IIRC, the issue is that you can't @export a
>> "var".
>> > You can only @export a function because @export sets up a reference
>> to the
>> > renamed function and you can't set up a reference to simple vars.
>> >
>> > Class Josh {
>>     >   Static var foo:int = 1;
>> > }
>> >
>> > Compiles to:
>> >
>> >   Josh.foo = 1;
>> >
>> > Gets renamed to:
>> >
>> >   a.b = 1;
>> >
>> > The @export will result in:

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

2019-09-16 Thread Josh Tynjala
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://bowlerhat.dev>


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
> perspective,
> it looks like quoting the public variable's name is our best option.
>
> Similar to how we handle js-dynamic-access-unknown-members, we can
> quote
> the public variable's name when getting or setting it in JS:
>
> var foo = new Foo();
> foo["bar"] = 2;
> var baz = foo["bar"];
>
> In this case, we also need to quote the public variable's name when
> declaring it on the prototype:
>
> Foo.prototype["bar"] = 3;
>
> I did some tests, and I can confirm that Closure will preserve the
> public
> variable's name, similar to how it preserves the names when we declare
> public getters and setters. I'm going to make this change and turn off
> warn-public-vars.
>
> (To be clear, I'm only going to change how the emitter handles public
> variables specifically. Behavior for other types of property access
> will
> remain the same.)
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741705917sdata=oIgajcsJSzyrmkeIOX%2BcuPe9lVt7iukyGAhrLdlVmvY%3Dreserved=0
> >
>
>
> On Mon, Sep 16, 2019 at 10:06 AM Alex Harui 
> wrote:
>
> > Feel free to revisit.  IIRC, the issue is that you can't @export a
> "var".
> > You can only @export a function because @export sets up a reference
> to the
> > renamed function and you can't set up a reference to simple vars.
> >
> > Class Josh {
> >   Static var foo:int = 1;
> > }
> >
> > Compiles to:
> >
> >   Josh.foo = 1;
> >
> > Gets renamed to:
> >
> >   a.b = 1;
> >
> > The @export will result in:
> >
> >   ['Josh']['foo'] = a.b;
> >
> > And then code that does:
> >
> >   Josh.foo = 2;
> >
> > Will not change
> >
> >   Console.log(a.b); // 1 (not 2)
> >
> > Of course, I could be wrong..
> >
> > -Alex
> >
> > On 9/16/19, 9:57 AM, "Josh Tynjala" 
> wrote:
> >
> > I guess I was assuming that @nocollapse combined with @export
> would
> > make it
> > also prevent renaming. I suppose I can test it and see what
> happens.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741715916sdata=RzTt0oXl8VlOFQx61iqQmpTnZjzRQ83WA0nhC14VaBU%3Dreserved=0
> > >
> >
> >
> > On Mon, Sep 16, 2019 at 9:54 AM Alex Harui
> 
> > wrote:
> >
> > > IMO, the -warn-public-vars is more about the "renaming"
> mentioned i

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

2019-09-16 Thread Josh Tynjala
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 perspective,
it looks like quoting the public variable's name is our best option.

Similar to how we handle js-dynamic-access-unknown-members, we can quote
the public variable's name when getting or setting it in JS:

var foo = new Foo();
foo["bar"] = 2;
var baz = foo["bar"];

In this case, we also need to quote the public variable's name when
declaring it on the prototype:

Foo.prototype["bar"] = 3;

I did some tests, and I can confirm that Closure will preserve the public
variable's name, similar to how it preserves the names when we declare
public getters and setters. I'm going to make this change and turn off
warn-public-vars.

(To be clear, I'm only going to change how the emitter handles public
variables specifically. Behavior for other types of property access will
remain the same.)

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Sep 16, 2019 at 10:06 AM Alex Harui 
wrote:

> Feel free to revisit.  IIRC, the issue is that you can't @export a "var".
> You can only @export a function because @export sets up a reference to the
> renamed function and you can't set up a reference to simple vars.
>
> Class Josh {
>   Static var foo:int = 1;
> }
>
> Compiles to:
>
>   Josh.foo = 1;
>
> Gets renamed to:
>
>   a.b = 1;
>
> The @export will result in:
>
>   ['Josh']['foo'] = a.b;
>
> And then code that does:
>
>   Josh.foo = 2;
>
> Will not change
>
>   Console.log(a.b); // 1 (not 2)
>
> Of course, I could be wrong..
>
> -Alex
>
> On 9/16/19, 9:57 AM, "Josh Tynjala"  wrote:
>
> I guess I was assuming that @nocollapse combined with @export would
> make it
> also prevent renaming. I suppose I can test it and see what happens.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cd0c7fd54329c4f08a85708d73ac6ea33%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042498316114014sdata=N30d559D3wJpJJ5%2BPNSp%2BLR5jg64caj3rCByjf41iyk%3Dreserved=0
> >
>
>
> On Mon, Sep 16, 2019 at 9:54 AM Alex Harui 
> wrote:
>
> > IMO, the -warn-public-vars is more about the "renaming" mentioned in
> that
> > link than the "collapse".
> >
> > If you have:
> >
> > Package {
> > Class Josh {
> >   Public var name:String;
> > }
> > Var foo:Josh = new Josh();
> > foo.name = 'josh';
> >
> > I don't think @nocollapse will prevent renaming the 'name' property
> to
> > something random like 'jt':
> >
> > Var foo = new Josh();
> > foo.jt = 'josh';
> >
> > AIUI, @nocollapse is used for things that are not obviously
> mutable.  If
> > you look in the globals in the browser debugger for any js-debug
> version of
> > a Royale app, you can see the structure:
> >
> >org.apache.royale.core
> >
> > It was created by code similar to:
> >
> > window.org = {};
> > window.org.apache = {};
> > window.org.apache.royale = {};
> > window.org.apache.royale.core = {};
> >
> > Then some class gets added:
> >
> > window.org.apache.royale.core.UIBase = function ()...
> >
> > And some static might get added to that:
> >
> > window.org.apache.royale.core.UIBase.FOO = "BAR";
> >
> > Closure will collapse org.apache.royale.core to just something like
> "bb"
> > in the js-release output.  And that means that code that sets
> UIBase.FOO
> > will break because there won't be an org.apache.royale.core
> structure.
> > AIUI, nocollapse would prevent collapsing that structure, but won't
> prevent
> > UIBase and FOO from being renamed.  And the renaming mainly causes
> problems
> > when deserializing data structures coming from a server or other
> external
> > source.
> >
> > Of course, I could be wrong...
> > -Alex
> >
> > On 9/16/19, 9:07 AM, "Josh Tynjala" 
> wrote:
> >
> > I was looking through the Closure compiler annotations, and I
> noticed
> > @nocollapse:
> >
> > Denotes a property that should n

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

2019-09-16 Thread Josh Tynjala
I guess I was assuming that @nocollapse combined with @export would make it
also prevent renaming. I suppose I can test it and see what happens.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Sep 16, 2019 at 9:54 AM Alex Harui  wrote:

> IMO, the -warn-public-vars is more about the "renaming" mentioned in that
> link than the "collapse".
>
> If you have:
>
> Package {
> Class Josh {
>   Public var name:String;
> }
> Var foo:Josh = new Josh();
> foo.name = 'josh';
>
> I don't think @nocollapse will prevent renaming the 'name' property to
> something random like 'jt':
>
> Var foo = new Josh();
> foo.jt = 'josh';
>
> AIUI, @nocollapse is used for things that are not obviously mutable.  If
> you look in the globals in the browser debugger for any js-debug version of
> a Royale app, you can see the structure:
>
>org.apache.royale.core
>
> It was created by code similar to:
>
> window.org = {};
> window.org.apache = {};
> window.org.apache.royale = {};
> window.org.apache.royale.core = {};
>
> Then some class gets added:
>
> window.org.apache.royale.core.UIBase = function ()...
>
> And some static might get added to that:
>
> window.org.apache.royale.core.UIBase.FOO = "BAR";
>
> Closure will collapse org.apache.royale.core to just something like "bb"
> in the js-release output.  And that means that code that sets UIBase.FOO
> will break because there won't be an org.apache.royale.core structure.
> AIUI, nocollapse would prevent collapsing that structure, but won't prevent
> UIBase and FOO from being renamed.  And the renaming mainly causes problems
> when deserializing data structures coming from a server or other external
> source.
>
> Of course, I could be wrong...
> -Alex
>
> On 9/16/19, 9:07 AM, "Josh Tynjala"  wrote:
>
> I was looking through the Closure compiler annotations, and I noticed
> @nocollapse:
>
> Denotes a property that should not be collapsed by the compiler into a
> > variable. The primary use for @nocollapse is to allow exporting of
> mutable
> > properties.
> >
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23nocollapsedata=02%7C01%7Caharui%40adobe.com%7C0444699041f3402d06c908d73abff16c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637042468374325733sdata=P%2FqQl7pq69YhAYtZQdKEHKnbgPuGDuD%2BikOca3aTOGY%3Dreserved=0
>
> Isn't this collapsing behavior the reason why we needed to add
> -warn-public-vars?
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C0444699041f3402d06c908d73abff16c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637042468374335722sdata=%2BwzLkQRXkpBeaII1wYWrT1z4fb%2FqKt3Qn2O7q1K1j3w%3Dreserved=0
> >
>
>
>


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

2019-09-16 Thread Josh Tynjala
I was looking through the Closure compiler annotations, and I noticed
@nocollapse:

Denotes a property that should not be collapsed by the compiler into a
> variable. The primary use for @nocollapse is to allow exporting of mutable
> properties.
>

https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#nocollapse

Isn't this collapsing behavior the reason why we needed to add
-warn-public-vars?

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


Re: Async RoyaleUnit Tests

2019-09-15 Thread Josh Tynjala
Async tests are not yet supported by RoyaleUnit. It's something that I hope
to add when time allows.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Sun, Sep 15, 2019 at 2:15 AM Yishay Weiss  wrote:

> Hi,
>
> We’re trying to create a test suite for out application using RoyaleUnit.
> Some of these tests require loading fonts before running the test. Does
> RoyaleUnit currently support async operations similar to FlexUnit [1].
>
> Or, as a work around, can anyone think of a way to load fonts
> synchronously?
>
> Thanks,
> Yishay
>
> [1] https://flex.apache.org/flexunit/tutorial/flexunit/Unit-13.html
>
>


Re: Question about stringifyNode

2019-09-13 Thread Josh Tynjala
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: Discuss of release steps preparation

2019-09-13 Thread Josh Tynjala
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 
> 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

Re: Discuss of release steps preparation

2019-09-12 Thread Josh Tynjala
I installed the npm package on Windows 10 successfully, and I see that
mxmlc, compc, asjsc, asjscompc, and asnodec all seem to be available on my
path, and I can run them.


--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Thu, Sep 12, 2019 at 1:53 AM Carlos Rovira 
wrote:

> Hi,
>
> think al went fine :)
>
> this is my output:
>
>
> + @apache-royale/royale-js-swf@0.9.6-beta9
>
> added 146 packages from 108 contributors in 426.831s
>
>
>
>
> then I tried "mxmlc" just from command line:
>
>
> macbookpro:~ carlosrovira$ mxmlc
>
> Using Royale Compiler codebase:
> /Users/carlosrovira/Dev/Royale/Source/royale-compiler
>
> Using Royale SDK: /Users/carlosrovira/Dev/Royale/Source/royale-asjs
>
> MXMLJSC
>
> +royalelib=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks
>
>
> -sdk-js-lib=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/Royale/generated-sources
>
> Loading configuration:
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/royale-config.xml
>
>
> Error: a target file must be specified.
>
>
>
>
> Error: a target file must be specified.
>
>
>
>
> 0.888219402 seconds
>
> macbookpro:~ carlosrovira$
>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: [royale-compiler] branch develop updated: MemberAccessEmitter: fixed issue where fully-qualified names were emitted as dynamic access with -js-dynamic-access-unknown-members=true

2019-09-09 Thread Josh Tynjala
Maybe. It's worth mentioning that VSCode's Java support is based on
Eclipse, so it uses the same project file formats as Eclipse. We have
.classpath and .project files committed in the repo, presumably to make it
easy to import the compiler projects into Eclipse. However, they're
constantly in a modified state in my local copy because VSCode overwrites
them. I think that VSCode re-configures the project based on the Maven
pom.xml file, but the repo's versions don't know about Maven.

Even if we add .factorypath to .gitignore, both .classpath and .project are
at risk of being accidentally committed too. It wouldn't really make a huge
difference for me to ignore this file because I will still need to take
extra care before committing. It just happened to slip through this time.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Sep 9, 2019 at 8:27 AM Alex Harui  wrote:

> Should it be added to .gitignore so it doesn't get committed?
>
> On 9/9/19, 6:58 AM, "Josh Tynjala"  wrote:
>
> I removed this file. Should be gone on both develop and release/0.9.6.
>
> - Josh
>
>
>     On Mon, Sep 9, 2019 at 6:39 AM Josh Tynjala  >
> wrote:
>
> > It's a project file created by VSCode. I didn't realize that I
> > accidentally added it. It can be removed from the repo.
> >
> > - Josh
> >
> > On Saturday, September 7, 2019, Alex Harui  >
> > wrote:
> > > Josh,
> > >
> > > What is the .factorypath file?  It is in the release package.
> Should it
> > even be in the repo?
> > >
> > > -Alex
> > >
> > > On 8/12/19, 11:12 AM, "joshtynj...@apache.org" <
> joshtynj...@apache.org>
> > wrote:
> > >
> > > This is an automated email from the ASF dual-hosted git
> repository.
> > >
> > > joshtynjala pushed a commit to branch develop
> > > in repository
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-compiler.gitdata=02%7C01%7Caharui%40adobe.com%7C9d9cda8acf534faa637c08d7352db98f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036342817927726sdata=jLY5fG0O7mT1CeV%2B14Hzpzob4oAMW%2FclxdJB71Cfpl0%3Dreserved=0
> > >
> > >
> > > The following commit(s) were added to refs/heads/develop by
> this
> > push:
> > >  new f4f9898  MemberAccessEmitter: fixed issue where
> > fully-qualified names were emitted as dynamic access with
> > -js-dynamic-access-unknown-members=true
> > > f4f9898 is described below
> > >
> > > commit f4f9898ad6f94c903615db5bfae691bfaac4a5f3
> > > Author: Josh Tynjala 
> > > AuthorDate: Mon Aug 12 11:12:34 2019 -0700
> > >
> > > MemberAccessEmitter: fixed issue where fully-qualified
> names
> > were emitted as dynamic access with
> -js-dynamic-access-unknown-members=true
> > >
> > > Now, if a definition is resolved, and its parent
> definition is a
> > package, just outputs the fully-qualified name instead of walking
> the full
> > chain of member access
> > > ---
> > >  .../codegen/js/jx/MemberAccessEmitter.java |  13 ++-
> > >  debugger/.factorypath  | 102
> > +
> > >  2 files changed, 111 insertions(+), 4 deletions(-)
> > >
> > > diff --git
> >
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> >
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> > > index 741affb..cc0a892 100644
> > > ---
> >
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> > > +++
> >
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> > > @@ -23,6 +23,7 @@ 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.IDefinition;
> > > +import
> org.apache.royale.compiler.definitions.IPackageDefinition;
> > >  import
> > or

Re: [royale-compiler] branch develop updated: MemberAccessEmitter: fixed issue where fully-qualified names were emitted as dynamic access with -js-dynamic-access-unknown-members=true

2019-09-09 Thread Josh Tynjala
I removed this file. Should be gone on both develop and release/0.9.6.

- Josh


On Mon, Sep 9, 2019 at 6:39 AM Josh Tynjala 
wrote:

> It's a project file created by VSCode. I didn't realize that I
> accidentally added it. It can be removed from the repo.
>
> - Josh
>
> On Saturday, September 7, 2019, Alex Harui 
> wrote:
> > Josh,
> >
> > What is the .factorypath file?  It is in the release package.  Should it
> even be in the repo?
> >
> > -Alex
> >
> > On 8/12/19, 11:12 AM, "joshtynj...@apache.org" 
> wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > joshtynjala pushed a commit to branch develop
> > in repository
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-compiler.gitdata=02%7C01%7Caharui%40adobe.com%7C8f2fb400e5d54f73082808d71f50a99b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637012303647260983sdata=W79nBsynNmvLQKY1tdcHgbR6K09oo%2FA%2F3z%2BRBb1Iq8E%3Dreserved=0
> >
> >
> > The following commit(s) were added to refs/heads/develop by this
> push:
> >  new f4f9898  MemberAccessEmitter: fixed issue where
> fully-qualified names were emitted as dynamic access with
> -js-dynamic-access-unknown-members=true
> > f4f9898 is described below
> >
> > commit f4f9898ad6f94c903615db5bfae691bfaac4a5f3
> > Author: Josh Tynjala 
> > AuthorDate: Mon Aug 12 11:12:34 2019 -0700
> >
> > MemberAccessEmitter: fixed issue where fully-qualified names
> were emitted as dynamic access with -js-dynamic-access-unknown-members=true
> >
> > Now, if a definition is resolved, and its parent definition is a
> package, just outputs the fully-qualified name instead of walking the full
> chain of member access
> > ---
> >  .../codegen/js/jx/MemberAccessEmitter.java |  13 ++-
> >  debugger/.factorypath  | 102
> +
> >  2 files changed, 111 insertions(+), 4 deletions(-)
> >
> > diff --git
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> > index 741affb..cc0a892 100644
> > ---
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> > +++
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> > @@ -23,6 +23,7 @@ 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.IDefinition;
> > +import org.apache.royale.compiler.definitions.IPackageDefinition;
> >  import
> org.apache.royale.compiler.internal.codegen.as.ASEmitterTokens;
> >  import
> org.apache.royale.compiler.internal.codegen.js.JSEmitterTokens;
> >  import org.apache.royale.compiler.internal.codegen.js.JSSubEmitter;
> > @@ -32,7 +33,6 @@ import
> org.apache.royale.compiler.internal.codegen.js.royale.JSRoyaleEmitterToke
> >  import
> org.apache.royale.compiler.internal.codegen.js.goog.JSGoogEmitterTokens;
> >  import
> org.apache.royale.compiler.internal.codegen.js.jx.BinaryOperatorEmitter.DatePropertiesGetters;
> >  import
> org.apache.royale.compiler.internal.definitions.AccessorDefinition;
> > -import
> org.apache.royale.compiler.internal.definitions.AppliedVectorDefinition;
> >  import
> org.apache.royale.compiler.internal.definitions.FunctionDefinition;
> >  import org.apache.royale.compiler.internal.projects.RoyaleJSProject;
> >  import org.apache.royale.compiler.internal.tree.as.*;
> > @@ -42,8 +42,6 @@ import org.apache.royale.compiler.tree.as.*;
> >  import
> org.apache.royale.compiler.tree.as.IOperatorNode.OperatorType;
> >  import org.apache.royale.compiler.utils.ASNodeUtils;
> >
> > -import javax.sound.midi.SysexMessage;
> > -
> >  public class MemberAccessEmitter extends JSSubEmitter implements
> >  ISubEmitter
> >  {
> > @@ -177,6 +175,13 @@ public class MemberAccessEmitter extends
> JSSubEmitter implements
> > return;
> > }
> >  }
> > +   else if(def.getParent() instanceof IPackageDefinition)
> > +   {
> &g

Re: [royale-compiler] branch develop updated: MemberAccessEmitter: fixed issue where fully-qualified names were emitted as dynamic access with -js-dynamic-access-unknown-members=true

2019-09-09 Thread Josh Tynjala
It's a project file created by VSCode. I didn't realize that I accidentally
added it. It can be removed from the repo.

- Josh

On Saturday, September 7, 2019, Alex Harui  wrote:
> Josh,
>
> What is the .factorypath file?  It is in the release package.  Should it
even be in the repo?
>
> -Alex
>
> On 8/12/19, 11:12 AM, "joshtynj...@apache.org" 
wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> joshtynjala pushed a commit to branch develop
> in repository
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-compiler.gitdata=02%7C01%7Caharui%40adobe.com%7C8f2fb400e5d54f73082808d71f50a99b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637012303647260983sdata=W79nBsynNmvLQKY1tdcHgbR6K09oo%2FA%2F3z%2BRBb1Iq8E%3Dreserved=0
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new f4f9898  MemberAccessEmitter: fixed issue where
fully-qualified names were emitted as dynamic access with
-js-dynamic-access-unknown-members=true
> f4f9898 is described below
>
> commit f4f9898ad6f94c903615db5bfae691bfaac4a5f3
> Author: Josh Tynjala 
> AuthorDate: Mon Aug 12 11:12:34 2019 -0700
>
> MemberAccessEmitter: fixed issue where fully-qualified names were
emitted as dynamic access with -js-dynamic-access-unknown-members=true
>
> Now, if a definition is resolved, and its parent definition is a
package, just outputs the fully-qualified name instead of walking the full
chain of member access
> ---
>  .../codegen/js/jx/MemberAccessEmitter.java |  13 ++-
>  debugger/.factorypath  | 102
+
>  2 files changed, 111 insertions(+), 4 deletions(-)
>
> diff --git
a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> index 741affb..cc0a892 100644
> ---
a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> +++
b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> @@ -23,6 +23,7 @@ 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.IDefinition;
> +import org.apache.royale.compiler.definitions.IPackageDefinition;
>  import
org.apache.royale.compiler.internal.codegen.as.ASEmitterTokens;
>  import
org.apache.royale.compiler.internal.codegen.js.JSEmitterTokens;
>  import org.apache.royale.compiler.internal.codegen.js.JSSubEmitter;
> @@ -32,7 +33,6 @@ import
org.apache.royale.compiler.internal.codegen.js.royale.JSRoyaleEmitterToke
>  import
org.apache.royale.compiler.internal.codegen.js.goog.JSGoogEmitterTokens;
>  import
org.apache.royale.compiler.internal.codegen.js.jx.BinaryOperatorEmitter.DatePropertiesGetters;
>  import
org.apache.royale.compiler.internal.definitions.AccessorDefinition;
> -import
org.apache.royale.compiler.internal.definitions.AppliedVectorDefinition;
>  import
org.apache.royale.compiler.internal.definitions.FunctionDefinition;
>  import org.apache.royale.compiler.internal.projects.RoyaleJSProject;
>  import org.apache.royale.compiler.internal.tree.as.*;
> @@ -42,8 +42,6 @@ import org.apache.royale.compiler.tree.as.*;
>  import org.apache.royale.compiler.tree.as.IOperatorNode.OperatorType;
>  import org.apache.royale.compiler.utils.ASNodeUtils;
>
> -import javax.sound.midi.SysexMessage;
> -
>  public class MemberAccessEmitter extends JSSubEmitter implements
>  ISubEmitter
>  {
> @@ -177,6 +175,13 @@ public class MemberAccessEmitter extends
JSSubEmitter implements
> return;
> }
>  }
> +   else if(def.getParent() instanceof IPackageDefinition)
> +   {
> +   //this is a fully qualified name, and we should
output it directly
> +   //because we don't want it to be treated as
dynamic access
> +
 write(fjs.formatQualifiedName(def.getQualifiedName()));
> +   return;
> +   }
>  else if (def.getParent() != null &&
>
def.getParent().getQualifiedName().equals("Array"))
>  {
> @@ -260,7 +265,7 @@ public class MemberAccessEmitter extends
JSSubEmitter implements
> getEmitter().em

Re: Heads up on XML

2019-09-07 Thread Josh Tynjala
> > 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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%3Dreserved=0
>>> >> > > > "
>>> >> > > > xmlns:m="nothing">\n' +
>>> >> > > > '  >> rel="no_namespace"
>>> >> > > > 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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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
>>> >> > > > >> >> href="blah/12321/domain/"
>>> >> > xmlns:atom="
>>> >> > > >
>>> >> > > >
>>> >> > >
>>> >> >
>>> >>
>>>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtomdata=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%3Dreserved=0
>>> >> > > "
>>> >> > > > 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.
>>> >> >> nodes where
>>> >> > the
>>> >> > > prefix atom
>>> >> > > > is
>>> >> > > > 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.
>>> >> > > >
>>> >> > > >
>>> >> > > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>>
>>>
>>>
>

-- 
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


Re: [DISCUSS] Release Apache Royale 0.9.6 RC1

2019-09-06 Thread Josh Tynjala
I just updated the royale-compiler and royale-asjs release notes with the
things that I worked on. They're in the develop branch for now.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Fri, Sep 6, 2019 at 9:37 AM Piotr Zarzycki 
wrote:

> I was thinking about that in a very brave way at the beginning ! I was
> going to go trough commits from our last 0.9.4 release and prepare nice
> list for CHANGELOG, but since everything took double time then I assume. -
> It's not going to happen from my sight.
>
> On Fri, Sep 6, 2019, 5:13 PM Andrew Wetmore  wrote:
>
> > The release notes file doesn't seem to have a section about what's in
> > 0.9.6, the current release.
> >
> > a
> >
> > On Fri, Sep 6, 2019 at 11:29 AM Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> > wrote:
> >
> > > Hi Carlos,
> > >
> > > IT depends on what commit MX is failing. I did branch for this RC
> couple
> > of
> > > days ago. In that time I was seeing some commits to develop related to
> > MX.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > On Fri, Sep 6, 2019, 4:02 PM Carlos Rovira 
> > > wrote:
> > >
> > > > Hi Piotr,
> > > >
> > > > thanks. One question I have is: I think MX Test was failing, does it
> > > > affects the release or are not crucial to get the bits out?
> > > >
> > > > Thanks
> > > >
> > > > El vie., 6 sept. 2019 a las 13:10, Piotr Zarzycki (<
> > > > piotrzarzyck...@gmail.com>) escribió:
> > > >
> > > > > Hi Guys,
> > > > >
> > > > > I have upload manually ant artifacts. Please start reviewing stuff.
> > > What
> > > > if
> > > > > vote passes - Should we merge 0.9.6 tag to develop ?
> > > > >
> > > > > Thanks,
> > > > > Piotr
> > > > >
> > > > > pt., 6 wrz 2019 o 13:09 Apache Royale CI Server <
> > > > apacheroyal...@gmail.com>
> > > > > napisał(a):
> > > > >
> > > > > > This is the discussion thread.
> > > > > >
> > > > > > Thanks,
> > > > > > Piotr Zarzycki
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Piotr Zarzycki
> > > > >
> > > > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > > > <https://www.patreon.com/piotrzarzycki>*
> > > > >
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > > >
> > >
> >
> >
> > --
> > Andrew Wetmore
> >
> > http://cottage14.blogspot.com/
> >
>


Re: Discuss of release steps preparation

2019-09-03 Thread Josh Tynjala
macOS allows you to escape a space in a path using a backslash. You can see
that Carlos has some backslashes in his message.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Sep 3, 2019 at 9:50 AM Piotr Zarzycki 
wrote:

> ok it failed. How should I put in bash_profile file this path so it would
> be understandable?
>
> export
>
> FLASHPLAYER_DEBUGGER=/Users/piotr/Downloads/player/flashplayer.app/Contents/MacOS/Flash
> Player Debugger
>
> On Windows we would probably go with:
>
>
> FLASHPLAYER_DEBUGGER="/Users/piotr/Downloads/player/flashplayer.app/Contents/MacOS/Flash
> Player Debugger"
>
>
>
>
>
> wt., 3 wrz 2019 o 18:34 Piotr Zarzycki 
> napisał(a):
>
> > I have path exactly the same as Josh mention placed in bash script. I
> just
> > run build and will see whether this help. However after printenv I see
> that
> > path is cutted cause there are spaces in file name. On windows it would
> not
> > work, but maybe on it is different. We will see.
> >
> > wt., 3 wrz 2019 o 17:32 Carlos Rovira 
> > napisał(a):
> >
> >> Hi Piotr, this is what I use in my .bash_profile:
> >>
> >> export FLASHPLAYER_DEBUGGER=/Applications/Flash\
> >> Player.app/Contents/MacOS/Flash\ Player\ Debugger
> >>
> >>
> >> El mar., 3 sept. 2019 a las 17:04, Piotr Zarzycki (<
> >> piotrzarzyck...@gmail.com>) escribió:
> >>
> >> > Hey Josh,
> >> >
> >> > Thank you so much! I will check it out soon.
> >> >
> >> > On Tue, Sep 3, 2019, 4:48 PM Josh Tynjala 
> >> > wrote:
> >> >
> >> > > I think you need to point to the executable inside of the .app file.
> >> So
> >> > > it's something like this:
> >> > >
> >> > > /Applications/Flash Player.app/Contents/MacOS/Flash Player Debugger
> >> > >
> >> > > I may not have that exactly right because I'm on Windows at the
> >> moment,
> >> > and
> >> > > I can't check. However, if you right-click the .app file, and choose
> >> Show
> >> > > Package Contents, you can dig in there and find the correct path.
> >> > >
> >> > > --
> >> > > Josh Tynjala
> >> > > Bowler Hat LLC <https://bowlerhat.dev>
> >> > >
> >> > >
> >> > > On Tue, Sep 3, 2019 at 6:56 AM Piotr Zarzycki <
> >> piotrzarzyck...@gmail.com
> >> > >
> >> > > wrote:
> >> > >
> >> > > > In Mac is different - maybe I setup it wrong. Does anyone know
> >> whether
> >> > I
> >> > > > should setup it to "flashplayer.app" or just "flashplayer"?
> >> > > >
> >> > > > Thanks,
> >> > > > Piotr
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Tue, Sep 3, 2019, 3:18 PM Yishay Weiss  >
> >> > > wrote:
> >> > > >
> >> > > > > All failures look to be on flash tests. Are you sure you’re
> >> pointing
> >> > at
> >> > > > > the right FLASHPLAYER_DEBUGGER?
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > I have env var
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > FLASHPLAYER_DEBUGGER
> >> > > > >
> >> > > > > ==
> >> > > > >
> >> > > > > C:\dev\flash\flashplayer_18_sa_debug.exe
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > 
> >> > > > > From: Piotr Zarzycki 
> >> > > > > Sent: Tuesday, September 3, 2019 3:53:24 PM
> >> > > > > To: dev@royale.apache.org 
> >> > > > > Subject: Re: Discuss of release steps preparation
> >> > > > >
> >> > > > > Ok but in folder junit-reprots there were two files [1][2]
> >> > > > >
> >> > > > > [1] https://paste.apache.org/fu49t
> >> > > > > [2] https://paste.apache.org/2dd6c
> >> > > > >
> >> > > > > wt., 3 wrz 2019 o 14:46 Piotr Zarzycki <
> piotrzarzyck...@gmail.com
> >> >

Re: Discuss of release steps preparation

2019-09-03 Thread Josh Tynjala
I think you need to point to the executable inside of the .app file. So
it's something like this:

/Applications/Flash Player.app/Contents/MacOS/Flash Player Debugger

I may not have that exactly right because I'm on Windows at the moment, and
I can't check. However, if you right-click the .app file, and choose Show
Package Contents, you can dig in there and find the correct path.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Sep 3, 2019 at 6:56 AM Piotr Zarzycki 
wrote:

> In Mac is different - maybe I setup it wrong. Does anyone know whether I
> should setup it to "flashplayer.app" or just "flashplayer"?
>
> Thanks,
> Piotr
>
>
>
> On Tue, Sep 3, 2019, 3:18 PM Yishay Weiss  wrote:
>
> > All failures look to be on flash tests. Are you sure you’re pointing at
> > the right FLASHPLAYER_DEBUGGER?
> >
> >
> >
> > I have env var
> >
> >
> >
> > FLASHPLAYER_DEBUGGER
> >
> > ==
> >
> > C:\dev\flash\flashplayer_18_sa_debug.exe
> >
> >
> >
> > 
> > From: Piotr Zarzycki 
> > Sent: Tuesday, September 3, 2019 3:53:24 PM
> > To: dev@royale.apache.org 
> > Subject: Re: Discuss of release steps preparation
> >
> > Ok but in folder junit-reprots there were two files [1][2]
> >
> > [1] https://paste.apache.org/fu49t
> > [2] https://paste.apache.org/2dd6c
> >
> > wt., 3 wrz 2019 o 14:46 Piotr Zarzycki 
> > napisał(a):
> >
> > > Hi Yishay,
> > >
> > > Interesting. In that folder there is no such file as it's on
> stacktrace.
> > > There are only swf files -> https://ibb.co/7vh7MnD
> > >
> > > Thanks,
> > > Piotr
> > >
> > > wt., 3 wrz 2019 o 14:40 Yishay Weiss 
> > napisał(a):
> > >
> > >> If I understand correctly these messages [1] don’t indicate a failure,
> > >> but are part of a test to make sure that the proper error message
> > appears
> > >> when you write to a read-only prop. Can you find the tests that failed
> > >> further up in the output?
> > >>
> > >>
> > >>
> > >> [1] [junit]
> > >>
> >
> /Users/piotr/Downloads/royale/release/releaseasjs_ant/sources/royale-compiler/compiler/target/junit-temp/ASDateTests2436056786678332499.as(16):
> > >> col: 1 Error: Property timezoneOffset is read-only.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 
> > >> From: Piotr Zarzycki 
> > >> Sent: Tuesday, September 3, 2019 2:52:11 PM
> > >> To: dev@royale.apache.org 
> > >> Subject: Re: Discuss of release steps preparation
> > >>
> > >> I have setup my Mac instead to have a ANT build. Unfortunately one of
> > the
> > >> compiler test failed [1]. I have used -DskipTests=true, so why
> actually
> > >> those tests run ?
> > >>
> > >> [1]  https://paste.apache.org/kzm3t
> > >>
> > >>
> > >>
> > >> wt., 3 wrz 2019 o 12:20 Piotr Zarzycki 
> > >> napisał(a):
> > >>
> > >> > Just FYI I have tried several times and I still cannot properly
> > prepare
> > >> > ANT artifacts for 0.9.6 release. I have uninstall TortoiseGIT, but
> > files
> > >> > which I cannot delete has been still hold by some processes related
> to
> > >> > build.
> > >> >
> > >> > I'm going to try this very last step do on our remote PC to see
> > whether
> > >> it
> > >> > will be successful. If not I gave up on being RM. Someone else will
> > >> have to
> > >> > try.
> > >> >
> > >> > śr., 28 sie 2019 o 18:10 Alex Harui 
> > >> napisał(a):
> > >> >
> > >> >> Failonerror is typically false when deleting in case the folder has
> > >> >> already been deleted.
> > >> >>
> > >> >> Pretty sure that at least on Windows,  if a jar is being used by a
> > >> >> running application that you cannot delete the jar.
> > >> >>
> > >> >> In theory, the Ant scripts should not be loading jars when building
> > the
> > >> >> source package and I think they even run super-clean which should
> > clean
> > >> >> everything assuming nothing else is running th

Re: Trying abstract classes in Jewel

2019-08-29 Thread Josh Tynjala
 The AS3 & MXML extension for VSCode bundles Royale 0.9.4, which doesn't
understand abstract. Maybe you forgot to use the as3mxml.sdk.editor setting
to tell it to use 0.9.6 for code intelligence? In other words, both
as3mxml.sdk.framework and as3mxml.sdk.editor need to point to 0.9.6.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Thu, Aug 29, 2019 at 12:45 AM Carlos Rovira 
wrote:

> Hi Josh,
>
> using your indication in VSCode shows a problem in the "abstract" word and
> says:
>
> "Access specifiers are not allowed with namespace attributes.(1003)"
>
> I assume we have abstract keyword set by default right? so in Jewel without
> configuring nothing "abstract" should be allowed.
>
> Thanks
>
>
> El mié., 28 ago. 2019 a las 23:31, Josh Tynjala (<
> joshtynj...@bowlerhat.dev>)
> escribió:
>
> > Hi Carlos,
> >
> > If I understand you correctly, you removed public and added abstract.
> > However, you should not remove public. Your new declaration should
> probably
> > look like this:
> >
> > public abstract class TextInputBase extends StyledUIBase implements
> > ITextInput
> >
> > If this does not seem to help, can you share the full error message?
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Fri, Aug 23, 2019 at 2:21 AM Carlos Rovira 
> > wrote:
> >
> > > Hi Josh,
> > >
> > > after cleaning Jewel TextInput classes, I tried to change TextInputBase
> > > from public to abstract class.
> > >
> > > The reason is that while Simple** classes (like Jewel SimpleButton or
> > > SimpleRemoteObject), are a reduced case of a class named without
> "Simple"
> > > (in the example "Button", and most users would want to use just
> "Button",
> > > so this name strategy seems very good to me, exposing the most used
> class
> > > with the expected name and a simple one with that prefix).
> > >
> > > Others like TextInputBase (with suffix **Base) are just a base class
> for
> > > other classes like TextInput and TextArea and should not be used as a
> > > component,
> > > so in this way of thinking seems reasonable to mark it as "abstract".
> > >
> > > When doing that little change (switch public for abstract at level
> class
> > in
> > > TextInputBase), when compile Jewel SWC, a bunch of errors appear,
> > > so is not clear to me if I'm doing something wrong, or I'm missing
> > > something.
> > >
> > > Hope you can give some light on this.
> > >
> > > Thanks.
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: Trying abstract classes in Jewel

2019-08-28 Thread Josh Tynjala
Hi Carlos,

If I understand you correctly, you removed public and added abstract.
However, you should not remove public. Your new declaration should probably
look like this:

public abstract class TextInputBase extends StyledUIBase implements
ITextInput

If this does not seem to help, can you share the full error message?

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Fri, Aug 23, 2019 at 2:21 AM Carlos Rovira 
wrote:

> Hi Josh,
>
> after cleaning Jewel TextInput classes, I tried to change TextInputBase
> from public to abstract class.
>
> The reason is that while Simple** classes (like Jewel SimpleButton or
> SimpleRemoteObject), are a reduced case of a class named without "Simple"
> (in the example "Button", and most users would want to use just "Button",
> so this name strategy seems very good to me, exposing the most used class
> with the expected name and a simple one with that prefix).
>
> Others like TextInputBase (with suffix **Base) are just a base class for
> other classes like TextInput and TextArea and should not be used as a
> component,
> so in this way of thinking seems reasonable to mark it as "abstract".
>
> When doing that little change (switch public for abstract at level class in
> TextInputBase), when compile Jewel SWC, a bunch of errors appear,
> so is not clear to me if I'm doing something wrong, or I'm missing
> something.
>
> Hope you can give some light on this.
>
> Thanks.
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: Discuss of release steps preparation

2019-08-28 Thread Josh Tynjala
With that in mind, it seems like you may need to temporarily disable
TortoiseGit while running the build.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Aug 28, 2019 at 6:28 AM Piotr Zarzycki 
wrote:

> I'm not sure if it's related, but I have tried deleted that folder manually
> and it's being blocked by Git [1]
>
> [1] https://ibb.co/bsm48DV
>
> Thanks,
> Piotr
>
> śr., 28 sie 2019 o 15:07 Piotr Zarzycki 
> napisał(a):
>
> > I have modified build.xml script locally and I got following result ->
> > https://paste.apache.org/m5mz5
> >
> > What can hold that jar file ?
> >
> >
> >
> > śr., 28 sie 2019 o 14:23 Piotr Zarzycki 
> > napisał(a):
> >
> >> Hi Alex,
> >>
> >> I just made another attempt and it's failed. I missed your information
> >> that "royale-asjs/js/lib/ " contains 2 jar files. I see them on my
> machine.
> >> I see also that we have [1] deletion line for that. My fix for deleting
> >> helped so far to get rid of problem with RoyaleUnit [2].
> >>
> >> Maybe we should switch failonerror="false" to "true" and see what is
> >> happening ? Why actually those flags are false ?
> >>
> >> [1]
> >>
> https://github.com/apache/royale-asjs/blob/946e1f13c125ad2f3fc74ae56d8cbc462487c3f5/build.xml#L565
> >> [2]
> >>
> https://github.com/apache/royale-asjs/commit/946e1f13c125ad2f3fc74ae56d8cbc462487c3f5
> >>
> >> Thanks,
> >> Piotr
> >>
> >> pon., 26 sie 2019 o 08:35 Alex Harui 
> >> napisał(a):
> >>
> >>> The two zips are different.
> >>>
> >>> The second zip contains several files that the first one doesn't.  Try
> >>> using other diff tools to find one that will help you see the
> differences.
> >>> I just use my Mac's *nix command line with "diff -rwq" and "find".
> Cygwin
> >>> and GitBash should have those tools on Windows.  I didn't take the
> time to
> >>> find out.
> >>>
> >>> The second zip has two extra folders:
> >>>
> >>> royale-asjs/js/lib/ with two jars in it.  Those jars should be cleaned
> >>> by Ant, but maybe they were in use and thus locked.
> >>>
> second/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target
> >>> with lots of files in it.  These files may not be getting cleaned by
> Ant
> >>> scripts since RoyaleUnit is a new library.
> >>>
> >>> Maybe you ran step 13 in a folder where it had already run?
> >>>
> >>> I'm done working for today.  Will check in my morning.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>>
> >>>
> >>> On 8/25/19, 11:08 PM, "Piotr Zarzycki" 
> >>> wrote:
> >>>
> >>> Links:
> >>>
> >>> zip1:
> >>>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!ApVpLyjpHDC2ic0S8UffcFPmhXGKGQ%3Fe%3DZstLevdata=02%7C01%7Caharui%40adobe.com%7Cee362a70359f471e8aed08d729ebc5cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637023964926048393sdata=2LuY8Zl6krXiKSqrhXJkm8xN01uwQq1aQ9ap9NZsTfY%3Dreserved=0
> >>> zip2:
> >>>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!ApVpLyjpHDC2ic0TPORa2P9OKsWRiw%3Fe%3Dk8fQ7Tdata=02%7C01%7Caharui%40adobe.com%7Cee362a70359f471e8aed08d729ebc5cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637023964926048393sdata=shpNZi76ycOzZnlaqD2HPBuVPZJcju%2F6Ud1ERZXTKvo%3Dreserved=0
> >>>
> >>> Thanks,
> >>> Piotr
> >>>
> >>> pon., 26 sie 2019 o 00:48 Alex Harui 
> >>> napisał(a):
> >>>
> >>> > Looks like there are 130 files in the "left" folder that aren't
> in
> >>> the
> >>> > "right"?  Or I don't understand the output of whatever tool you
> >>> are using.
> >>> > Post a link to the two zips if  you want.
> >>> >
> >>> > HTH,
> >>> > -Alex
> >>> >
> >>> > On 8/25/19, 3:08 PM, "Piotr Zarzycki"  >
> >>> wrote:
> >>> >
> >>> > Content in both zips is exactly the same. I don't see now the
> >>> reason
> >>> > to do
> >>> > not move forward with that ->
> >&

Re: ${body} in index template

2019-08-27 Thread Josh Tynjala
It is worth mentioning that you are not required to include ${body} in a
custom html template. If you need to customize the app startup, you can
skip ${body} completely and write your  tag from scratch.

- Josh

On Tuesday, August 27, 2019, Chris Velevitch <chris.velevi...@gmail.com>
wrote:
> Where is the value of "${body}" defined? When I build a javascript app,
the
> following code is inserted there:-
>
><script>
>   new MyApp().start();
>
>
> I want to be able to insert additional code there like:-
>
> 
>royaleCompatibility = new RoyaleCompatibility();
>if (royaleCompatibility.isCompatible) {
>new MyApp().start();
>} else {
>royaleCompatibility.displayIncompatibilityText();
>}
> 
>
>
> How do I do that?
>

-- 
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


Re: Discuss of release steps preparation

2019-08-26 Thread Josh Tynjala
Yeah, I think you should be able to add the project to Maven. If the pom is
missing or incomplete, I expect that you can basically copy another
project's pom and change a few names to get it working.

Sorry for the trouble! It's easy to forget Maven sometimes. I'm surprised
that this didn't come up earlier, but I guess the Maven build didn't fail
because RoyaleUnit and FlexUnit have compatible metadata APIs, so the tests
still passed.

- Josh

On Monday, August 26, 2019, Piotr Zarzycki 
wrote:
> You are basically saying that in case of Maven I should try to move it as
> an standard module build.
>
> In case of Ant build I will try to figure it out - if I won't be able to I
> will wait to your free cycles.
>
> Thanks,
> Piotr
>
> pon., 26 sie 2019 o 16:39 Josh Tynjala 
> napisał(a):
>
>> I guess that I completely forgot to add RoyaleUnit to the Maven build.
>> Someone else must have added it to the "broken" thing because I have no
>> idea what that is.
>>
>> With the Ant build, I tried my best to copy what the build was doing with
>> the other libraries. I guess this means that I missed some important
>> detail. I can take a look, but I won't have time until the first week of
>> September.
>>
>> - Josh
>>
>> On Monday, August 26, 2019, Piotr Zarzycki 
>> wrote:
>> > Hi Josh,
>> >
>> > You were working on RoyaleUnit ? I see that it is not even part of
Maven
>> > build but it is part of profile "brokenbuild" [1]. In case of ANT see
>> that
>> > this module is part of the build, but obviously something doesn't work
in
>> > the end. [2]
>> >
>> > I'm not sure what actually I should do with that ?
>> >
>> > [1]
>> >
>>
>>
https://github.com/apache/royale-asjs/blob/4a3cb8864d2df2ba4e028e07d9cda9215373c42c/frameworks/projects/pom.xml#L76
>> > [2]
>> >
>>
>>
https://github.com/apache/royale-asjs/blob/4a3cb8864d2df2ba4e028e07d9cda9215373c42c/frameworks/build.xml#L116
>> >
>> > Thanks,
>> > Piotr
>> >
>> > pon., 26 sie 2019 o 10:19 Piotr Zarzycki 
>> > napisał(a):
>> >
>> >> Alex,
>> >>
>> >> I see what is happening. I had the same issue when I was preparing
Maven
>> >> artifacts - I think so. Royale unit is not part of final src zip ->
>> >> https://ibb.co/44ByBKV
>> >>
>> >> I have to figure out how add it there.
>> >>
>> >> Thanks,
>> >> Piotr
>> >>
>> >> pon., 26 sie 2019 o 08:35 Alex Harui 
>> >> napisał(a):
>> >>
>> >>> The two zips are different.
>> >>>
>> >>> The second zip contains several files that the first one doesn't.
Try
>> >>> using other diff tools to find one that will help you see the
>> differences.
>> >>> I just use my Mac's *nix command line with "diff -rwq" and "find".
>> Cygwin
>> >>> and GitBash should have those tools on Windows.  I didn't take the
time
>> to
>> >>> find out.
>> >>>
>> >>> The second zip has two extra folders:
>> >>>
>> >>> royale-asjs/js/lib/ with two jars in it.  Those jars should be
cleaned
>> by
>> >>> Ant, but maybe they were in use and thus locked.
>> >>>
>>
>>
second/royale-asjs/frameworks/js/projects/RoyaleUnitJS/src/test/royale/target
>> >>> with lots of files in it.  These files may not be getting cleaned by
>> Ant
>> >>> scripts since RoyaleUnit is a new library.
>> >>>
>> >>> Maybe you ran step 13 in a folder where it had already run?
>> >>>
>> >>> I'm done working for today.  Will check in my morning.
>> >>>
>> >>> HTH,
>> >>> -Alex
>> >>>
>> >>>
>> >>>
>> >>> On 8/25/19, 11:08 PM, "Piotr Zarzycki" 
>> >>> wrote:
>> >>>
>> >>> Links:
>> >>>
>> >>> zip1:
>> >>>
>>
>>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!ApVpLyjpHDC2ic0S8UffcFPmhXGKGQ%3Fe%3DZstLevdata=02%7C01%7Caharui%40adobe.com%7Cee362a70359f471e8aed08d729ebc5cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637023964926048393sdata=2LuY8Zl6krXiKSqrhXJkm8xN01uwQq1aQ9ap9NZsTfY%3Dreserved=0
>> >>> zip2:
>> >>>
>>
>>
https://nam04.safelinks.protection.

Re: Discuss of release steps preparation

2019-08-26 Thread Josh Tynjala
>> > >>> >
>>> > >>> > At this point, I would definitely recommend trying
>>> the three
>>> > steps
>>> > >>> without
>>> > >>> > any changes to the release_steps.xml file and use an
>>> ABSOLUTE
>>> > >>> path.  That's
>>> > >>> > the only way I tested the scripts.  I did not try a
>>> relative
>>> > path,
>>> > >>> and I
>>> > >>> > highly recommend not putting all of these files in a
>>> working
>>> > >>> copy.  It is
>>> > >>> > probably less work to just have RM's specify an
>>> absolute path
>>> > >>> external to
>>> > >>> > the working copy.  Using "../.." may not work
>>> consistently
>>> > so do
>>> > >>> not use
>>> > >>> > those adjustments.
>>> > >>> >
>>> > >>> > Capture the logs for all 3 steps and if there is a
>>> problem
>>> > post
>>> > >>> the output.
>>> > >>> >
>>> > >>> > Thanks,
>>> > >>> > -Alex
>>> > >>> >
>>> > >>> >
>>> > >>> > On 8/16/19, 2:57 AM, "Piotr Zarzycki" <
>>> > piotrzarzyck...@gmail.com>
>>> > >>> wrote:
>>> > >>> >
>>> > >>> > It looks like this is again problem with
>>> RoyaleUnit[1].
>>> > Here
>>> > >>> is the
>>> > >>> > results
>>> > >>> > of comparison. I'm not sure why left folder
>>> doesn't
>>> > contains
>>> > >>> files.
>>> > >>> >
>>> > >>> > [1]
>>> > >>> >
>>> > >>>
>>> >
>>>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpasteboard.co%2FIsWnHGq.pngdata=02%7C01%7Caharui%40adobe.com%7Cee362a70359f471e8aed08d729ebc5cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637023964926048393sdata=w0ixJ5SmSTDQbC7gMpzTit5MTQkZBFsHerit8qf%2FYvU%3Dreserved=0
>>> > >>> >
>>> > >>> > Thanks,
>>> > >>> > Piotr
>>> > >>> >
>>> > >>> > pt., 16 sie 2019 o 11:08 Piotr Zarzycki <
>>> > >>> piotrzarzyck...@gmail.com>
>>> > >>> > napisał(a):
>>> > >>> >
>>> > >>> > > Ok I was mistake. Both zips exists, but they
>>> have
>>> > different
>>> > >>> sizes! So
>>> > >>> > > comparison went fine and I need to understand
>>> one
>>> > sources are
>>> > >>> > different...
>>> > >>> > >
>>> > >>> > > pt., 16 sie 2019 o 10:59 Piotr Zarzycki <
>>> > >>> piotrzarzyck...@gmail.com>
>>> > >>> > > napisał(a):
>>> > >>> > >
>>> > >>> > >> I have analyzed that target
(compare-src-zips)
>>> and it
>>> > >>> compares zip
>>> > >>> > file
>>> > >>> > >> in following locations:
>>> > >>> > >>
>>> > >>> > >> 1) artifacts\apache-royale-0.9.6-src.zip
>>> > >>> > >> 2)
/sources/srczip/apache-royale-0.9.6-src.zip
>>> > >>> > >>
>>> > >>> > >> I have changed in that target all places
where
>>> > >>> ${artifactfolder} to
>>> > >>> > >> ../../${artifactfolder} and launch that
>>> target. It
>>> > looks
>>> > >>> like zip
>>> > >>> > file
>>> > >>> > >> wasn't created at all in location:
>>> > >>> > >> /sources/srczip/apache-royale-0.9.6-src.zip.
>>> > >>> > >>
>>> > >>> > >> I will try to figure out what has happened.
>>> Btw. I
>>> > didn't
>>> > >>> commit my
>>> > >>> > >> changes with ../../ - those are local.
>>> > >>> > >>
>>> > >>> > >> Thanks,
>>> > >>> > >> Piotr
>>> > >>> > >>
>>> > >>> > >> pt., 16 sie 2019 o 09:29 Piotr Zarzycki <
>>> > >>> piotrzarzyck...@gmail.com>
>>> > >>> > >> napisał(a):
>>> > >>> > >>
>>> > >>> > >>> Unfortunately I don't know what is happening
>>> but
>>> > signing
>>> > >>> trough
>>> > >>> > script
>>> > >>> > >>> hang for me. Stopped working. :(
>>> > >>> > >>>
>>> > >>> > >>>
>>> > >>> > >>> ant -f releasesteps.xml
Release_Step_003_Sign
>>> > >>> > -Drelease.version=0.9.6
>>> > >>> > >>> Buildfile:
>>> > >>> d:\Work\royale-sources\royale-compiler\releasesteps.xml
>>> > >>> > >>>
>>> > >>> > >>> get-artifact-folder:
>>> > >>> > >>> [input] Enter the temporary folder to
>>> store the
>>> > >>> downloaded
>>> > >>> > artifacts:
>>> > >>> > >>> royale096
>>> > >>> > >>>
>>> > >>> > >>> Release_Step_003_Sign:
>>> > >>> > >>>
>>> > >>> > >>> sign-file:
>>> > >>> > >>>
>>> > >>>

-- 
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


Re: Proposed change to inject_html

2019-08-20 Thread Josh Tynjala
> but opening almost every JS file twice doesn't make sense to me.

We agree completely on this.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Aug 20, 2019 at 11:21 AM Alex Harui 
wrote:

> Doesn't your plan assume that searching for a potentially (and probably)
> missing companion file is faster than opening and scanning a few lines of
> an known-to-exist file?  That's opposite of what I thought was the case.
>
> I haven't looked closely at how things work today, but I thought we were
> searching every JS file for @extern annotations (as well as remove-circular
> info) and adding files with @externs to the externs list.  Maybe that code
> no longer runs these days with recent changes to better handle source
> externs.  But also check externs from typedefs SWCs.  There may be other
> ways files get added to the externs list.
>
> I'm not opposed to refactoring to improve performance and consider
> separating dependency on the Closure Compiler, but opening almost every JS
> file twice doesn't make sense to me.
>
> Another idea may be searching the externs as they are being copied to the
> output folder.  Maybe there should be some data structure that various file
> handlers contribute to.  Maybe there should be more Publisher classes with
> a base class that the Closure Publisher overrides to further scan the files
> for remove circular dependencies.
>
> Maybe I'm too old, but my recollection was that opening files was more
> expensive than reading opened files so I'm hoping we can avoid doing that.
>
> -Alex
>
> On 8/20/19, 11:03 AM, "Josh Tynjala"  wrote:
>
> Since externs can also include inject_html, and externs don't have
> circulars to remove, it would faster to find inject_html in those files
> using this proposed method.
>
> It's true that remove-circulars already opens and reads the JS files.
> However, by including the check for inject_html in there, we had code
> that
> was more complicated than it needed to be only to gain the
> optimization of
> opening and reading JS file a single time. Extracting the inject_html
> detection makes the GoogDepsWriter code more focused, which means it's
> less
> effort for a developer to understand what the code is doing. In my
> experience, there's a lot to process there to fully understand it all.
> One
> fewer thing will help. Additionally, in the future, should we decide
> to add
> a separate workflow that uses something other than Closure compiler to
> create a release build (maybe something involving the newer native JS
> modules), the inject_html detection code will not be as tightly
> coupled and
> can be reused more easily.
>
> Finally, in my opinion, the less we need to read generated JS files to
> search for special strings, the better. It may not be possible to
> avoid it
> completely, but this is a place where we can avoid that.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Ce071bbe36e6848e8731208d72598c074%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637019210332973330sdata=0cNEXnLCkz48JYr3RRXgyJj%2FMQzc%2Fp27pCT70ozU8DQ%3Dreserved=0
> >
>
>
> On Tue, Aug 20, 2019 at 10:31 AM Alex Harui 
> wrote:
>
> > IMO, we have to open and read each JS file anyway for
> remove-circulars, so
> > it isn't clear that looking for additional companion files is going
> to be
> > faster than scanning an already open file.  We could make the
> inject_html
> > easier to find by moving it higher up in the JS file.
> >
> > My 2 cents,
> > -Alex
> >
> > On 8/20/19, 10:25 AM, "Josh Tynjala" 
> wrote:
> >
> >  I would like to propose a change to how we handle inject_html.
> >
> > Currently, it works like this: We define an  tag in
> an
> > asdoc
> > comment. That tag gets copied to a jsdoc comment when we emit JS
> code.
> > When
> > we build an app, we search through the JS files line by line to
> find
> > .
> >
> > I think that, when we emit JS files, it would be beneficial to
> emit a
> > separate file that contains the inject_html content.
> >
> > So, you'd get a JS file, like we have now:
> >
> > com/example/MyClass.js
> >
> > Then, if the class contains inject_html, you'd also get:
> >
> > com/example/MyClass.js.html
> >
> > This is similar,

Re: Proposed change to inject_html

2019-08-20 Thread Josh Tynjala
Since externs can also include inject_html, and externs don't have
circulars to remove, it would faster to find inject_html in those files
using this proposed method.

It's true that remove-circulars already opens and reads the JS files.
However, by including the check for inject_html in there, we had code that
was more complicated than it needed to be only to gain the optimization of
opening and reading JS file a single time. Extracting the inject_html
detection makes the GoogDepsWriter code more focused, which means it's less
effort for a developer to understand what the code is doing. In my
experience, there's a lot to process there to fully understand it all. One
fewer thing will help. Additionally, in the future, should we decide to add
a separate workflow that uses something other than Closure compiler to
create a release build (maybe something involving the newer native JS
modules), the inject_html detection code will not be as tightly coupled and
can be reused more easily.

Finally, in my opinion, the less we need to read generated JS files to
search for special strings, the better. It may not be possible to avoid it
completely, but this is a place where we can avoid that.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Aug 20, 2019 at 10:31 AM Alex Harui 
wrote:

> IMO, we have to open and read each JS file anyway for remove-circulars, so
> it isn't clear that looking for additional companion files is going to be
> faster than scanning an already open file.  We could make the inject_html
> easier to find by moving it higher up in the JS file.
>
> My 2 cents,
> -Alex
>
> On 8/20/19, 10:25 AM, "Josh Tynjala"  wrote:
>
>  I would like to propose a change to how we handle inject_html.
>
> Currently, it works like this: We define an  tag in an
> asdoc
> comment. That tag gets copied to a jsdoc comment when we emit JS code.
> When
> we build an app, we search through the JS files line by line to find
> .
>
> I think that, when we emit JS files, it would be beneficial to emit a
> separate file that contains the inject_html content.
>
> So, you'd get a JS file, like we have now:
>
> com/example/MyClass.js
>
> Then, if the class contains inject_html, you'd also get:
>
> com/example/MyClass.js.html
>
> This is similar, in a way, to how there's a MyClass.js.map file when
> source
> maps are enabled.
>
> With this change, instead of loading MyClass.js and parsing it line by
> line
> looking for inject_html, we could simply check to see if
> MyClass.js.html
> exists in the same folder (or in the same SWC). This should help us
> detect
> inject_html much faster and without needing to try to parse JS files.
>
> Thoughts?
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cd6daa4ae9b744b8a195c08d725935cbb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637019187152937419sdata=gSsOaEcI5J%2BaRg8T28eIJoYniqsZd%2F8BsYGjsavlfTg%3Dreserved=0
> >
>
>
>


Proposed change to inject_html

2019-08-20 Thread Josh Tynjala
 I would like to propose a change to how we handle inject_html.

Currently, it works like this: We define an  tag in an asdoc
comment. That tag gets copied to a jsdoc comment when we emit JS code. When
we build an app, we search through the JS files line by line to find
.

I think that, when we emit JS files, it would be beneficial to emit a
separate file that contains the inject_html content.

So, you'd get a JS file, like we have now:

com/example/MyClass.js

Then, if the class contains inject_html, you'd also get:

com/example/MyClass.js.html

This is similar, in a way, to how there's a MyClass.js.map file when source
maps are enabled.

With this change, instead of loading MyClass.js and parsing it line by line
looking for inject_html, we could simply check to see if MyClass.js.html
exists in the same folder (or in the same SWC). This should help us detect
inject_html much faster and without needing to try to parse JS files.

Thoughts?

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


Re: Discuss of release steps preparation

2019-08-15 Thread Josh Tynjala
If it started working correctly after changing the path to include ../../,
perhaps ${artifactfolder} is being set to a relative path, but the script
expects the path to be absolute. I'm not familiar with the release steps
yet, so I'm just guessing, but does that make sense?

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Aug 14, 2019 at 9:23 AM Alex Harui  wrote:

> Can you explain why that would be the right change?  Doesn't make sense to
> me.
>
> On 8/14/19, 3:36 AM, "Piotr Zarzycki"  wrote:
>
> So far so good. I did tweak the script and was able to upload
> artifacts. I
> have changed in each script:
> Line from:
>
> 
> To
> 
>
> The very last thing was close repository, so I got some errors you can
> check here by logging your Apache handle [1] related to RoyaleUnit [2].
>
> Missing Signature:
>
> '/org/apache/royale/compiler/royaleunit-ant-tasks/0.9.6/royaleunit-ant-tasks-0.9.6.pom.asc'
> does not exist for 'royaleunit-ant-tasks-0.9.6.pom'.
>
> I will try to figure out what has happened, but if someone has any
> clue to
> that let me know.
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2F%23stagingRepositoriesdata=02%7C01%7Caharui%40adobe.com%7Ccc49916dedd948ec37a408d720a330e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637013757624763085sdata=MBN%2FVae7WMZ6YWOD8fQumGivlLwaxfFNwmNE59%2F61Rc%3Dreserved=0
> [2]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpasteboard.co%2FIsDKVTe.pngdata=02%7C01%7Caharui%40adobe.com%7Ccc49916dedd948ec37a408d720a330e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637013757624763085sdata=wiTOzckxfuKk9whMWtP1ZbBQ8nPygJb7ORnT0yvLKiM%3Dreserved=0
>
> Thanks,
> Piotr
>
>
> śr., 14 sie 2019 o 10:58 Carlos Rovira 
> napisał(a):
>
> > Hi Alex,
> >
> > El lun., 12 ago. 2019 a las 19:30, Alex Harui
> ()
> > escribió:
> >
> > > Also, the other committers should be aware that an RC is being
> created
> > > because they see the emails being sent by the CI server and ask
> the RM to
> > > agree to accept a commit to the release branch instead of the
> develop
> > > branch.
> >
> >
> > AFAIK, we should always commit to dev branch and not to release
> branch.
> > Releases are cut from develop. Only hot-fixes use to be branches
> that have
> > commits that fix something important in the release and then use to
> be
> > merged back to develop and master. Making commits to release
> branches could
> > bring some confusion and problems.
> >
> > At least from is what I always learnt and used [1]
> >
> > [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvie.com%2Fposts%2Fa-successful-git-branching-model%2Fdata=02%7C01%7Caharui%40adobe.com%7Ccc49916dedd948ec37a408d720a330e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637013757624763085sdata=wH%2B2sM0uBA8CdSRbaaniZdqaHrRk6hnIwdYZPJHTVLA%3Dreserved=0
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Ccc49916dedd948ec37a408d720a330e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637013757624763085sdata=ncu5xXT3rnbQG%2BKTZBO6sX61T5gWfOiicgAIXQy8%2F8Y%3Dreserved=0
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzyckidata=02%7C01%7Caharui%40adobe.com%7Ccc49916dedd948ec37a408d720a330e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637013757624773080sdata=CY1fo%2FqTgW%2B8Jtx32I7bw%2B0k7ys3iNJ2zxjT3p7P1cU%3Dreserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzyckidata=02%7C01%7Caharui%40adobe.com%7Ccc49916dedd948ec37a408d720a330e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637013757624773080sdata=CY1fo%2FqTgW%2B8Jtx32I7bw%2B0k7ys3iNJ2zxjT3p7P1cU%3Dreserved=0
> >*
>
>
>


Re: Minification problem with latest build

2019-08-12 Thread Josh Tynjala
Okay, this should be working correctly now.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Aug 12, 2019 at 10:36 AM Josh Tynjala 
wrote:

> I've determined that when js-dynamic-access-unknown-members is true, a
> fully-qualified name is output differently:
>
> org["apache"]["royale"]["jewel"]["beads"]["models"].FormItemModel
>
> A fully-qualified name should not be considered dynamic access, though, so
> that's a bug. I'll try to get it fixed.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Fri, Aug 9, 2019 at 3:52 AM Piotr Zarzycki 
> wrote:
>
>> Hi Guys,
>>
>> Many Thanks for your answers. I figure out what has happened. Following
>> line causes an issue:
>>
>>
>> _strand.getBeadByType(org.apache.royale.jewel.beads.models.FormItemModel)
>> as
>> org.apache.royale.jewel.beads.models.FormItemModel;
>>
>>
>>
>> When I change that to:
>>
>>
>> _strand.getBeadByType(FormItemModel) as FormItemModel;
>>
>>
>>
>> Everything has started to work. Is it compiler's issue ? It sounds to that
>> it should work.
>>
>> Thanks,
>> Piotr
>>
>> czw., 8 sie 2019 o 14:05 Piotr Zarzycki 
>> napisał(a):
>>
>> > Hi Harbs,
>> >
>> > If I build my code with: -js-dynamic-access-unknown-members=false I'm
>> > getting in that line following code [1] - look into place around: a.
>> > parentNode&_wrapper.
>> >
>> > Having -js-dynamic-access-unknown-members=false - making an application
>> > work.
>> >
>> > By unminified do you mean to provide debug version of code ?
>> >
>> > [1] https://paste.apache.org/rnmxg
>> >
>> > Thanks,
>> > Piotr
>> >
>> > czw., 8 sie 2019 o 12:03 Harbs  napisał(a):
>> >
>> >> N('org.apache.royale.events.getTargetWrapper',tP.If)
>> >>
>> >> tP.If is an alias to the package level function getTargetWrapper. My
>> >> guess is that package level functions have an issue.
>> >>
>> >> Presumable, tP is org.apache.royale.events, which only makes sense if
>> >> org.apache.royale.events would have been a class.
>> >>
>> >> What’s the un-minified output?
>> >>
>> >> > On Aug 8, 2019, at 12:20 PM, Piotr Zarzycki <
>> piotrzarzyck...@gmail.com>
>> >> 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
>> >> > <https://www.patreon.com/piotrzarzycki>*
>> >>
>> >>
>> >
>> > --
>> >
>> > Piotr Zarzycki
>> >
>> > Patreon: *https://www.patreon.com/piotrzarzycki
>> > <https://www.patreon.com/piotrzarzycki>*
>> >
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> <https://www.patreon.com/piotrzarzycki>*
>>
>


Re: Minification problem with latest build

2019-08-12 Thread Josh Tynjala
I've determined that when js-dynamic-access-unknown-members is true, a
fully-qualified name is output differently:

org["apache"]["royale"]["jewel"]["beads"]["models"].FormItemModel

A fully-qualified name should not be considered dynamic access, though, so
that's a bug. I'll try to get it fixed.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Fri, Aug 9, 2019 at 3:52 AM Piotr Zarzycki 
wrote:

> Hi Guys,
>
> Many Thanks for your answers. I figure out what has happened. Following
> line causes an issue:
>
>
> _strand.getBeadByType(org.apache.royale.jewel.beads.models.FormItemModel)
> as
> org.apache.royale.jewel.beads.models.FormItemModel;
>
>
>
> When I change that to:
>
>
> _strand.getBeadByType(FormItemModel) as FormItemModel;
>
>
>
> Everything has started to work. Is it compiler's issue ? It sounds to that
> it should work.
>
> Thanks,
> Piotr
>
> czw., 8 sie 2019 o 14:05 Piotr Zarzycki 
> napisał(a):
>
> > Hi Harbs,
> >
> > If I build my code with: -js-dynamic-access-unknown-members=false I'm
> > getting in that line following code [1] - look into place around: a.
> > parentNode&_wrapper.
> >
> > Having -js-dynamic-access-unknown-members=false - making an application
> > work.
> >
> > By unminified do you mean to provide debug version of code ?
> >
> > [1] https://paste.apache.org/rnmxg
> >
> > Thanks,
> > Piotr
> >
> > czw., 8 sie 2019 o 12:03 Harbs  napisał(a):
> >
> >> N('org.apache.royale.events.getTargetWrapper',tP.If)
> >>
> >> tP.If is an alias to the package level function getTargetWrapper. My
> >> guess is that package level functions have an issue.
> >>
> >> Presumable, tP is org.apache.royale.events, which only makes sense if
> >> org.apache.royale.events would have been a class.
> >>
> >> What’s the un-minified output?
> >>
> >> > On Aug 8, 2019, at 12:20 PM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> >> 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
> >> > <https://www.patreon.com/piotrzarzycki>*
> >>
> >>
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>


Re: Builds

2019-08-09 Thread Josh Tynjala
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: [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 Josh Tynjala
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(-)
> >
> > 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.JSGoogEmitter

Re: Separate @extern classes in Jewel to a new externs library

2019-07-25 Thread Josh Tynjala
Typedefs are not required to be .js files. The Royale compiler knows how to
compile .as files with @externs metadata. In fact, that's what was already
happening when dialogPolyfill was located in the Jewel project. You should
be able to set up a project in royale-typedefs that is built similarly to
Jewel and the other framework projects that contain .as files.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Thu, Jul 25, 2019 at 12:47 PM Carlos Rovira 
wrote:

> Hi Josh,
>
> trying to move dialogPolyfill to royale-typedefs: I only see *.js classes.
> I can't find any *.as class in that repo. This means I need to transform
> dialogPolyfill to js? In fact some weeks ago dialogPolifyll was in that
> format in missing.js...
>
> El jue., 25 jul. 2019 a las 21:21, Carlos Rovira ( >)
> escribió:
>
> > Hi Josh,
> >
> > ok, I suppose dialogPolyfill could go to typedefs and hljs to the example
> > project, but just posted a problem I just found trying to do so with the
> > later
> >
> > El jue., 25 jul. 2019 a las 21:19, Josh Tynjala (<
> > joshtynj...@bowlerhat.dev>) escribió:
> >
> >> dialogPolyfill and hljs are not in any wayt related to each other,
> except
> >> the fact that they're both used in Jewel. With that in mind, I think
> that
> >> they belong in separate libraries.
> >>
> >> I also think that we should add these libraries to royale-typedefs
> instead
> >> of royale-asjs.
> >>
> >> --
> >> Josh Tynjala
> >> Bowler Hat LLC <https://bowlerhat.dev>
> >>
> >>
> >> On Thu, Jul 25, 2019 at 11:56 AM Carlos Rovira  >
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > as we already discussed, we have some @extern classes in Jewel that
> >> should
> >> > be located in its own library for @extern classes, since can be used
> for
> >> > Jewel or many other code that does not need Jewel.
> >> >
> >> > So I want to ask for a name for that library where we can add this
> >> classes
> >> > (for now dialogPolyfill and hljs) and other that will be needed in the
> >> > future.
> >> > I'm thinking in call that library "Externs" (Externs.swc).
> >> >
> >> > Let me know what you think
> >> >
> >> > thanks
> >> >
> >> > --
> >> > Carlos Rovira
> >> > http://about.me/carlosrovira
> >> >
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: Separate @extern classes in Jewel to a new externs library

2019-07-25 Thread Josh Tynjala
dialogPolyfill and hljs are not in any wayt related to each other, except
the fact that they're both used in Jewel. With that in mind, I think that
they belong in separate libraries.

I also think that we should add these libraries to royale-typedefs instead
of royale-asjs.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Thu, Jul 25, 2019 at 11:56 AM Carlos Rovira 
wrote:

> Hi,
>
> as we already discussed, we have some @extern classes in Jewel that should
> be located in its own library for @extern classes, since can be used for
> Jewel or many other code that does not need Jewel.
>
> So I want to ask for a name for that library where we can add this classes
> (for now dialogPolyfill and hljs) and other that will be needed in the
> future.
> I'm thinking in call that library "Externs" (Externs.swc).
>
> Let me know what you think
>
> thanks
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: library-path changes

2019-07-22 Thread Josh Tynjala
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: library-path changes

2019-07-22 Thread Josh Tynjala
When you compile a SWC, the framework libraries need to be on
external-library-path (or js-external-library-path or
swf-external-library-path). When you changed forceSwcExternalLibraryPath to
false, this may have moved some of the libraries to the library-path
instead. You don't want that. You can check the
target/compile-js-config.xml file generated for your library to see if
Maven is using library-path or external-library-path for each framework SWC.

I took a look at the source code for the Royale Maven tasks. To add a
framework library to the external-library-path, you need to specify the
scope in pom.xml. It should be either "provided" or "runtime" to add them
to the external-library-path instead of the library-path. I don't know what
the difference between "provided" and "runtime" is, but I assume that you
do since you know Maven much better than I do.

I should point out that you should use "provided" or "runtime" for
framework SWCs only when you are when compiling a SWC. When compiling an
app, you definitely want these SWCs added to the library-path.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Jul 22, 2019 at 9:59 AM Carlos Rovira 
wrote:

> Hi,
>
> the compilation was ok, but I'm facing now a blank page. I'm getting in
> debug mode:
>
> [Error] Error: Undefined nameToPath for
> org.apache.royale.events.EventDispatcher
> visitNode (base.js:1357)
> visitNode (base.js:1355)
> visitNode (base.js:1355)
> writeScripts_ (base.js:1369)
> require (base.js:706)
> Código global (tablet-debug:418)
>
> and
>
> [Error] ReferenceError: Can't find variable: App
> Código global (tablet-debug:425)
>
>
> do you know what's could be wrong?
>
> thanks
>
> Carlos
>
>
>
>
>
> El lun., 22 jul. 2019 a las 18:33, Carlos Rovira ( >)
> escribió:
>
> > Hi,
> >
> > I think finally reach to the problem, I had more of this in each library
> >
> > true
> >
> > So now I'm getting all the rest libs compiling properly
> >
> > thanks for the help :)
> >
> > Carlos
> >
> >
> >
> >
> >
> > El lun., 22 jul. 2019 a las 18:32, Carlos Rovira (<
> carlosrov...@apache.org>)
> > escribió:
> >
> >> I get the following progress:
> >>
> >> first library was compiled by commenting forceSwcExternalLibraryPath
> >> since I have all libraries in the same folder "roaylelibs"
> >>
> >> 
> >> 
> >> 
> >> org.apache.royale.compiler
> >> royale-maven-plugin
> >> ${royale.compiler.version}
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >>
> >> but now the next one is failing in the same way as the previous one was
> >> failing :?
> >>
> >> I removed all compile-swf-config.xml in all projects, and what I don't
> >> understand is where comes the config maven is using:
> >>
> >> Executing COMPC in tool group Royale with args:
> >>
> [-load-config=/Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royaledto/target/compile-swf-config.xml,
> >> -js-default-initializers=false, -source-map=true,
> >> -compiler.targets=SWF,JSRoyale, -compiler.strict-xml=true]
> >>
> >>
> >>
> >>
> >>
> >>
> >> El lun., 22 jul. 2019 a las 18:14, Carlos Rovira (<
> >> carlosrov...@apache.org>) escribió:
> >>
> >>> I think the license header would be added in all files at some point
> for
> >>> all files to prevent RAT plugin to make compilation fail, so I'm
> figuring
> >>> it was something done manual
> >>>
> >>> El lun., 22 jul. 2019 a las 17:57, Josh Tynjala (<
> >>> joshtynj...@bowlerhat.dev>) escribió:
> >>>
> >>>> You're right. I remember seeing that the Royale Maven plugin generates
> >>>> compile-swf-config.xml and compile-js-config.xml.
> >>>>
> >>>> It's strange that your Codeoscopic copyright header is added to
> >>>> compiler-swf-config.xml, though. I wouldn't expect Maven to do that...
> >>>> unless maybe you have some other plugin that adds it?
> >>>>
> >>>> --
> >>>> Josh Tynjala
> >>>> Bowler Hat LLC <https://bowlerhat.dev>
> >>>>
> >>>>
> >>>> On Mon, Jul 22, 2019 at 8:49 AM Carlos Rovira <
> carlosrov...@apache.org>
> >>>> wrote:
> >>>>
>

Re: library-path changes

2019-07-22 Thread Josh Tynjala
You're right. I remember seeing that the Royale Maven plugin generates
compile-swf-config.xml and compile-js-config.xml.

It's strange that your Codeoscopic copyright header is added to
compiler-swf-config.xml, though. I wouldn't expect Maven to do that...
unless maybe you have some other plugin that adds it?

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Jul 22, 2019 at 8:49 AM Carlos Rovira 
wrote:

> Hi Josh,
>
> since my build is JS, I removed all "compile-swf-config.xml", but executing
> again "mvn clean install", makes a "compile-swf-config.xml" file be
> generated in target folder
> so I think is something in royale maven plugin that creates that file in
> target folder. But is strange since as I say I'm working against JS
> although SWF is present but although always was compiling ok, it does not
> really works since Jewel is still not implemented fully in SWF
>
> El lun., 22 jul. 2019 a las 17:35, Josh Tynjala (<
> joshtynj...@bowlerhat.dev>)
> escribió:
>
> > The append attribute has existed since the Flex days.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Mon, Jul 22, 2019 at 8:34 AM Carlos Rovira 
> > wrote:
> >
> > > Hi Harbs,
> > > thanks, the append attribute is new one? it was introduced recently?
> > >
> > > thanks
> > >
> > > El lun., 22 jul. 2019 a las 17:29, Harbs ()
> > > escribió:
> > >
> > > > Make sure you have for the JS config:
> > > > 
> > > >
> > > > The append wil make sure you keep the default values.
> > > >
> > > > Here’s where I updated some of the libs I’m using:
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/unhurdle/cep-royale/commit/35d45906035e3d1997d70a67893cc096307a3842
> > > > <
> > > >
> > >
> >
> https://github.com/unhurdle/cep-royale/commit/35d45906035e3d1997d70a67893cc096307a3842
> > > > >
> > > >
> > > >
> > >
> >
> https://github.com/unhurdle/spectrum-royale/commit/2f6e1b5ed25cc57585d6879fbcf2ccae79d57d28
> > > > <
> > > >
> > >
> >
> https://github.com/unhurdle/spectrum-royale/commit/2f6e1b5ed25cc57585d6879fbcf2ccae79d57d28
> > > > >
> > > >
> > > > > On Jul 22, 2019, at 6:20 PM, Carlos Rovira <
> carlosrov...@apache.org>
> > > > wrote:
> > > > >
> > > > > Hi Josh,
> > > > >
> > > > > playerglobal.swc is ok, but can you point me to some place where
> > > "js.swc"
> > > > > is used?
> > > > >
> > > > > contents of compile-swf-config.xml are the following:
> > > > >
> > > > > 
> > > > > 
> > > > >
> > > > > 
> > > > > false
> > > > > 
> > > > > 
> > > > > SWF
> > > > > JSRoyale
> > > > > 
> > > > > true
> > > > >
> > > > > 
> > > > > ${env.AIR_HOME}/frameworks/libs/air/airglobal.swc > > > > path-element>
> > > > > ../../../../../libs/Binding.swc
> > > > > ../../../../../libs/Core.swc
> > > > > ../../../../../libs/Graphics.swc
> > > > > ../../../../../libs/Collections.swc
> > > > > ../../../../../libs/Basic.swc
> > > > > 
> > > > > true
> > > > >
> > > > >true
> > > > >
> > > > >
> > > > >
> > org.apache.royale.events.ValueChangeEvent
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.royale.events.ValueChangeEvent
> > > > >valueChange > > > > binding-value-change-event-type>
> > > > >
> > > > > 
> > > > > COMPILE::SWF
> > > > > true
> > > > > 
> > > > > 
> > > > > COMPILE::JS
> > > > > false
> > > > > 
> > > > >
> > > > > 
> > > > > Bindable
> > > > > Managed
> > > > > ChangeEvent
> > > > > NonCommittingChangeEvent
> > > > > Transient
> > > > > 
> > > > >
> > > > > 
> > > > &g

Re: library-path changes

2019-07-22 Thread Josh Tynjala
The append attribute has existed since the Flex days.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Jul 22, 2019 at 8:34 AM Carlos Rovira 
wrote:

> Hi Harbs,
> thanks, the append attribute is new one? it was introduced recently?
>
> thanks
>
> El lun., 22 jul. 2019 a las 17:29, Harbs ()
> escribió:
>
> > Make sure you have for the JS config:
> > 
> >
> > The append wil make sure you keep the default values.
> >
> > Here’s where I updated some of the libs I’m using:
> >
> >
> >
> https://github.com/unhurdle/cep-royale/commit/35d45906035e3d1997d70a67893cc096307a3842
> > <
> >
> https://github.com/unhurdle/cep-royale/commit/35d45906035e3d1997d70a67893cc096307a3842
> > >
> >
> >
> https://github.com/unhurdle/spectrum-royale/commit/2f6e1b5ed25cc57585d6879fbcf2ccae79d57d28
> > <
> >
> https://github.com/unhurdle/spectrum-royale/commit/2f6e1b5ed25cc57585d6879fbcf2ccae79d57d28
> > >
> >
> > > On Jul 22, 2019, at 6:20 PM, Carlos Rovira 
> > wrote:
> > >
> > > Hi Josh,
> > >
> > > playerglobal.swc is ok, but can you point me to some place where
> "js.swc"
> > > is used?
> > >
> > > contents of compile-swf-config.xml are the following:
> > >
> > > 
> > > 
> > >
> > > 
> > > false
> > > 
> > > 
> > > SWF
> > > JSRoyale
> > > 
> > > true
> > >
> > > 
> > > ${env.AIR_HOME}/frameworks/libs/air/airglobal.swc > > path-element>
> > > ../../../../../libs/Binding.swc
> > > ../../../../../libs/Core.swc
> > > ../../../../../libs/Graphics.swc
> > > ../../../../../libs/Collections.swc
> > > ../../../../../libs/Basic.swc
> > > 
> > > true
> > >
> > >true
> > >
> > >
> > > org.apache.royale.events.ValueChangeEvent
> > >
> > >
> >
> org.apache.royale.events.ValueChangeEvent
> > >valueChange > > binding-value-change-event-type>
> > >
> > > 
> > > COMPILE::SWF
> > > true
> > > 
> > > 
> > > COMPILE::JS
> > > false
> > > 
> > >
> > > 
> > > Bindable
> > > Managed
> > > ChangeEvent
> > > NonCommittingChangeEvent
> > > Transient
> > > 
> > >
> > > 
> > > 
> > >
> > > 
> > > 
> > > library://ns.apache.org/royale/basic
> > > ../resources/icons-manifest.xml
> > > 
> > > 
> > > 
> > > ../royale
> > > 
> > > false
> > > 
> > > 
> > > IconsClasses
> > > 
> > > 
> > > library://ns.apache.org/royale/basic
> > > 
> > > ${playerglobal.version}
> > >
> > > 
> > >
> > >
> > >
> > > I don't know too much about this file, have we docs about it?
> > > the compiler generates the file itself?
> > > it uses the global config.xml as a base?
> > >
> > > thanks Josh
> > >
> > >
> > > El lun., 22 jul. 2019 a las 17:01, Josh Tynjala (<
> > joshtynj...@bowlerhat.dev>)
> > > escribió:
> > >
> > >> Error: Missing builtin type Object
> > >>
> > >> This error usually means that either playerglobal.swc or js.swc is
> > missing.
> > >>
> > >> It would be difficult to suggest anything more without seeing the
> > contents
> > >> of compile-swf-config.xml.
> > >>
> > >> --
> > >> Josh Tynjala
> > >> Bowler Hat LLC <https://bowlerhat.dev>
> > >>
> > >>
> > >> On Mon, Jul 22, 2019 at 7:50 AM Carlos Rovira <
> carlosrov...@apache.org>
> > >> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> after latest changes with "library-path" I'm trying to update my
> > project
> > >>> with no luck.
> > >>>
> > >>> Hope someone could let me know some guide since all what I tried
> didn't
> > >>> work and always get this:
> > >>>
> > >>> [*INFO*] *--- *royale-maven-plugin:0.9.6-SNAPSHOT:compile-as
> > >>> *(default-compile-as)* @ royalejewel* ---*
> > >>>
> > >>> [*INFO*] Executing COMPC in tool group Royale with args:
> > >>>
> > >>>
> > >>
> >
> [-load-config=/Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royalejewel/target/compile-swf-config.xml,
> > >>> -js-default-initializers=false, -source-map=true,
> > >>> -compiler.targets=SWF,JSRoyale, -compiler.strict-xml=true]
> > >>>
> > >>> args:
> > >>>
> > >>>
> > >>>
> > >>
> >
> -load-config=/Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royalejewel/target/compile-swf-config.xml
> > >>>
> > >>> -js-default-initializers=false
> > >>>
> > >>> -source-map=true
> > >>>
> > >>> -compiler.targets=SWF,JSRoyale
> > >>>
> > >>> -compiler.strict-xml=true
> > >>>
> > >>> target:SWF
> > >>>
> > >>> target:JSRoyale
> > >>>
> > >>> COMPC
> > >>>
> > >>> Loading configuration:
> > >>>
> > >>>
> > >>
> >
> /Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royalejewel/target/compile-swf-config.xml
> > >>>
> > >>>
> > >>> Error: Missing builtin type Object
> > >>>
> > >>>
> > >>>
> > >>> Missing builtin type Object
> > >>>
> > >>>
> > >>>
> > >>> 0.553372072 seconds
> > >>>
> > >>> this is failing when maven tries to compile the first library project
> > >>>
> > >>> Thanks for any light on this
> > >>>
> > >>> --
> > >>> Carlos Rovira
> > >>> http://about.me/carlosrovira
> > >>>
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: library-path changes

2019-07-22 Thread Josh Tynjala
You created compile-swf-config.xml in your own project. It is not generated
by the compiler.

You are loading it with this compiler option:

-load-config=/Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royalejewel/target/compile-swf-config.xml


Normally, it would extend the defaults in frameworks/royale-config.xml from
your SDK. Since you build with Maven, it is probably extending some
defaults defined by the Royale Maven plugin (or maybe the Royale Maven
plugin just uses the compiler's defaults).

js.swc is the main typedefs SWC for JS. This is clearly a SWF build,
though, so it is not relevant right now.

If I had to guess, it's having trouble finding airglobal.swc, since that is
where the Object class would be defined for a SWF build. Maybe the AIR_HOME
environment variable is not set, or it is set to a value that makes this
path invalid:

${env.AIR_HOME}/frameworks/libs/air/airglobal.swc


--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Jul 22, 2019 at 8:20 AM Carlos Rovira 
wrote:

> Hi Josh,
>
> playerglobal.swc is ok, but can you point me to some place where "js.swc"
> is used?
>
> contents of compile-swf-config.xml are the following:
>
> 
> 
>
> 
> false
> 
> 
> SWF
> JSRoyale
> 
> true
>
> 
> ${env.AIR_HOME}/frameworks/libs/air/airglobal.swc path-element>
> ../../../../../libs/Binding.swc
> ../../../../../libs/Core.swc
> ../../../../../libs/Graphics.swc
> ../../../../../libs/Collections.swc
> ../../../../../libs/Basic.swc
> 
> true
> 
> true
> 
> 
> org.apache.royale.events.ValueChangeEvent
> 
> org.apache.royale.events.ValueChangeEvent
> valueChange binding-value-change-event-type>
>
> 
> COMPILE::SWF
> true
> 
> 
> COMPILE::JS
> false
> 
>
> 
> Bindable
> Managed
> ChangeEvent
> NonCommittingChangeEvent
> Transient
> 
>
> 
> 
>
> 
> 
> library://ns.apache.org/royale/basic
> ../resources/icons-manifest.xml
> 
> 
> 
> ../royale
> 
> false
> 
> 
> IconsClasses
> 
> 
> library://ns.apache.org/royale/basic
> 
> ${playerglobal.version}
>
> 
>
>
>
> I don't know too much about this file, have we docs about it?
> the compiler generates the file itself?
> it uses the global config.xml as a base?
>
> thanks Josh
>
>
> El lun., 22 jul. 2019 a las 17:01, Josh Tynjala (<
> joshtynj...@bowlerhat.dev>)
> escribió:
>
> >  Error: Missing builtin type Object
> >
> > This error usually means that either playerglobal.swc or js.swc is
> missing.
> >
> > It would be difficult to suggest anything more without seeing the
> contents
> > of compile-swf-config.xml.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Mon, Jul 22, 2019 at 7:50 AM Carlos Rovira 
> > wrote:
> >
> > > Hi,
> > >
> > > after latest changes with "library-path" I'm trying to update my
> project
> > > with no luck.
> > >
> > > Hope someone could let me know some guide since all what I tried didn't
> > > work and always get this:
> > >
> > > [*INFO*] *--- *royale-maven-plugin:0.9.6-SNAPSHOT:compile-as
> > > *(default-compile-as)* @ royalejewel* ---*
> > >
> > > [*INFO*] Executing COMPC in tool group Royale with args:
> > >
> > >
> >
> [-load-config=/Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royalejewel/target/compile-swf-config.xml,
> > > -js-default-initializers=false, -source-map=true,
> > > -compiler.targets=SWF,JSRoyale, -compiler.strict-xml=true]
> > >
> > > args:
> > >
> > >
> > >
> >
> -load-config=/Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royalejewel/target/compile-swf-config.xml
> > >
> > > -js-default-initializers=false
> > >
> > > -source-map=true
> > >
> > > -compiler.targets=SWF,JSRoyale
> > >
> > > -compiler.strict-xml=true
> > >
> > > target:SWF
> > >
> > > target:JSRoyale
> > >
> > > COMPC
> > >
> > > Loading configuration:
> > >
> > >
> >
> /Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royalejewel/target/compile-swf-config.xml
> > >
> > >
> > > Error: Missing builtin type Object
> > >
> > >
> > >
> > > Missing builtin type Object
> > >
> > >
> > >
> > > 0.553372072 seconds
> > >
> > > this is failing when maven tries to compile the first library project
> > >
> > > Thanks for any light on this
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: library-path changes

2019-07-22 Thread Josh Tynjala
 Error: Missing builtin type Object

This error usually means that either playerglobal.swc or js.swc is missing.

It would be difficult to suggest anything more without seeing the contents
of compile-swf-config.xml.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Jul 22, 2019 at 7:50 AM Carlos Rovira 
wrote:

> Hi,
>
> after latest changes with "library-path" I'm trying to update my project
> with no luck.
>
> Hope someone could let me know some guide since all what I tried didn't
> work and always get this:
>
> [*INFO*] *--- *royale-maven-plugin:0.9.6-SNAPSHOT:compile-as
> *(default-compile-as)* @ royalejewel* ---*
>
> [*INFO*] Executing COMPC in tool group Royale with args:
>
> [-load-config=/Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royalejewel/target/compile-swf-config.xml,
> -js-default-initializers=false, -source-map=true,
> -compiler.targets=SWF,JSRoyale, -compiler.strict-xml=true]
>
> args:
>
>
> -load-config=/Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royalejewel/target/compile-swf-config.xml
>
> -js-default-initializers=false
>
> -source-map=true
>
> -compiler.targets=SWF,JSRoyale
>
> -compiler.strict-xml=true
>
> target:SWF
>
> target:JSRoyale
>
> COMPC
>
> Loading configuration:
>
> /Users/carlosrovira/Dev/Codeoscopic/Source/sgc/royale/royalelibs/royalejewel/target/compile-swf-config.xml
>
>
> Error: Missing builtin type Object
>
>
>
> Missing builtin type Object
>
>
>
> 0.553372072 seconds
>
> this is failing when maven tries to compile the first library project
>
> Thanks for any light on this
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: Maven distribution changes

2019-07-22 Thread Josh Tynjala
It was a step in that direction. I did not test it in VSCode to see if it
had become a valid SDK for code intelligence again. I don't know for sure
what other changes are necessary to make that happen.

- Josh

On Mon, Jul 22, 2019, 6:39 AM Carlos Rovira  wrote:

> Hi Piotr,
>
> I'm asking for this specific commit from Josh: "fixes for config files in
> Maven distribution" : 85333c6f6d0a98e1b0a1ff984e81255a6947942b
> For this reason I asked Josh if this commit was fixing distribution or was
> a step in that direction but doesn't finish to solve the issue.
>
>
> El dom., 21 jul. 2019 a las 21:06, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > Hi Carlos,
> >
> > Without knowing even what were the changes they rather won't give valid
> > SDK. Distribution have never been finished and work as a valid SDK. I was
> > using distribution only as a source of code intelligence a way back in
> > Intellij, cause that IDE were able to use it even it it wasn't fully
> valid
> > sdk.
> >
> > Thanks,
> > Piotr
> >
> > niedz., 21 lip 2019 o 21:02 Carlos Rovira 
> > napisał(a):
> >
> > > Hi Josh,
> > >
> > > I saw your changes for maven distribution and today I want to try if I
> > can
> > > create a Royale SDK with Maven again.
> > >
> > > Using the following command line:
> > >
> > > mvn -s settings-template.xml -P build-distribution clean install
> > >
> > > I get a success build but I think is still not valid SDK since I open a
> > > project in VSCode and as3mxml plugin seems does not recognize a project
> > > like Core, Basic or Jewel.
> > >
> > > I tried as well with other folder and this time the build failed:
> > >
> > > [*INFO*] *--- *maven-assembly-plugin:2.6:single
> > *(create-distro-packages)*
> > > @ distribution* ---*
> > >
> > > [*INFO*] Reading assembly descriptor: src/main/assembly/bin.xml
> > >
> > > [*WARNING*] The following patterns were never triggered in this
> artifact
> > > exclusion filter:
> > >
> > > o  'org.apache.royale.framework:*:swc:typedefs'
> > >
> > >
> > > [*INFO*] Building zip:
> > >
> > >
> >
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/distribution/target/apache-royale-0.9.6-SNAPSHOT-bin.zip
> > >
> > > [*WARNING*] The following patterns were never triggered in this
> artifact
> > > exclusion filter:
> > >
> > > o  'org.apache.royale.framework:*:swc:typedefs'
> > >
> > >
> > > [*INFO*] Building tar:
> > >
> > >
> >
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/distribution/target/apache-royale-0.9.6-SNAPSHOT-bin.tar.gz
> > >
> > > [*INFO*]
> > >
> > > [*INFO*] *--- *maven-assembly-plugin:2.6:single
> > > *(create-distribution-folder)* @ distribution* ---*
> > >
> > > [*INFO*] Reading assembly descriptor: src/main/assembly/dir.xml
> > >
> > > [*WARNING*] The following patterns were never triggered in this
> artifact
> > > exclusion filter:
> > >
> > > o  'org.apache.royale.framework:*:swc:typedefs'
> > >
> > >
> > > [*WARNING*] The following patterns were never triggered in this
> artifact
> > > inclusion filter:
> > >
> > > o  'com.adobe.air.compiler:adt:zip:win'
> > >
> > >
> > > [*WARNING*] NOTE: Your assembly specifies a dependencySet that matches
> > > multiple artifacts, but specifies a concrete output format. THIS MAY
> > RESULT
> > > IN ONE OR MORE ARTIFACTS BEING OBSCURED!
> > >
> > >
> > > Output directory: 'null'
> > >
> > > Output filename mapping: 'frameworks'
> > >
> > > [*WARNING*] The following patterns were never triggered in this
> artifact
> > > inclusion filter:
> > >
> > > o  'com.adobe.air.runtime:adl:exe:win'
> > >
> > >
> > > [*WARNING*] The following patterns were never triggered in this
> artifact
> > > inclusion filter:
> > >
> > > o  'com.adobe.air.runtime:air:zip:win'
> > >
> > >
> > > [*WARNING*] The following patterns were never triggered in this
> artifact
> > > inclusion filter:
> > >
> > > o  'com.adobe.air.runtime:air-captive:zip:win'
> > >
> > >
> > > [*WARNING*] The following patterns were never triggered in this
> artifact
> > > inclusion filter:
> > >
> > > o  'com.adobe:fontkit'
> > >
> > >
> > > [*INFO*] Copying files to /Usuarios/carlosrovira/Dev/Royale/Sdks/.
> > >
> > > [*INFO*]
> > >
> >
> **
> > >
> > > [*INFO*] *Reactor Summary for Apache Royale: Framework: Parent
> > > 0.9.6-SNAPSHOT:*
> > >
> > > [*INFO*]
> > >
> > > [*INFO*] Apache Royale: Framework: Parent ...
> *SUCCESS* [
> > > 2.639 s]
> > >
> > > [*INFO*] compc ..
> *SUCCESS* [
> > > 1.441 s]
> > >
> > > [*INFO*] compiler-asc ...
> *SUCCESS* [
> > > 0.492 s]
> > >
> > > [*INFO*] compiler-compc .
> *SUCCESS* [
> > > 0.391 s]
> > >
> > > [*INFO*] compiler-mxmlc .
> *SUCCESS* [
> > > 0.407 s]
> > >
> > > [*INFO*] compiler-optimizer .
> *SUCCESS* [
> > > 0.392 s]
> > >
> > > [*INFO*] 

Re: Crux Branch

2019-07-17 Thread Josh Tynjala
oid 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 
> > 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 to

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

2019-07-16 Thread Josh Tynjala
Turns out I needed the JAVA_TOOL_OPTIONS environment variable set to
-Dfile.encoding=UTF8 to get the release build working. Closure compiler
doesn't seem to like files that are not UTF-8.

It seemed strange to me that an environment variable was necessary to work
around the issue, so I fixed the problem: The compiler will now always
generate JS as UTF-8.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 16, 2019 at 1:01 PM Josh Tynjala 
wrote:

> I made some tweaks to the royale-maven-plugin to make it properly use
> external-library-path (and js-external-library-path). Now, I can
> successfully create a debug build of TourDeJewel with Maven.
>
> However, it looks like App.js in the release build is empty except for the
> source mapping URL. I'm not sure what's going on there. Maybe I'm running
> the wrong command to have it also produce a release build.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Tue, Jul 16, 2019 at 9:47 AM Josh Tynjala 
> wrote:
>
>> Thanks. I'm investigating.
>>
>> I've figured out that the Maven build is still using library-path (or
>> js-library-path) instead of external-library-path (or
>> js-external-library-path) when building the framework SWCs.
>>
>> If I run "mvn clean install" in frameworks/projects/Jewel, I can see that
>> a target/compile-js-config.xml file is created, and it's using
>> js-library-path for framework SWCs. I'm still figuring out where this
>> config file is coming from and how to change it.
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC <https://bowlerhat.dev>
>>
>>
>> On Tue, Jul 16, 2019 at 9:00 AM Piotr Zarzycki 
>> wrote:
>>
>>> Josh,
>>>
>>> It looks like something is happened actually. Latest build on server
>>> failed, but was able to build all examples and TourDeJewel is not running
>>> [1]
>>>
>>> [1]
>>>
>>> https://builds.apache.org/job/Royale-asjs/1956/artifact/examples/royale/TourDeJewel/target/javascript/bin/js-debug/index.html
>>>
>>> Thanks,
>>> Piotr
>>>
>>> wt., 16 lip 2019 o 17:58 Harbs  napisał(a):
>>>
>>> > These warnings look new:
>>> >
>>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>>> > println
>>> > WARNING: externs/dialogPolyfill.js:15: WARNING - accessing name
>>> > dialogPolyfill in externs has no effect. Perhaps you forgot to add a
>>> var
>>> > keyword?
>>> > dialogPolyfill = function() {
>>> > ^^
>>> >
>>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>>> > println
>>> > WARNING: externs/dialogPolyfill.js:15: WARNING - variable
>>> dialogPolyfill
>>> > is undeclared
>>> > dialogPolyfill = function() {
>>> > ^^
>>> >
>>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>>> > println
>>> > WARNING: externs/dialogPolyfill.js:23: WARNING - name dialogPolyfill is
>>> > not defined in the externs.
>>> > dialogPolyfill.registerDialog = function(dialog) {
>>> > ^^
>>> >
>>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>>> > println
>>> > WARNING: externs/hljs.js:19: WARNING - accessing name hljs in externs
>>> has
>>> > no effect. Perhaps you forgot to add a var keyword?
>>> > hljs = function() {
>>> > 
>>> >
>>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>>> > println
>>> > WARNING: externs/hljs.js:19: WARNING - variable hljs is undeclared
>>> > hljs = function() {
>>> > 
>>> >
>>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>>> > println
>>> > WARNING: externs/hljs.js:27: WARNING - name hljs is not defined in the
>>> > externs.
>>> > hljs.highlightBlock = function(block) {
>>> > 
>>> >
>>> > Any thoughts on this?
>>> >
>>> > > On Jul 15, 2019, at 10:32 PM, Josh Tynjala <
>>> joshtynj...@bowlerhat.dev>
>>> > wrote:
>>> > >
>>> > > Hey folks,
>>> > >
>>> > > I just pushed some commits to royale-compiler and royale-asjs, and I
>>> > wanted
>>> > > to add a li

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

2019-07-16 Thread Josh Tynjala
I made some tweaks to the royale-maven-plugin to make it properly use
external-library-path (and js-external-library-path). Now, I can
successfully create a debug build of TourDeJewel with Maven.

However, it looks like App.js in the release build is empty except for the
source mapping URL. I'm not sure what's going on there. Maybe I'm running
the wrong command to have it also produce a release build.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 16, 2019 at 9:47 AM Josh Tynjala 
wrote:

> Thanks. I'm investigating.
>
> I've figured out that the Maven build is still using library-path (or
> js-library-path) instead of external-library-path (or
> js-external-library-path) when building the framework SWCs.
>
> If I run "mvn clean install" in frameworks/projects/Jewel, I can see that
> a target/compile-js-config.xml file is created, and it's using
> js-library-path for framework SWCs. I'm still figuring out where this
> config file is coming from and how to change it.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Tue, Jul 16, 2019 at 9:00 AM Piotr Zarzycki 
> wrote:
>
>> Josh,
>>
>> It looks like something is happened actually. Latest build on server
>> failed, but was able to build all examples and TourDeJewel is not running
>> [1]
>>
>> [1]
>>
>> https://builds.apache.org/job/Royale-asjs/1956/artifact/examples/royale/TourDeJewel/target/javascript/bin/js-debug/index.html
>>
>> Thanks,
>> Piotr
>>
>> wt., 16 lip 2019 o 17:58 Harbs  napisał(a):
>>
>> > These warnings look new:
>> >
>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>> > println
>> > WARNING: externs/dialogPolyfill.js:15: WARNING - accessing name
>> > dialogPolyfill in externs has no effect. Perhaps you forgot to add a var
>> > keyword?
>> > dialogPolyfill = function() {
>> > ^^
>> >
>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>> > println
>> > WARNING: externs/dialogPolyfill.js:15: WARNING - variable dialogPolyfill
>> > is undeclared
>> > dialogPolyfill = function() {
>> > ^^
>> >
>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>> > println
>> > WARNING: externs/dialogPolyfill.js:23: WARNING - name dialogPolyfill is
>> > not defined in the externs.
>> > dialogPolyfill.registerDialog = function(dialog) {
>> > ^^
>> >
>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>> > println
>> > WARNING: externs/hljs.js:19: WARNING - accessing name hljs in externs
>> has
>> > no effect. Perhaps you forgot to add a var keyword?
>> > hljs = function() {
>> > 
>> >
>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>> > println
>> > WARNING: externs/hljs.js:19: WARNING - variable hljs is undeclared
>> > hljs = function() {
>> > 
>> >
>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
>> > println
>> > WARNING: externs/hljs.js:27: WARNING - name hljs is not defined in the
>> > externs.
>> > hljs.highlightBlock = function(block) {
>> > 
>> >
>> > Any thoughts on this?
>> >
>> > > On Jul 15, 2019, at 10:32 PM, 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

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

2019-07-16 Thread Josh Tynjala
Thanks. I'm investigating.

I've figured out that the Maven build is still using library-path (or
js-library-path) instead of external-library-path (or
js-external-library-path) when building the framework SWCs.

If I run "mvn clean install" in frameworks/projects/Jewel, I can see that a
target/compile-js-config.xml file is created, and it's using
js-library-path for framework SWCs. I'm still figuring out where this
config file is coming from and how to change it.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 16, 2019 at 9:00 AM Piotr Zarzycki 
wrote:

> Josh,
>
> It looks like something is happened actually. Latest build on server
> failed, but was able to build all examples and TourDeJewel is not running
> [1]
>
> [1]
>
> https://builds.apache.org/job/Royale-asjs/1956/artifact/examples/royale/TourDeJewel/target/javascript/bin/js-debug/index.html
>
> Thanks,
> Piotr
>
> wt., 16 lip 2019 o 17:58 Harbs  napisał(a):
>
> > These warnings look new:
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> > println
> > WARNING: externs/dialogPolyfill.js:15: WARNING - accessing name
> > dialogPolyfill in externs has no effect. Perhaps you forgot to add a var
> > keyword?
> > dialogPolyfill = function() {
> > ^^
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> > println
> > WARNING: externs/dialogPolyfill.js:15: WARNING - variable dialogPolyfill
> > is undeclared
> > dialogPolyfill = function() {
> > ^^
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> > println
> > WARNING: externs/dialogPolyfill.js:23: WARNING - name dialogPolyfill is
> > not defined in the externs.
> > dialogPolyfill.registerDialog = function(dialog) {
> > ^^
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> > println
> > WARNING: externs/hljs.js:19: WARNING - accessing name hljs in externs has
> > no effect. Perhaps you forgot to add a var keyword?
> > hljs = function() {
> > 
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> > println
> > WARNING: externs/hljs.js:19: WARNING - variable hljs is undeclared
> > hljs = function() {
> > 
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> > println
> > WARNING: externs/hljs.js:27: WARNING - name hljs is not defined in the
> > externs.
> > hljs.highlightBlock = function(block) {
> > 
> >
> > Any thoughts on this?
> >
> > > On Jul 15, 2019, at 10:32 PM, 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 d

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

2019-07-16 Thread Josh Tynjala
Oh, yes. Sorry. In this case, it's not externc, but our code in the Royale
compiler is still generating the JS externs.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 16, 2019 at 9:19 AM Harbs  wrote:

> OK.
>
> FWIW, it seems like it’s being generated by an @externs comment in the AS3
> class.
>
> > On Jul 16, 2019, at 7:13 PM, Josh Tynjala 
> wrote:
> >
> > Closure compiler is giving a minor warning about the externs JS files
> that
> > externc is generating. Nothing has changed recently about the way we
> > generate code with externc, as far as I know. I think it has actually
> > always complained about our externs JS. It's just that the build is
> > discovering a couple of new files because I fixed a bug.
> >
> > Since these are just Closure compiler externs, they should not affect the
> > compiled output of your app, even if they're from a library that you
> don't
> > use. It's just a little extra console output that can be ignored.
> However,
> > I can look into ignoring unused JS externs when I have time in the coming
> > months.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Tue, Jul 16, 2019 at 9:06 AM Harbs  wrote:
> >
> >> I quick look seems to indicate that these are coming from Jewel (which
> I'm
> >> not using).
> >>
> >>> On Jul 16, 2019, at 6:58 PM, Harbs  wrote:
> >>>
> >>> These warnings look new:
> >>>
> >>> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> >> println
> >>> WARNING: externs/dialogPolyfill.js:15: WARNING - accessing name
> >> dialogPolyfill in externs has no effect. Perhaps you forgot to add a var
> >> keyword?
> >>> dialogPolyfill = function() {
> >>> ^^
> >>>
> >>> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> >> println
> >>> WARNING: externs/dialogPolyfill.js:15: WARNING - variable
> dialogPolyfill
> >> is undeclared
> >>> dialogPolyfill = function() {
> >>> ^^
> >>>
> >>> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> >> println
> >>> WARNING: externs/dialogPolyfill.js:23: WARNING - name dialogPolyfill is
> >> not defined in the externs.
> >>> dialogPolyfill.registerDialog = function(dialog) {
> >>> ^^
> >>>
> >>> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> >> println
> >>> WARNING: externs/hljs.js:19: WARNING - accessing name hljs in externs
> >> has no effect. Perhaps you forgot to add a var keyword?
> >>> hljs = function() {
> >>> 
> >>>
> >>> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> >> println
> >>> WARNING: externs/hljs.js:19: WARNING - variable hljs is undeclared
> >>> hljs = function() {
> >>> 
> >>>
> >>> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> >> println
> >>> WARNING: externs/hljs.js:27: WARNING - name hljs is not defined in the
> >> externs.
> >>> hljs.highlightBlock = function(block) {
> >>> 
> >>>
> >>> Any thoughts on this?
> >>>
> >>>> On Jul 15, 2019, at 10:32 PM, 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 fro

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

2019-07-16 Thread Josh Tynjala
 Closure compiler is giving a minor warning about the externs JS files that
externc is generating. Nothing has changed recently about the way we
generate code with externc, as far as I know. I think it has actually
always complained about our externs JS. It's just that the build is
discovering a couple of new files because I fixed a bug.

Since these are just Closure compiler externs, they should not affect the
compiled output of your app, even if they're from a library that you don't
use. It's just a little extra console output that can be ignored. However,
I can look into ignoring unused JS externs when I have time in the coming
months.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 16, 2019 at 9:06 AM Harbs  wrote:

> I quick look seems to indicate that these are coming from Jewel (which I'm
> not using).
>
> > On Jul 16, 2019, at 6:58 PM, Harbs  wrote:
> >
> > These warnings look new:
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> > WARNING: externs/dialogPolyfill.js:15: WARNING - accessing name
> dialogPolyfill in externs has no effect. Perhaps you forgot to add a var
> keyword?
> > dialogPolyfill = function() {
> > ^^
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> > WARNING: externs/dialogPolyfill.js:15: WARNING - variable dialogPolyfill
> is undeclared
> > dialogPolyfill = function() {
> > ^^
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> > WARNING: externs/dialogPolyfill.js:23: WARNING - name dialogPolyfill is
> not defined in the externs.
> > dialogPolyfill.registerDialog = function(dialog) {
> > ^^
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> > WARNING: externs/hljs.js:19: WARNING - accessing name hljs in externs
> has no effect. Perhaps you forgot to add a var keyword?
> > hljs = function() {
> > 
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> > WARNING: externs/hljs.js:19: WARNING - variable hljs is undeclared
> > hljs = function() {
> > 
> >
> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> > WARNING: externs/hljs.js:27: WARNING - name hljs is not defined in the
> externs.
> > hljs.highlightBlock = function(block) {
> > 
> >
> > Any thoughts on this?
> >
> >> On Jul 15, 2019, at 10:32 PM, 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 t

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

2019-07-16 Thread Josh Tynjala
I thought that's what you meant when you said that you built the SDK with
Maven. Well, regardless, I still need to update those files.

I'll try to build TourDeJewel entirely with Maven. Maybe there's something
that I need to tweak in the Maven build plugin that wasn't picked up by my
changes. Maybe it's forcing the use of library-path or something like that.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 16, 2019 at 8:21 AM Piotr Zarzycki 
wrote:

> Hi Josh,
>
> Do you refer to my post by mentioning "distribution"? - I don't use
> distribution for Maven. I will rebuild everything once again. Maybe I'm
> missing something.
>
> Thanks,
> Piotr
>
> wt., 16 lip 2019 o 17:04 Josh Tynjala 
> napisał(a):
>
> > Oh yeah, the Maven "distribution" has its own separate versions of files
> > like frameworks/royale-config.xml and frameworks/js-config.xml, doesn't
> it?
> > I guess that those need to be updated to use external-library-path too.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Tue, Jul 16, 2019 at 7:34 AM Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> > wrote:
> >
> > > Hi Carlos,
> > >
> > > Did you check whether you can run TourDeJewel ? I have build SDK using
> > > Maven and than TourDeJewel and I couldn't run application. I'm getting
> > [1].
> > > When I build HelloWorld and run I got the same.
> > >
> > > [1] https://ibb.co/NKjNBMJ
> > >
> > > Thanks,
> > > Piotr
> > >
> > > wt., 16 lip 2019 o 16:10 Carlos Rovira 
> > > napisał(a):
> > >
> > > > Hi,
> > > >
> > > > thanks Josh for the update!
> > > > One question about it: should separate the @extern classes in Jewel
> > > > (dialogPollyfill and hljs classes) or with this change now can live
> in
> > > that
> > > > library?
> > > > Just to know it, although for other organizational purposes I think
> it
> > > > should be probably separated.
> > > >
> > > > @Greg Dove   just merged locally this changes
> and
> > > > rebuild Crux branch and seems some changes are needed there when
> > building
> > > > ANT SDK. I probably can't do changes to try to solve this before you
> > > reach
> > > > the problem since I'm busy with work things. Just copy here my log so
> > it
> > > > could be of help for you
> > > >
> > > > I suppose is the need to change in this branch from library-path to
> > > > external-library-path
> > > >
> > > >
> > > > compile-swf:
> > > >
> > > >  [echo] Compiling libs/Crux.swc
> > > >
> > > >  [echo] ROYALE_HOME:
> > > /Users/carlosrovira/Dev/Royale/Source/royale-asjs
> > > >
> > > >  [echo] ROYALE_SWF_COMPILER_HOME:
> > > > /Users/carlosrovira/Dev/Royale/Source/royale-asjs
> > > >
> > > >  [echo] ROYALE_COMPILER_HOME:
> > > > /Users/carlosrovira/Dev/Royale/Source/royale-asjs/js
> > > >
> > > >  [java] args:
> > > >
> > > >  [java]
> > > >
> +royalelib=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks
> > > >
> > > >  [java] +playerglobal.version=11.1
> > > >
> > > >  [java] +env.AIR_HOME=/Users/carlosrovira/Dev/Air/Sdks/AIR_SDK_25
> > > >
> > > >  [java] -compiler.strict-xml=true
> > > >
> > > >  [java] -compiler.targets=SWF,JSRoyale
> > > >
> > > >  [java] -metadata.date=07/16/19 12:12 +0200
> > > >
> > > >  [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
> > > >
> > > >  [java] -swf-debugfile-alias=/org/apache/royale/0.9.6
> > > >
> > > >  [java]
> > > >
> > > >
> > >
> >
> -output=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/target/Crux.swc
> > > >
> > > >  [java]
> > > >
> > > >
> > >
> >
> -load-config=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/src/main/config/compile-swf-config.xml
> > > >
> > > >  [java]
> > > >
> > > >
> > >
> >
> -js-load-config=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js-config.xml
> > 

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

2019-07-16 Thread Josh Tynjala
Oh yeah, the Maven "distribution" has its own separate versions of files
like frameworks/royale-config.xml and frameworks/js-config.xml, doesn't it?
I guess that those need to be updated to use external-library-path too.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 16, 2019 at 7:34 AM Piotr Zarzycki 
wrote:

> Hi Carlos,
>
> Did you check whether you can run TourDeJewel ? I have build SDK using
> Maven and than TourDeJewel and I couldn't run application. I'm getting [1].
> When I build HelloWorld and run I got the same.
>
> [1] https://ibb.co/NKjNBMJ
>
> Thanks,
> Piotr
>
> wt., 16 lip 2019 o 16:10 Carlos Rovira 
> napisał(a):
>
> > Hi,
> >
> > thanks Josh for the update!
> > One question about it: should separate the @extern classes in Jewel
> > (dialogPollyfill and hljs classes) or with this change now can live in
> that
> > library?
> > Just to know it, although for other organizational purposes I think it
> > should be probably separated.
> >
> > @Greg Dove   just merged locally this changes and
> > rebuild Crux branch and seems some changes are needed there when building
> > ANT SDK. I probably can't do changes to try to solve this before you
> reach
> > the problem since I'm busy with work things. Just copy here my log so it
> > could be of help for you
> >
> > I suppose is the need to change in this branch from library-path to
> > external-library-path
> >
> >
> > compile-swf:
> >
> >  [echo] Compiling libs/Crux.swc
> >
> >  [echo] ROYALE_HOME:
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs
> >
> >  [echo] ROYALE_SWF_COMPILER_HOME:
> > /Users/carlosrovira/Dev/Royale/Source/royale-asjs
> >
> >  [echo] ROYALE_COMPILER_HOME:
> > /Users/carlosrovira/Dev/Royale/Source/royale-asjs/js
> >
> >  [java] args:
> >
> >  [java]
> > +royalelib=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks
> >
> >  [java] +playerglobal.version=11.1
> >
> >  [java] +env.AIR_HOME=/Users/carlosrovira/Dev/Air/Sdks/AIR_SDK_25
> >
> >  [java] -compiler.strict-xml=true
> >
> >  [java] -compiler.targets=SWF,JSRoyale
> >
> >  [java] -metadata.date=07/16/19 12:12 +0200
> >
> >  [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
> >
> >  [java] -swf-debugfile-alias=/org/apache/royale/0.9.6
> >
> >  [java]
> >
> >
> -output=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/target/Crux.swc
> >
> >  [java]
> >
> >
> -load-config=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/src/main/config/compile-swf-config.xml
> >
> >  [java]
> >
> >
> -js-load-config=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js-config.xml
> >
> >  [java]
> >
> >
> -js-load-config+=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/../../js/projects/CruxJS/src/main/config/compile-js-config.xml
> >
> >  [java] target:SWF
> >
> >  [java] target:JSRoyale
> >
> >  [java] COMPC
> >
> >  [java] Loading configuration:
> >
> >
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/src/main/config/compile-swf-config.xml
> >
> >  [java]
> >
> >  [java] 128421 bytes written to
> >
> >
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/target/Crux.swc
> > in 3,234 seconds
> >
> >  [java] COMPCJSCRoyale
> >
> >  [java] 6.474858102 seconds
> >
> >  [java]
> >
> >
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> > The definition XMLList depended on by mx.messaging.config.ServerConfig in
> > the SWC
> >
> >
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> > could not be found
> >
> >  [java]
> >
> >  [java]
> >
> >  [java]
> >
> >
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> > The definition XML depended on by mx.messaging.config.ServerConfig in the
> > SWC
> >
> >
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> > could not be found
> >
> >  [java]
> >
> >  [java]
> >
> >  [java]
> >
> >
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/fr

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

2019-07-16 Thread Josh Tynjala
Before I committed my changes, I confirmed that dialogPolyfill seemed to be
properly working in a release build of TourDeJewel. With that in mind, I
don't think that it will cause any problems to keep dialogPolyfill and hljs
in Jewel. However, I think that the best practice would be to move them
into a separate library. In fact, that library should probably be in
royale-typedefs, since these classes are type definitions for JS libraries.

I'm curious. Is hljs actually used for anything in the Jewel components? If
it's only used in examples, the .as source file with @externs could just be
added to those examples instead of being included in any SWCs.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 16, 2019 at 7:10 AM Carlos Rovira 
wrote:

> Hi,
>
> thanks Josh for the update!
> One question about it: should separate the @extern classes in Jewel
> (dialogPollyfill and hljs classes) or with this change now can live in that
> library?
> Just to know it, although for other organizational purposes I think it
> should be probably separated.
>
> @Greg Dove   just merged locally this changes and
> rebuild Crux branch and seems some changes are needed there when building
> ANT SDK. I probably can't do changes to try to solve this before you reach
> the problem since I'm busy with work things. Just copy here my log so it
> could be of help for you
>
> I suppose is the need to change in this branch from library-path to
> external-library-path
>
>
> compile-swf:
>
>  [echo] Compiling libs/Crux.swc
>
>  [echo] ROYALE_HOME: /Users/carlosrovira/Dev/Royale/Source/royale-asjs
>
>  [echo] ROYALE_SWF_COMPILER_HOME:
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs
>
>  [echo] ROYALE_COMPILER_HOME:
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/js
>
>  [java] args:
>
>  [java]
> +royalelib=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks
>
>  [java] +playerglobal.version=11.1
>
>  [java] +env.AIR_HOME=/Users/carlosrovira/Dev/Air/Sdks/AIR_SDK_25
>
>  [java] -compiler.strict-xml=true
>
>  [java] -compiler.targets=SWF,JSRoyale
>
>  [java] -metadata.date=07/16/19 12:12 +0200
>
>  [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
>
>  [java] -swf-debugfile-alias=/org/apache/royale/0.9.6
>
>  [java]
>
> -output=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/target/Crux.swc
>
>  [java]
>
> -load-config=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/src/main/config/compile-swf-config.xml
>
>  [java]
>
> -js-load-config=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js-config.xml
>
>  [java]
>
> -js-load-config+=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/../../js/projects/CruxJS/src/main/config/compile-js-config.xml
>
>  [java] target:SWF
>
>  [java] target:JSRoyale
>
>  [java] COMPC
>
>  [java] Loading configuration:
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/src/main/config/compile-swf-config.xml
>
>  [java]
>
>  [java] 128421 bytes written to
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Crux/target/Crux.swc
> in 3,234 seconds
>
>  [java] COMPCJSCRoyale
>
>  [java] 6.474858102 seconds
>
>  [java]
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> The definition XMLList depended on by mx.messaging.config.ServerConfig in
> the SWC
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> could not be found
>
>  [java]
>
>  [java]
>
>  [java]
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> The definition XML depended on by mx.messaging.config.ServerConfig in the
> SWC
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> could not be found
>
>  [java]
>
>  [java]
>
>  [java]
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> The definition XML depended on by mx.messaging.channels.PollingChannel in
> the SWC
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> could not be found
>
>  [java]
>
>  [java]
>
>  [java]
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> The definition QName depended on by mx.utils.ObjectUtil in the SWC
>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/js/libs/MXRoyaleJS.swc
> could not be found

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

2019-07-15 Thread Josh Tynjala
The Maven royale-compiler build is fixed now. :)

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Jul 15, 2019 at 1:19 PM Josh Tynjala 
wrote:

> FYI: Found an issue building royale-compiler with Maven. Working on the
> fix.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Mon, Jul 15, 2019 at 12:32 PM 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,

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

2019-07-15 Thread Josh Tynjala
FYI: Found an issue building royale-compiler with Maven. Working on the fix.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Jul 15, 2019 at 12:32 PM 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 should not cause any problems.
> You're probably using library-path and external-library-path correctly.
>
> If you have a project that is a library, you should check your compiler
> options to see if you are using library-path and external-library-path
> correctly. If your library depends on another library, you prob

library-path and external-library-path fixes

2019-07-15 Thread Josh Tynjala
old typedef SWCs may look like
goog.require() SWCs instead. To be sure, you can open a SWC file in any
program that can read ZIP files, and you'll see the internal folder
structure. If a typedef SWC has a "js/out" folder, it's not going to work
properly.

If you're working directly out of the royale-compiler and royale-asjs Git
repos, be sure to update and rebuild them both. The nightly builds should
be updated shortly.

When you build any apps, be sure to clean first, just to be sure that you
have the latest JS files from the SWCs.

If you run into any other problems with these changes, please let me know.
I'll get them fixed right away!

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


Re: Crux Branch

2019-07-12 Thread Josh Tynjala
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:
> > > >
> > > > 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)
&g

Re: Jewel CSS winding up in non-Jewel apps

2019-07-11 Thread Josh Tynjala
I like the idea of checking the layout of the SWC. I'll give that a try.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Jul 10, 2019 at 11:20 PM Alex Harui 
wrote:

> Is the "isNative()" function hooked up to the native keyword or the
> [native] metadata?
>
> This is not the gotcha I was trying to remember in my last post, but one
> concern that came to mind was that some API that we consider "native" or a
> "typedef" for JS in the browser because it is supplied by the browser or a
> third-party library may not be provided the same way on other
> platforms/runtimes, so there is a danger that if you declare some class or
> function as native that someone trying to create an
> implementation/emulation of that API on some other platform/runtime will
> run into trouble.
>
> So maybe we should flip the problem on its head and consider how to
> identify classes whose JS output includes goog.provides().  That feels a
> bit better because it is specific to JS output.  A possible first
> approximation would simply be to see if the SWC has a js/out folder and if
> it does, assume that all classes from that SWC support goog.provides.
> Typedef SWCs should not have a js/out folder and only an externs folder.
>
> HTH,
> -Alex
>
> On 7/10/19, 8:54 AM, "Josh Tynjala"  wrote:
>
> It looks like the native keyword is allowed on functions only. You'll
> get a
> compiler error if you try to add the native keyword onto a class. After
> discovering this, I looked at how classes are compiled into
> playerglobal.swc, and it looks like they have [native] metadata. That
> could
> possibly serve the same purpose.
>
> Here are a few options that might work:
>
> 1) Modify the compiler to allow the native keyword to be used on
> classes.
>
> 2) Use [native] metadata to detect typedef classes.
>
>     3) Check the class for a constructor that has the native keyword
> (since a
> constructor is a function, native is allowed there).
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764667456sdata=DEinUrLNfiRQmsk9kPo9bMXAik2hH2R1h6%2FuhvB2fq4%3Dreserved=0
> >
>
>
> On Tue, Jul 9, 2019 at 8:08 PM Alex Harui 
> wrote:
>
> > Good idea.  I have this vague memory that there are some other
> gotchas
> > around using "native", but give it a try and see what happens.
> >
> > -Alex
> >
> > On 7/9/19, 4:21 PM, "Josh Tynjala" 
> wrote:
> >
> > You know, I just realized... we should start adding the "native"
> > modifier
> > to ActionScript classes in typedef SWCs. Typedef SWCs serve the
> same
> > purpose as playerglobal/airglobal SWCs, which are also compiled
> as
> > "native". They all define APIs that will be available at
> run-time and
> > the
> > SWC should only be used for checking types and things at
> compile-time.
> >
> > IDefinition has an isNative() method that tells you if a class
> was
> > marked
> > with the "native" keyword. We would use that instead of
> > library-path/external-library-path to determine whether
> goog.require()
> > is
> > needed for a particular class. This would keep
> > library-path/external-library-path working as they always have,
> without
> > affecting goog.require().
> >
> > I think I actually suggested using the "native" keyword for
> typedefs a
> > very
> > long time ago. I think you said that externc or the JS emitter
> didn't
> > handle it properly. Since I wasn't very familiar with the
> compiler
> > code at
> > the time, I didn't think I could fix it, so I dropped the idea.
> >
> > This is what was missing. We were ignoring a feature of the
> language
> > that
> > was meant for exactly this situation.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3Dreserved=0
> > >
>

Re: Jewel CSS winding up in non-Jewel apps

2019-07-10 Thread Josh Tynjala
It looks like the native keyword is allowed on functions only. You'll get a
compiler error if you try to add the native keyword onto a class. After
discovering this, I looked at how classes are compiled into
playerglobal.swc, and it looks like they have [native] metadata. That could
possibly serve the same purpose.

Here are a few options that might work:

1) Modify the compiler to allow the native keyword to be used on classes.

2) Use [native] metadata to detect typedef classes.

3) Check the class for a constructor that has the native keyword (since a
constructor is a function, native is allowed there).

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 9, 2019 at 8:08 PM Alex Harui  wrote:

> Good idea.  I have this vague memory that there are some other gotchas
> around using "native", but give it a try and see what happens.
>
> -Alex
>
> On 7/9/19, 4:21 PM, "Josh Tynjala"  wrote:
>
> You know, I just realized... we should start adding the "native"
> modifier
> to ActionScript classes in typedef SWCs. Typedef SWCs serve the same
> purpose as playerglobal/airglobal SWCs, which are also compiled as
> "native". They all define APIs that will be available at run-time and
> the
> SWC should only be used for checking types and things at compile-time.
>
> IDefinition has an isNative() method that tells you if a class was
> marked
> with the "native" keyword. We would use that instead of
> library-path/external-library-path to determine whether goog.require()
> is
> needed for a particular class. This would keep
> library-path/external-library-path working as they always have, without
> affecting goog.require().
>
> I think I actually suggested using the "native" keyword for typedefs a
> very
> long time ago. I think you said that externc or the JS emitter didn't
> handle it properly. Since I wasn't very familiar with the compiler
> code at
> the time, I didn't think I could fix it, so I dropped the idea.
>
> This is what was missing. We were ignoring a feature of the language
> that
> was meant for exactly this situation.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cbdb3db4ff29e40f289e908d704c425d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983112848931274sdata=OejBnXkhiEnesxpytUFjtQZ6NOCrMR1%2FWK9zhiVqvuw%3Dreserved=0
> >
>
>
> On Tue, Jul 9, 2019 at 4:00 PM Alex Harui 
> wrote:
>
> > Category #1 is when someone intends to combine code from a SWC into
> > another SWC to create one mega-swc, maybe to reduce the number of
> SWCs or,
> > back in the day, to create one RSL instead of two.  I don't think
> Royale
> > should ever need to do this.
> >
> > Category #2 is the other AS classes from other SWCs you need.  As you
> > mentioned Jewel.SWC uses Basic org.apache.royale.states.States (from
> > Core.swc or Basic.swc).
> >
> > Category #3 is definitions that are not in Royale code.  For SWF
> versions
> > of SWCs, it is everything in playerglobal/airglobal.  So Sprite,
> > DisplayObject, other flash.*.* packages.  For JS versions of SWCs it
> is
> > HTMLElement and other stuff in js.swc or other typedefs.
> >
> > If you are suggesting that somehow the compiler will know that some
> SWCs
> > on the external-library-path are typedefs vs a framework class from
> > Core.swc or Basic.swc, that might be possible, but I don't know how
> > efficient that will be (or accurate) to determine that, plus
> portions of
> > the compiler have a test for "isExternal()" that we'd have to make
> sure we
> > get right.
> >
> > That's why I suggest that we add some new option that lists classes
> that
> > shouldn't be linked into library.swf without marking them
> "isExternal()".
> > There is already a similar option that does mark classes as
> "isExternal()"
> > that we might be able to leverage.
> >
> > HTH,
> > -Alex
> >
> >
> > On 7/9/19, 3:43 PM, "Josh Tynjala" 
> wrote:
> >
> > > 3) code that should not be in the output SWC that doesn't
> support
> > goog.require/goog.provide
> >
> >     Is there anything other than a typedef SWC that could be
> classified as
> > #3?
> > It seems like we have an extra category that doesn

Re: Jewel CSS winding up in non-Jewel apps

2019-07-09 Thread Josh Tynjala
You know, I just realized... we should start adding the "native" modifier
to ActionScript classes in typedef SWCs. Typedef SWCs serve the same
purpose as playerglobal/airglobal SWCs, which are also compiled as
"native". They all define APIs that will be available at run-time and the
SWC should only be used for checking types and things at compile-time.

IDefinition has an isNative() method that tells you if a class was marked
with the "native" keyword. We would use that instead of
library-path/external-library-path to determine whether goog.require() is
needed for a particular class. This would keep
library-path/external-library-path working as they always have, without
affecting goog.require().

I think I actually suggested using the "native" keyword for typedefs a very
long time ago. I think you said that externc or the JS emitter didn't
handle it properly. Since I wasn't very familiar with the compiler code at
the time, I didn't think I could fix it, so I dropped the idea.

This is what was missing. We were ignoring a feature of the language that
was meant for exactly this situation.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 9, 2019 at 4:00 PM Alex Harui  wrote:

> Category #1 is when someone intends to combine code from a SWC into
> another SWC to create one mega-swc, maybe to reduce the number of SWCs or,
> back in the day, to create one RSL instead of two.  I don't think Royale
> should ever need to do this.
>
> Category #2 is the other AS classes from other SWCs you need.  As you
> mentioned Jewel.SWC uses Basic org.apache.royale.states.States (from
> Core.swc or Basic.swc).
>
> Category #3 is definitions that are not in Royale code.  For SWF versions
> of SWCs, it is everything in playerglobal/airglobal.  So Sprite,
> DisplayObject, other flash.*.* packages.  For JS versions of SWCs it is
> HTMLElement and other stuff in js.swc or other typedefs.
>
> If you are suggesting that somehow the compiler will know that some SWCs
> on the external-library-path are typedefs vs a framework class from
> Core.swc or Basic.swc, that might be possible, but I don't know how
> efficient that will be (or accurate) to determine that, plus portions of
> the compiler have a test for "isExternal()" that we'd have to make sure we
> get right.
>
> That's why I suggest that we add some new option that lists classes that
> shouldn't be linked into library.swf without marking them "isExternal()".
> There is already a similar option that does mark classes as "isExternal()"
> that we might be able to leverage.
>
> HTH,
> -Alex
>
>
> On 7/9/19, 3:43 PM, "Josh Tynjala"  wrote:
>
> > 3) code that should not be in the output SWC that doesn't support
> goog.require/goog.provide
>
> Is there anything other than a typedef SWC that could be classified as
> #3?
> It seems like we have an extra category that doesn't exist in
> practice, but
> we're giving it priority over a category that is more common.
>
> Not just with framework SWCs either. Third-party SWCs that include
> custom
> components would need to set the framework SWCs on the
> external-library-path too.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Ce8d3fd5407a241169b3708d704bed6ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983090037408433sdata=ZLh%2BhjW0JHwUJiGJC3%2B5imtgGoFDWFxI1rNvFnZoYGY%3Dreserved=0
> >
>
>
> On Tue, Jul 9, 2019 at 3:33 PM Alex Harui 
> wrote:
>
> > I'm not sure why Jewel CSS is winding up in non-Jewel apps, but the
> issue
> > of whether SWC dependencies should be on the library-path or
> > external-library-path isn't so much as a bug (functionality that
> isn't
> > working as expected) but rather, a problem we've had "forever".
> >
> > With only -library-path and -external-library-path options, that is
> only
> > two categories to categorize:
> >
> > 1) code from another library you want included in the output SWC
> > 2) code that should not be in the output SWC but supports
> > goog.require/goog.provide
> > 3) code that should not be in the output SWC that doesn't support
> > goog.require/goog.provide
> >
> > When we build the framework, we rarely ever want #1.  So we've been
> using
> > -library-path for #2 and -external-library-path to be #3 and somehow
> got
> > this far by ignoring the fact that code that shouldn't be duplicated
> in the
> > SWCs are.  I think it has been like t

Re: Jewel CSS winding up in non-Jewel apps

2019-07-09 Thread Josh Tynjala
> 3) code that should not be in the output SWC that doesn't support
goog.require/goog.provide

Is there anything other than a typedef SWC that could be classified as #3?
It seems like we have an extra category that doesn't exist in practice, but
we're giving it priority over a category that is more common.

Not just with framework SWCs either. Third-party SWCs that include custom
components would need to set the framework SWCs on the
external-library-path too.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 9, 2019 at 3:33 PM Alex Harui  wrote:

> I'm not sure why Jewel CSS is winding up in non-Jewel apps, but the issue
> of whether SWC dependencies should be on the library-path or
> external-library-path isn't so much as a bug (functionality that isn't
> working as expected) but rather, a problem we've had "forever".
>
> With only -library-path and -external-library-path options, that is only
> two categories to categorize:
>
> 1) code from another library you want included in the output SWC
> 2) code that should not be in the output SWC but supports
> goog.require/goog.provide
> 3) code that should not be in the output SWC that doesn't support
> goog.require/goog.provide
>
> When we build the framework, we rarely ever want #1.  So we've been using
> -library-path for #2 and -external-library-path to be #3 and somehow got
> this far by ignoring the fact that code that shouldn't be duplicated in the
> SWCs are.  I think it has been like that "forever", so no idea why it is
> breaking now unless folks are using the JS versions of the SWCs more these
> days.
>
> I didn't think the duplication was causing problems but since it
> apparently is, I think the compiler would need a way to know to exclude
> certain classes from the output SWF.  I think there is already an -externs
> option but that requires listing every class which would be painful to
> administrate.  And I think that might re-categorize the class as being on
> the -external-library-path which we don't want either.  So maybe a new
> compiler option to exclude all classes from a SWC in the output library.swf
> is best.
>
> HTH,
> -Alex
>
> On 7/9/19, 3:06 PM, "Josh Tynjala"  wrote:
>
> I have confirmed that these SWCs are defined on the library-path in the
> compile-js-config.xml used to build JewelJS.swc. Instead, it should be
> using the external-library-path or js-external-library-path.
>
> In compile-swf-config.xml for Jewel.swc, the dependencies are correctly
> defined on external-library-path so that they aren't included in
> Jewel.swc.
>
> Unfortunately, my initial attempts to use external-library-path or
> js-external-library-path are running into issues. I worry that it may
> be
> related to this comment in compile-js-config.xml where the SWCs were
> added
> to the library-path:
>
> 
>
> I could be wrong, but I interpret this comment to mean that
> goog.require()
>     is not added if something is on the external-library-path. That sounds
> like
> a bug in the compiler, and this was more of a workaround than the
> correct
> way to fix things.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cc10e9c73a5954c16e96a08d704b9abf6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983067811352669sdata=ZE1Kb6B418%2FEw7MuGPdmCjKsHKE5wMspjavvDVqRjyw%3Dreserved=0
> >
>
>
> On Tue, Jul 9, 2019 at 2:35 PM Josh Tynjala  >
> wrote:
>
> > It looks like JewelJS.swc includes some classes in the SWC that
> probably
> > shouldn't be there. One example (but there are many more):
> > org.apache.royale.states.State.
> >
> > These are core classes that should be from dependencies, and I
> suspect
> > that something might be on the library-path instead of the
> > external-library-path. Because the compiler found the class in
> JewelJS.swc,
> > it assumes that it needs defaults.css from JewelJS.swc too.
> >
> > To try to reproduce this issue, I created a sample app that uses only
> > Basic components. I'm seeing that the compiler is trying to use
> > defaults.css from Basic, Express, Jewel, and MaterialDesignLite.
> >
> > I'll take a look at the compiler options for some of the other SWCs
> to see
> > if anything catches my eye.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cc10e9c73a595

Re: Jewel CSS winding up in non-Jewel apps

2019-07-09 Thread Josh Tynjala
I have confirmed that these SWCs are defined on the library-path in the
compile-js-config.xml used to build JewelJS.swc. Instead, it should be
using the external-library-path or js-external-library-path.

In compile-swf-config.xml for Jewel.swc, the dependencies are correctly
defined on external-library-path so that they aren't included in Jewel.swc.

Unfortunately, my initial attempts to use external-library-path or
js-external-library-path are running into issues. I worry that it may be
related to this comment in compile-js-config.xml where the SWCs were added
to the library-path:



I could be wrong, but I interpret this comment to mean that goog.require()
is not added if something is on the external-library-path. That sounds like
a bug in the compiler, and this was more of a workaround than the correct
way to fix things.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 9, 2019 at 2:35 PM Josh Tynjala 
wrote:

> It looks like JewelJS.swc includes some classes in the SWC that probably
> shouldn't be there. One example (but there are many more):
> org.apache.royale.states.State.
>
> These are core classes that should be from dependencies, and I suspect
> that something might be on the library-path instead of the
> external-library-path. Because the compiler found the class in JewelJS.swc,
> it assumes that it needs defaults.css from JewelJS.swc too.
>
> To try to reproduce this issue, I created a sample app that uses only
> Basic components. I'm seeing that the compiler is trying to use
> defaults.css from Basic, Express, Jewel, and MaterialDesignLite.
>
> I'll take a look at the compiler options for some of the other SWCs to see
> if anything catches my eye.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Tue, Jul 9, 2019 at 3:21 AM Harbs  wrote:
>
>> I have no jewel components in my app, but I’m suddenly seeing TONS of
>> jewel css in my app.
>>
>> Similarly, I’m seeing Basic CSS (such as Button) which did not used to be
>> included (and is messing up the visuals in my app).
>>
>> Has something changed with the logic which includes CSS?
>>
>> Harbs
>
>


Re: Jewel CSS winding up in non-Jewel apps

2019-07-09 Thread Josh Tynjala
It looks like JewelJS.swc includes some classes in the SWC that probably
shouldn't be there. One example (but there are many more):
org.apache.royale.states.State.

These are core classes that should be from dependencies, and I suspect that
something might be on the library-path instead of the
external-library-path. Because the compiler found the class in JewelJS.swc,
it assumes that it needs defaults.css from JewelJS.swc too.

To try to reproduce this issue, I created a sample app that uses only Basic
components. I'm seeing that the compiler is trying to use defaults.css from
Basic, Express, Jewel, and MaterialDesignLite.

I'll take a look at the compiler options for some of the other SWCs to see
if anything catches my eye.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 9, 2019 at 3:21 AM Harbs  wrote:

> I have no jewel components in my app, but I’m suddenly seeing TONS of
> jewel css in my app.
>
> Similarly, I’m seeing Basic CSS (such as Button) which did not used to be
> included (and is messing up the visuals in my app).
>
> Has something changed with the logic which includes CSS?
>
> Harbs


Re: [royale-compiler] branch develop updated: PackageHeaderEmitter: output goog.require() for externs because release builds fail without it

2019-07-09 Thread Josh Tynjala
It seems that Jewel is being compiled with a couple of ActionScript classes
marked with @externs. Perhaps that's the problem. Maybe those classes
should be compiled into a separate SWC. Maybe the compiler should not allow
classes with @externs and classes without it in the same SWC.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 9, 2019 at 9:35 AM Alex Harui  wrote:

> I can't tell from this thread what an "extern" is, but I believe at least
> in js-debug, if you goog.require something that doesn't have a goog.provide
> in it, there can be other problems.  So maybe it was already broken, but
> this does not seem like a positive change.  I expect other things to
> break.  I'm surprised the GoogDepsWriter didn't output warnings or errors.
>
> Most Externs are in royale-typedefs and their SWCs should be on the
> -external-library-path.  In theory, their .js files get handed to Google
> Closure Compiler as externs not as regular js files.
>
> Source externs are supposed to do the same thing.
>
> IIRC, if you use a typedefs SWC to compile a framework SWC, then the
> typedefs SWC must be in the external-library-path for the application that
> uses the framework SWC.
>
> Thanks,
> -Alex
>
> On 7/9/19, 9:11 AM, "Josh Tynjala"  wrote:
>
> Without a goog.require(), the .js file for the extern does not seem to
> be
> copied to the output folder, and Closure renames its APIs.
>
> How the compiler behaved *before* my change:
>
> * If I reference the extern in a library, the compiler did not add a
> goog.require() for it.
> * If I reference the extern in an application, *the compiler added a
> goog.require() for it.*
>
> How it works after my change:
>
> * If I reference the extern in a library, the compiler adds a
> goog.require() for it.
> * If I reference the extern in an application, the compiler adds a
> goog.require() for it.
>
> I made the compiler's behavior more consistent because the it was
> already
> adding goog.require() for externs in applications. If that's wrong, it
> was
> already wrong before I made any changes.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.devdata=02%7C01%7Caharui%40adobe.com%7Cc589f5d7d32c425579c208d70488262a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636982855118961103sdata=B4z9PGs%2FVKFu7ZOPupm1UTRVxdw38MEx2yehIFPNKmc%3Dreserved=0
> >
>
>
> On Mon, Jul 8, 2019 at 11:26 PM Alex Harui 
> wrote:
>
> > This doesn't seem right to me.  Externs should be representing JS
> files
> > that don't have goog.provide in them.
> >
> > -Alex
> >
> > On 7/8/19, 1:40 PM, "joshtynj...@apache.org"  >
> > wrote:
> >
> > This is an automated email from the ASF dual-hosted git
> repository.
> >
> > joshtynjala pushed a commit to branch develop
> > in repository
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-compiler.gitdata=02%7C01%7Caharui%40adobe.com%7Cc589f5d7d32c425579c208d70488262a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636982855118961103sdata=C4JjqtBaAcFyhUCORG7jgDP3X0bthRGexYZVS%2B1A29Q%3Dreserved=0
> >
> >
> > The following commit(s) were added to refs/heads/develop by this
> push:
> >  new 942a423  PackageHeaderEmitter: output goog.require() for
> > externs because release builds fail without it
> > 942a423 is described below
> >
> > commit 942a4235758020239eca707a5e5c73e94a63df8c
> > Author: Josh Tynjala 
> > AuthorDate: Mon Jul 8 13:40:05 2019 -0700
> >
> > PackageHeaderEmitter: output goog.require() for externs
> because
> > release builds fail without it
> > ---
> >
> .../royale/compiler/internal/codegen/js/jx/PackageHeaderEmitter.java
> >  | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git
> >
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/PackageHeaderEmitter.java
> >
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/PackageHeaderEmitter.java
> > index 7c8b9ac..57cfc76 100644
> > ---
> >
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/PackageHeaderEmitter.java
> > +++
> >
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/PackageHeaderEmitter.java
> > @@ -380,9 +380,6 @@ public class PackageHeaderEmitter extends
> > JSSubEmitter implements
> >
> >  if (imp.equals(cname))
> >  continue;
> > -
> > -if (project.sourceExterns.contains(imp))
> > -   continue;
> >
> >  if (NativeUtils.isNative(imp))
> >  {
> >
> >
> >
> >
>
>
>


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

2019-07-09 Thread Josh Tynjala
Especially if the purpose of inject_html is to load JS from a CDN. There
will definitely be users of Royale who cannot have external dependencies
like that, and they'll need a way to override the behavior to load a JS
file from their own server instead.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 9, 2019 at 9:23 AM Harbs  wrote:

> I’m really not excited about the use of inject_html in Framework code.
>
> > On Jul 9, 2019, at 7:13 PM, Carlos Rovira 
> wrote:
> >
> > Hi Alex,
> >
> > El mar., 9 jul. 2019 a las 17:43, Alex Harui ( <mailto:aha...@adobe.com.invalid>>)
> > escribió:
> >
> >> IMO, adding an API for missing.js should only be done for APIs that are
> >> truly cross-browser.  If an API requires a polyfill, then if we add it
> to
> >> missing.js and someone tries to use it on the browser that doesn't
> support
> >> it, it won't work for them without the polyfill.
> >>
> >
> > ok. another option could be to provide the inject_html for the polyfill
> if
> > the user uses "animate" method, since the polyfill makes that
> > cross-browser. This is other abstraction or ease of development for Royal
> > users.
> >
> >
> >>
> >> Either there should be a separate typedefs SWC for it, or we should see
> >> what changes to the toolchain are needed to allow the missing API to be
> >> supplied by a source extern in the SWC that uses it.
> >>
> >
> > I don't understand exactly what you propose here. I think I miss some
> > knowledge here.
> >
> > thanks
> >
> >
> >
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 7/9/19, 7:57 AM, "Josh Tynjala"  wrote:
> >>
> >>Generally, if we need a browser API that Closure doesn't include in
> >> it's
> >>official externs, we add it to missing.js in the appropriate library
> in
> >>royale-typedefs.
> >>
> >>- Josh
> >>
> >>On Tue, Jul 9, 2019, 4:39 AM Piotr Zarzycki <
> piotrzarzyck...@gmail.com
> >>>
> >>wrote:
> >>
> >>> I thought this is the right place, from where I should download it
> >> to have
> >>> URLSearchParams available ?
> >>>
> >>> wt., 9 lip 2019 o 13:33 Harbs  napisał(a):
> >>>
> >>>> I see you added that line. It does not look like url.js was
> >> modified in
> >>>> royale-extras. Why are you downloading it from there?
> >>>>
> >>>>> On Jul 9, 2019, at 2:26 PM, Piotr Zarzycki <
> >> piotrzarzyck...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Hi Harbs,
> >>>>>
> >>>>> Unfortunately I don't see different. externc-config.xml has
> >> url.js in
> >>>>> target/downloads/browser/url.js.
> >>>>> Ant build is downloading url.js to that folder [2]. Maven build
> >> is
> >>> doing
> >>>>> exactly the same [3].
> >>>>>
> >>>>> What am I missing ?
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-typedefs%2Fblob%2F952664e244c75f9700e7d9c14bd74283c5a75070%2Fjs%2Fsrc%2Fmain%2Fconfig%2Fexternc-config.xml%23L89data=02%7C01%7Caharui%40adobe.com%7Cc47e32b453da4ca1ea1f08d7047dc0d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636982810484735244sdata=10jV0FoSeRbDPa2Ex7Vj6ivI%2BR6hw5w47QPtbbNtPQI%3Dreserved=0
> >>>>> [2]
> >>>>>
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-typedefs%2Fblob%2F952664e244c75f9700e7d9c14bd74283c5a75070%2Fjs%2Fbuild.xml%23L116data=02%7C01%7Caharui%40adobe.com%7Cc47e32b453da4ca1ea1f08d7047dc0d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636982810484735244sdata=5yby%2B%2BSp4SM96q4BD5kzT8o7pIHyb%2Fo0nRP0HrVP1zs%3Dreserved=0
> >>>>> [3]
> >>>>>
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-typedefs%2Fblob%2F952664e244c75f9700e7d9c14bd74283c5a75070%2Fjs%2Fpom.xml%23L192data=02%7C01%7Caharui%40adobe.com%7Cc47e32b453da4ca1ea1f08d7047dc0d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636982810484735244sdata=lzI4EiTN90jLN5xZtM2TrO7

Re: [royale-compiler] branch develop updated: PackageHeaderEmitter: output goog.require() for externs because release builds fail without it

2019-07-09 Thread Josh Tynjala
Without a goog.require(), the .js file for the extern does not seem to be
copied to the output folder, and Closure renames its APIs.

How the compiler behaved *before* my change:

* If I reference the extern in a library, the compiler did not add a
goog.require() for it.
* If I reference the extern in an application, *the compiler added a
goog.require() for it.*

How it works after my change:

* If I reference the extern in a library, the compiler adds a
goog.require() for it.
* If I reference the extern in an application, the compiler adds a
goog.require() for it.

I made the compiler's behavior more consistent because the it was already
adding goog.require() for externs in applications. If that's wrong, it was
already wrong before I made any changes.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Jul 8, 2019 at 11:26 PM Alex Harui  wrote:

> This doesn't seem right to me.  Externs should be representing JS files
> that don't have goog.provide in them.
>
> -Alex
>
> On 7/8/19, 1:40 PM, "joshtynj...@apache.org" 
> wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> joshtynjala pushed a commit to branch develop
> in repository
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-compiler.gitdata=02%7C01%7Caharui%40adobe.com%7C98ea3f4308e6419aa4c908d703e48029%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636982152277066484sdata=K7kYU5xaJKz%2BXluJl0gpl0N21%2FlV%2FS6Z%2BfPEqaVWipg%3Dreserved=0
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new 942a423  PackageHeaderEmitter: output goog.require() for
> externs because release builds fail without it
> 942a423 is described below
>
> commit 942a4235758020239eca707a5e5c73e94a63df8c
> Author: Josh Tynjala 
> AuthorDate: Mon Jul 8 13:40:05 2019 -0700
>
> PackageHeaderEmitter: output goog.require() for externs because
> release builds fail without it
> ---
>  .../royale/compiler/internal/codegen/js/jx/PackageHeaderEmitter.java
>  | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/PackageHeaderEmitter.java
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/PackageHeaderEmitter.java
> index 7c8b9ac..57cfc76 100644
> ---
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/PackageHeaderEmitter.java
> +++
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/PackageHeaderEmitter.java
> @@ -380,9 +380,6 @@ public class PackageHeaderEmitter extends
> JSSubEmitter implements
>
>  if (imp.equals(cname))
>  continue;
> -
> -if (project.sourceExterns.contains(imp))
> -   continue;
>
>  if (NativeUtils.isNative(imp))
>  {
>
>
>
>


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

2019-07-09 Thread Josh Tynjala
Generally, if we need a browser API that Closure doesn't include in it's
official externs, we add it to missing.js in the appropriate library in
royale-typedefs.

- Josh

On Tue, Jul 9, 2019, 4:39 AM Piotr Zarzycki 
wrote:

> I thought this is the right place, from where I should download it to have
> URLSearchParams available ?
>
> wt., 9 lip 2019 o 13:33 Harbs  napisał(a):
>
> > I see you added that line. It does not look like url.js was modified in
> > royale-extras. Why are you downloading it from there?
> >
> > > On Jul 9, 2019, at 2:26 PM, Piotr Zarzycki 
> > wrote:
> > >
> > > Hi Harbs,
> > >
> > > Unfortunately I don't see different. externc-config.xml has url.js in
> > > target/downloads/browser/url.js.
> > > Ant build is downloading url.js to that folder [2]. Maven build is
> doing
> > > exactly the same [3].
> > >
> > > What am I missing ?
> > >
> > > [1]
> > >
> >
> https://github.com/apache/royale-typedefs/blob/952664e244c75f9700e7d9c14bd74283c5a75070/js/src/main/config/externc-config.xml#L89
> > > [2]
> > >
> >
> https://github.com/apache/royale-typedefs/blob/952664e244c75f9700e7d9c14bd74283c5a75070/js/build.xml#L116
> > > [3]
> > >
> >
> https://github.com/apache/royale-typedefs/blob/952664e244c75f9700e7d9c14bd74283c5a75070/js/pom.xml#L192
> > >
> > > Thanks,
> > > Piotr
> > >
> > > wt., 9 lip 2019 o 11:06 Harbs  napisał(a):
> > >
> > >> Take a look at the following files in the typedef repo:
> > >> Lines 108-166 in build.xml
> > >> Line 67 and later in pom.xml
> > >> Notice the different paths in externc-config.xml
> > >>
> > >>> On Jul 9, 2019, at 11:57 AM, Carlos Rovira 
> > >> wrote:
> > >>>
> > >>> So I can add Web Animations API externs there, but this will trigger
> > some
> > >>> build in extras and royale will pick that in the next build? I'm
> > figuring
> > >>> if something must be done I extras or just committing there is all
> that
> > >> is
> > >>> needed
> > >>
> > >>
> > >
> > > --
> > >
> > > Piotr Zarzycki
> > >
> > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > *
> >
> >
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>


Re: Tour de Jewel regression in Jewel Alert (release version)

2019-07-08 Thread Josh Tynjala
This doesn't seem to be related to any recent changes in the compiler. It
may be one of those cases where Closure decided to start renaming something
that it didn't rename previously due to some file size heuristic being
triggered, or something like that.

I've found that the generation of the "Royale Dependency List" did not seem
account for externs that were not referenced directly by the application.
If the extern was compiled into a SWC and was only referenced by classes in
the same SWC, the extern would be ignored when compiling the application.
In this case, the Alert class in JewelJS.swc is referencing dialogPolyfill,
but the application doesn't use dialogPolyfill directly. As soon as I add a
reference to dialogPolyfill somewhere in the application, it starts working
correctly.

I changed to compiler to always output goog.require() calls for externs.
Previously, it was skipping externs completely when adding goog.require()
calls. I guess that this edge case must have been missed when testing that.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Mon, Jul 8, 2019 at 11:09 AM Carlos Rovira 
wrote:

> Hi,
>
> when I compile TDJ I can see not a problem in release (but not I debug) for
> jewel alert component.
>
> I think is a magnification problem for dialogPolyfill. I think Royale is
> changing method name in release mode for method "registerDialog"
> This was not happening before
>
> [Error] TypeError: dialogPolyfill.DH is not a function. (In
> 'dialogPolyfill.DH(a.Vi)', 'dialogPolyfill.DH' is undefined)
> IJ (App.js:1506:197)
> showModal (App.js:1507)
> cG (App.js:1506:439)
> L (App.js:1262)
> (función anónima)
> nx (App.js:91:245)
> Jx (App.js:110:262)
> fH (App.js:965:906)
> ix (App.js:93)
> (función anónima) (App.js:89)
>
> the class is this:
>
> package
> {
> /**
>  * @externs
>  */
> public class dialogPolyfill
> {
> COMPILE::JS
> public static function registerDialog(dialog:Element):void {}
> }
> }
>
> Someone knows what of the latest changes in compiler could be causing this
> problem?
>
> thanks
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


Re: Apache Royale Animations framework

2019-07-08 Thread Josh Tynjala
Greensock's source code is available, but it is not a standard open source
license. They require a commercial license if your project meets certain
conditions.

https://greensock.com/standard-license

- Josh

On Mon, Jul 8, 2019, 4:36 AM Carlos Rovira  wrote:

> Hi,
>
> one thing I'm investigating in parallel among other things is about how to
> make animations easy in Royale.
> We have already some infrastructure in the Effects.swc, but this library
> has the great point to be very oriented
> to Royale with beads and although I didn't tried in SWF, I suppose is
> working for Royale JS and SWF.
>
> In the other hand there's other great JS frameworks out there that brings
> many options to this field, but the problem will be
> just that: only JS.
>
> For me the better option would be to create a new library to be used with
> UI sets, that brings the power of some programatic JS
> lib out there, and concentrate in the JS part in the short term but left
> open to SWF for others that want to bring that part to it.
>
> I think many things nowadays can be done in CSS, or JS or combination of
> both. And I like the idea of having most of this in CSS
> if possible. I think Web Animations API has both options animations via JS
> API and via CSS
>
> I was interested in Framer [1]. I always liked it. But seems Framer has
> turn towards React. Today I could have a call with Framer people
> to ask for possibilities to make some Royale lib (as we did for MDL) for
> Framer , since although the older version is OS, the newer is still
> not, although they want to make it OS. The problems is Framer is very React
> oriented, so I think is not a real option.
>
> Then Framer people kindly point me to Popmotion Pure [2], that seems the
> point from where Framer was created.
>
> I still need to dig a bit into this, but seems a good option (for what I
> see).
> So, one option could be:
>
> a) Use Web Animations API: I used this already in Jewel Wizard, and maybe
> this is the real option of future
> b) Use Popmotion
> c) Use GreenShock [3] (I think others here like Harbs pointed to this. I
> still didn't look at it, but I think is a payed lib, so maybe not the
> better to use)
>
> What do you think about it? I'd like what others think about all of this
>
>
>
> [1] http://framer.com
> [2] https://popmotion.io/pure/
> [3] https://greensock.com
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


  1   2   >