Re: [VOTE] Release Apache Flex BlazeDS 4.8.0 RC1

[Greg Dove]

+1


Checked on Windows 10
with:
Apache Maven 3.5.4
Java version: 1.8.0_181

Source package built and installed without issue via maven.
(I did not attempt to test the usage of the build.)


Source release check:
(zip files were checked)

SHA512 matches.
zip file was signed by joshtynj...@apache.org

Binary release check
(zip files were checked)

SHA512 matches.
zip file was signed by joshtynj...@apache.org

The following files:
README
RELEASE NOTES
LICENSE
NOTICE

all seem fine to me.





On Thu, Mar 9, 2023 at 12:07 PM Josh Tynjala 
wrote:

> Hi,
>
> This is the vote for the 4.8.0 release of Apache Flex BlazeDS.
>
> This release disables or removes certain modules that required third-party
> dependencies that are no longer maintained, and it updates a number of
> other dependencies.
>
> The release candidate can be found here:
> https://dist.apache.org/repos/dist/dev/flex/BlazeDS/4.8.0/rc1/
>
> Before voting please review the section, "What are the ASF requirements on
> approving a release?", at:
> https://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 you can compile from source package using `mvn clean install`
>
> The KEYS file is at https://dist.apache.org/repos/dist/release/flex/KEYS
>
> Please vote to approve this release:
> +1 Approve the release
> -1 Don’t approve 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
>
> If you find an issue with the release that's a "show stopper" please don't
> hold off voting -1. If someone votes -1, please continue testing. We want
> to try and catch as many issues as we can and cut down on the number of
> release candidates. Remember existing voters can change their vote during
> the voting process.
>
> People who are not in the 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.
>
> Please put all discussion about this release in the DISCUSS thread – not in
> this VOTE thread.
>
> Thanks,
> Josh
>

Re: [DISCUSS] Release Apache Flex BlazeDS 4.8.0 RC1

[Greg Dove]

Hi Josh,

Just a quick note to say that I will test and review the build this coming
weekend. Sorry I can't get there sooner.

-Greg


On Thu, Mar 9, 2023 at 12:01 PM Josh Tynjala  wrote:

> Hi,
>
> Please discuss the BlazeDS 4.8.0 release candidate here and not in the vote
> thread.
>
> Thanks,
> Josh
>

Re: [DISCUSS] Release Apache flex-sdk-converter-maven-extension 1.1.0 RC1

[Greg Dove]

Just for the record: when I compiled I was using openjdk 11.0.6, so that is
the reason I did not encounter that issue.



On Fri, Feb 10, 2023 at 9:30 PM Yishay Weiss  wrote:

> I can confirm that it compiles on windows for java 8. I’ll try to do some
> more checks later and vote. Thanks.
>
> From: Josh Tynjala
> Sent: Thursday, February 9, 2023 6:24 PM
> To: dev@flex.apache.org
> Subject: Re: [DISCUSS] Release Apache flex-sdk-converter-maven-extension
> 1.1.0 RC1
>
> I confirm that PlatformTypeTest fails with JDK 17, but works in JDK 8 and
> 11. The test seems to be using reflection to change a private property in
> the JDK to non-final so that it can pretend to be running on a different
> platform temporarily. Some quick research turned up that the JDK authors
> made things stricter in JDK 12 because doing something like this should not
> be encouraged.
>
> This test is broken, but the behavior of flex-sdk-converter-maven-extension
> is still correct. I will definitely fix the test for future releases.
>
> Yishay, would you be willing to test `mvn clean install` with JDK 11 so
> that we don't need to do a new RC? If you're going to try it with
> royale-compiler, you can switch back to JDK 17 for that.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Wed, Feb 8, 2023 at 11:10 PM Yishay Weiss 
> wrote:
>
> > I’m getting this:
> >
> > C:\dev\apache-flex-sdk-converter-1.1.0>mvn clean install
> > Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
> > [INFO] Scanning for projects...
> > [INFO]
> > 
> > [INFO] Reactor Build Order:
> > [INFO]
> > [INFO] Apache Flex - SDK-Converter
> > [pom]
> > [
> > (…)
> >
> > [INFO]  T E S T S
> > [INFO] ---
> > [INFO] Running
> > org.apache.flex.utilities.converter.retrievers.types.PlatformTypeTest
> > [ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed:
> > 0.082 s <<< FAILURE! - in
> > org.apache.flex.utilities.converter.retrievers.types.PlatformTypeTest
> > [ERROR] [0] IS_OS_WINDOWS, WINDOWS
> >
> (it_detects_the_current_platform_type)(org.apache.flex.utilities.converter.retrievers.types.PlatformTypeTest)
> > Time elapsed: 0.009 s  <<< ERROR!
> > java.lang.NoSuchFieldException: modifiers
> > at
> >
> org.apache.flex.utilities.converter.retrievers.types.PlatformTypeTest.setFinalStatic(PlatformTypeTest.java:74)
> > at
> >
> org.apache.flex.utilities.converter.retrievers.types.PlatformTypeTest.setUp(PlatformTypeTest.java:51)
> >
> > From: Josh Tynjala
> > Sent: Friday, February 3, 2023 6:23 PM
> > To: dev@flex.apache.org
> > Subject: Re: [DISCUSS] Release Apache flex-sdk-converter-maven-extension
> > 1.1.0 RC1
> >
> > At minimum, extract the source-release .zip file and run `mvn clean
> > install` in the root directory that contains pom.xml.
> >
> > OPTIONAL: After `mvn clean isntall`, you can also test that it works with
> > the royale-compiler repo (be sure to pull the latest commits). Here's
> what
> > you need to do:
> >
> > (Prerequisite: Make sure that you have the FLASHPLAYER_DEBUGGER env var
> > pointing to a Flash Player projector executable. If you don't have this
> > executable already, the royale-compiler README explains how you can still
> > download it from Adobe.)
> >
> > 1. In royale-compiler, go into .mvn/extensions.xml and set the version to
> > 1.1.0: 1.1.0
> > 2. Go into ~/.m2/repository/com/adobe/flash/ and move the "framework"
> > directory somewhere else temporarily. This lets you put it back later, if
> > something goes wrong.
> > 3. In royale-compiler, run `mvn clean install -P option-with-swf`.
> >
> > If the royale-compiler option-with-swf build passes, then the extension
> > successfully installed playerglobal 32.0.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC 
> >
> >
> > On Thu, Feb 2, 2023 at 11:28 PM Harbs  wrote:
> >
> > > What do I need to do to test this?
> > >
> > > > On Feb 3, 2023, at 1:15 AM, Josh Tynjala 
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Please discuss the flex-sdk-converter-maven-extension 1.1.0 release
> > > > candidate here and not in the vote thread.
> > > >
> > > > Thanks,
> > > > Josh
> > >
> > >
> >
> >
>
>

Re: [DISCUSS] Release Apache flex-sdk-converter-maven-extension 1.1.0 RC1

[Greg Dove]

Thanks for your work on this, Josh. I followed your guide in here, and
think I covered all the required testing, and added my vote in the vote
thread
-Greg

On Sat, Feb 4, 2023 at 5:23 AM Josh Tynjala 
wrote:

> At minimum, extract the source-release .zip file and run `mvn clean
> install` in the root directory that contains pom.xml.
>
> OPTIONAL: After `mvn clean isntall`, you can also test that it works with
> the royale-compiler repo (be sure to pull the latest commits). Here's what
> you need to do:
>
> (Prerequisite: Make sure that you have the FLASHPLAYER_DEBUGGER env var
> pointing to a Flash Player projector executable. If you don't have this
> executable already, the royale-compiler README explains how you can still
> download it from Adobe.)
>
> 1. In royale-compiler, go into .mvn/extensions.xml and set the version to
> 1.1.0: 1.1.0
> 2. Go into ~/.m2/repository/com/adobe/flash/ and move the "framework"
> directory somewhere else temporarily. This lets you put it back later, if
> something goes wrong.
> 3. In royale-compiler, run `mvn clean install -P option-with-swf`.
>
> If the royale-compiler option-with-swf build passes, then the extension
> successfully installed playerglobal 32.0.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Thu, Feb 2, 2023 at 11:28 PM Harbs  wrote:
>
> > What do I need to do to test this?
> >
> > > On Feb 3, 2023, at 1:15 AM, Josh Tynjala 
> > wrote:
> > >
> > > Hi,
> > >
> > > Please discuss the flex-sdk-converter-maven-extension 1.1.0 release
> > > candidate here and not in the vote thread.
> > >
> > > Thanks,
> > > Josh
> >
> >
>

Re: [VOTE] Release Apache flex-sdk-converter-maven-extension 1.1.0 RC1

[Greg Dove]

Vote: +1

based on following checks conducted:
-sha512 hash matches the release.zip hash
-signing key matches Josh (following
https://www.apache.org/info/verification.html)
-nothing unusual observed from README, RELEASE_NOTES, NOTICE and LICENSE
files
-source code compiles without error.
-usage of the updated maven artifact at version 1.1.0 in build of
royale-compiler (instructions provided by Josh in separate DISCUSSION
thread), as part of a full royale maven build proceeds without error and
the {User}\.m2\repository\com\adobe\flash\framework\playerglobal\32.0 is
populated





On Fri, Feb 3, 2023 at 12:15 PM Josh Tynjala 
wrote:

> Hi,
>
> This is the vote for the 1.1.0 release of Apache
> flex-sdk-converter-maven-extension.
>
> This release fixes an HTTP to HTTPS redirect issue that causes Mavenized
> downloads to fail.
>
> The release candidate can be found here:
>
> https://dist.apache.org/repos/dist/dev/flex/flex-maven-tools/flex-sdk-converter/1.1.0/rc1/
>
> Before voting please review the section, "What are the ASF requirements on
> approving a release?", at:
> https://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 you can compile from source package
>
> The KEYS file is at https://dist.apache.org/repos/dist/release/flex/KEYS
>
> Please vote to approve this release:
> +1 Approve the release
> -1 Don’t approve 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
>
> If you find an issue with the release that's a "show stopper" please don't
> hold off voting -1. If someone votes -1, please continue testing. We want
> to try and catch as many issues as we can and cut down on the number of
> release candidates. Remember existing voters can change their vote during
> the voting process.
>
> People who are not in the 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.
>
> Please put all discussion about this release in the DISCUSSION thread not
> this VOTE thread.
>
> Thanks,
> Josh
>

Re: Update on Adobe Flash Player End of Support from Microsoft today

[Greg Dove]

> Microsoft didn't actually bundle or package the Flash Player with their
> browsers.


I'm sorry, but I don't think the above statement is correct, Nick.
Microsoft has had a custom flash player build for some time now. It was
many years ago a separate activex plugin from Adobe, but my understanding
is that in more recent years it has been a Microsoft custom build bundled
with the browsers. Flash player updates on windows are distributed via
windows update. It sounds like (from the Microsoft blog post) that the
changes beyond 2020 for continuing function might require switching to the
separate plugin, but I am not really sure about this yet.
On the flipside, I also did not think that Firefox bundled the player, but
maybe I missed that news. I have always just had the separate debug player
plugin installed for my Firefox browser, which still works fine as a plugin
(but if you are right about Firefox, then maybe I set up some
special config for that a long time ago, and forgot about it since).

Regardless, I certainly don't view this IE news as a 'long term solution',
assuming it does mean that we have extra time beyond 2020 for IE11. Like
you, I think it will possibly just 'buy us a few more months'. It doesn't
actually stop the need to migrate apps or content to html5, but it just
might provide a little more transition time.
But potentially it might mean that when porting apps to html5, there could
be greater willingness to avoid the need to officially support IE11 in the
html5 version, which is good news IMO. I think there are lots of extra nice
things in modern browsers that are closer to flash player capabilities
(which makes it easier to emulate the original flash content/app) than is
the case in IE11. Building html5 versions of flash content that are
IE11-compatible is extra work, or needs extra polyfills or compromises, so
if people are more inclined to ditch IE11, that is a good thing I think
(and hope).

Anyway, it still seems like we need some firm verification of these
details...

Cheers
Greg




On Mon, Sep 7, 2020 at 4:08 AM Nicholas Kwiatkowski <
nicholaskwiatkow...@gmail.com> wrote:

> Remember, unlike Firefox and Chrome, Microsoft didn't actually bundle or
> package the Flash Player with their browsers.  They relied on the
> desktop-installed Flash Player plugin.
>
> So, it may be true that it will continue to run (they won't stop it), but
> the Flash Player won't get any more bug or security updates.  Microsoft
> /will/ encourage people to uninstall versions, and I expect that future
> versions of virus scanners will flag it when the next big security issue
> occurs.  Additionally, Adobe is going to stop distributing it, meaning that
> new PCs or re-installs won't have access to versions directly from Adobe.
>
> TLDR: this may buy us a few months, at best -- unless you have a locked
> down, kiosk PC that you need to run the content.  Don't expect that the
> Flash Player in the browser is going to be a viable option for much
> longer...
>
> -Nick
>
> On Sat, Sep 5, 2020 at 1:10 AM Greg Dove  wrote:
>
> > Yes this gives some 'hope' :)
> > But it is difficult to be sure.
> >
> > It does seem to contradict one statement in this page:
> > https://www.adobe.com/products/flashplayer/end-of-life.html
> > 'Flash-based content will be blocked from running in Adobe Flash Player
> > after the EOL Date'
> >
> > Are there any Adobe employees reading this thread who could verify the
> > interpretation of the Microsoft blog post?
> >
> >
> >
> > On Sat, Sep 5, 2020 at 2:45 PM Flex Developer <
> shyamforf...@gmail.com
> > >
> > wrote:
> >
> > > Yes... i also thought all browsers  will stop running flash.
> > > But this article seems to  suggest that Microsoft will still support
> > Flash
> > > player in IE11 post DEC 2020.
> > > I also could not get clearly interpret this blog post if this is the
> > case.
> > >
> > > Regards,
> > > Shyam
> > >
> > > On Fri, Sep 4, 2020 at 5:27 PM Greg Dove  wrote:
> > >
> > > > That's interesting, it does sound like it might continue to be
> > > 'available'
> > > > in terms of 'function' after 2020 for player versions since June this
> > > year,
> > > > but disabled by default and not 'supported'in the old Edge and in
> IE11.
> > > > That interpretation is actually 'better' than I had understood it to
> be
> > > in
> > > > the past (I assumed it would cease to function after 2020). But I am
> > > still
> > > > not 100% clear on that after reading this.
> > > >
> > > > I think it would probably require a very specific question and
> response
> > &

Re: Update on Adobe Flash Player End of Support from Microsoft today

[Greg Dove]

Yes this gives some 'hope' :)
But it is difficult to be sure.

It does seem to contradict one statement in this page:
https://www.adobe.com/products/flashplayer/end-of-life.html
'Flash-based content will be blocked from running in Adobe Flash Player
after the EOL Date'

Are there any Adobe employees reading this thread who could verify the
interpretation of the Microsoft blog post?



On Sat, Sep 5, 2020 at 2:45 PM Flex Developer 
wrote:

> Yes... i also thought all browsers  will stop running flash.
> But this article seems to  suggest that Microsoft will still support Flash
> player in IE11 post DEC 2020.
> I also could not get clearly interpret this blog post if this is the case.
>
> Regards,
> Shyam
>
> On Fri, Sep 4, 2020 at 5:27 PM Greg Dove  wrote:
>
> > That's interesting, it does sound like it might continue to be
> 'available'
> > in terms of 'function' after 2020 for player versions since June this
> year,
> > but disabled by default and not 'supported'in the old Edge and in IE11.
> > That interpretation is actually 'better' than I had understood it to be
> in
> > the past (I assumed it would cease to function after 2020). But I am
> still
> > not 100% clear on that after reading this.
> >
> > I think it would probably require a very specific question and response
> > from Microsoft (and/or Adobe) to clarify this. It would be great if
> > Microsoft and Adobe published some FAQs on this...
> >
> >
> >
> >
> >
> > On Sat, Sep 5, 2020 at 10:10 AM Flex Developer <
> > shyamforf...@gmail.com>
> > wrote:
> >
> > > Hi All,
> > >
> > > I am not sure if anything has changed regarding Flash Player.
> > >
> > > Wanted to clarify if Microsoft is saying that IE11 will still run Flash
> > > Player post Dec 2020.
> > >
> > > Can anyone share their understanding from below blog post today from
> > > Microsoft ?
> > >
> > >
> > >
> >
> https://blogs.windows.com/msedgedev/2020/09/04/update-adobe-flash-end-support/
> > >
> > >
> > > Regards,
> > > Shyam
> > >
> >
>

Re: Update on Adobe Flash Player End of Support from Microsoft today

[Greg Dove]

That's interesting, it does sound like it might continue to be 'available'
in terms of 'function' after 2020 for player versions since June this year,
but disabled by default and not 'supported'in the old Edge and in IE11.
That interpretation is actually 'better' than I had understood it to be in
the past (I assumed it would cease to function after 2020). But I am still
not 100% clear on that after reading this.

I think it would probably require a very specific question and response
from Microsoft (and/or Adobe) to clarify this. It would be great if
Microsoft and Adobe published some FAQs on this...





On Sat, Sep 5, 2020 at 10:10 AM Flex Developer 
wrote:

> Hi All,
>
> I am not sure if anything has changed regarding Flash Player.
>
> Wanted to clarify if Microsoft is saying that IE11 will still run Flash
> Player post Dec 2020.
>
> Can anyone share their understanding from below blog post today from
> Microsoft ?
>
>
> https://blogs.windows.com/msedgedev/2020/09/04/update-adobe-flash-end-support/
>
>
> Regards,
> Shyam
>

Re: MXRoyale question - styleName

[Greg Dove]

Back to original topic:

I plan to work on that change at my EOD today. I was thinking to implement
this directly using native element.classList.add/element.classList.remove
for the string assignments (and adjust the trace warning for other types)

I also see org.apache.royale.utils.ClassSelectorList. Can you think of a
reason why that would be needed here? I assume it should not be needed.

Thanks
Greg

On Fri, May 8, 2020 at 5:40 AM Greg Dove  wrote:

>
> Oh, I know it's still out there. But we know it is small and getting
> smaller. It is the age-old dilemma of the needs-of-the-few dictating the
> needs-of-the-many. I don't think the laggards are those who use it for
> personal browser. Use as the 'internal' browser in corporates has to be
> getting less over time. And if they actually lock down updates, then maybe
> they will not lose flash player internally anyway (or could choose not to).
> I understand we are stuck with it for now, I was just expressing that it
> does hold Royale back.
>
> For Proxy, I don't think major re-writes would be necessary - perhaps they
> would be useful in some cases, but they may not be necessary. I have used
> it in the past, but it has been a while now. It does not participate in
> inheritance or typing. So you could simply use it to decorate instances to
> make them runtime savvy, and that may not need to be all instances for
> example, it could just be in parts of code that need it. For XML I don't
> know what the memory overhead would be of using it for every instance, and
> it may not be something to do by default. Proxy could perhaps be something
> that you use in places where it's needed (@royalexmlruntimeinstances -
> construct with Proxy support inside this function scope)  and otherwise
> not, for example. To be clear, I'm not worried about this specifically now,
> I was just replying to your earlier comment that it would be hard or slow
> to do runtime property access - I think the way Proxy works may mean it is
> not too difficult, but making it selective and not for all instances would
> still be preferable I assume (which is work in the compiler).
>
>
>
> On Fri, May 8, 2020 at 4:59 AM Yishay Weiss 
> wrote:
>
>> Yes, I was meaning to respond to that. Our client opened up our POC on
>> his default browser, which is IE11, and saw nothing working. It’s still out
>> there.
>>
>> >It's interesting that in the same month as someone wants modules to work
>> in IE11 we also want to get rid of IE11 support.
>>
>> On 5/7/20, 2:09 AM, "Greg Dove"  wrote:
>>
>> Assuming you meant add/remove from classList as you proposed in the
>> first
>> post, then I think the answer is yes.
>>
>> yes, that's what I really meant. Ok, I will add that to MXRoyale
>> probably
>> tomorrow.
>>
>> Other:
>> I do expect to be contributing more to MXRoyale over coming
>> weeks/months -
>> such as mxDataGrid which still needs more work over time.
>> I also saw different behavior with GridItems inside GridRow recently
>> when
>> there was no height set for example, it was not being set to full
>> height by
>> default, so I will look into that at some point (I am often using
>> workarounds for issues, but noting them as needs attention in Royale
>> - I
>> don't have time for logging issues for everything with repro at this
>> point).
>> For styles, yeah I think I saw alternatingColors for datagrid in
>> MXRoyale
>> is not correctly processed (I think it goes the browser which does not
>> understand it - and so ignores it).
>> I am working on a client project with similar justifications for
>> choosing
>> emulation I know others are looking at emulation as well for the
>> same
>> reasons.
>>
>> For people who don't care about IE11, (and I actually had someone
>> from my
>> client ask me 'why do we care about that?' recently with genuine
>> surprise)
>> then es6 Proxy would support a lot of 'runtime' emulations I think,
>> which I
>> mentioned to you previously, so I know you are aware of it. I know at
>> least
>> for certain browsers that es6 Proxy is very performant in spite of it
>> being
>> a 'Proxy' approach. I am not thinking about this for now, but really I
>> think IE11 is the only thing holding us back there. I personally
>> would like
>> to see us let go of IE11 asap after 1.0 - the more it continues to be
>> supported, the more it lingers and I do think we should look forward
>> more
>> rather than back. I think if people w

Re: MXRoyale question - styleName

[Greg Dove]

Oh, I know it's still out there. But we know it is small and getting
smaller. It is the age-old dilemma of the needs-of-the-few dictating the
needs-of-the-many. I don't think the laggards are those who use it for
personal browser. Use as the 'internal' browser in corporates has to be
getting less over time. And if they actually lock down updates, then maybe
they will not lose flash player internally anyway (or could choose not to).
I understand we are stuck with it for now, I was just expressing that it
does hold Royale back.

For Proxy, I don't think major re-writes would be necessary - perhaps they
would be useful in some cases, but they may not be necessary. I have used
it in the past, but it has been a while now. It does not participate in
inheritance or typing. So you could simply use it to decorate instances to
make them runtime savvy, and that may not need to be all instances for
example, it could just be in parts of code that need it. For XML I don't
know what the memory overhead would be of using it for every instance, and
it may not be something to do by default. Proxy could perhaps be something
that you use in places where it's needed (@royalexmlruntimeinstances -
construct with Proxy support inside this function scope)  and otherwise
not, for example. To be clear, I'm not worried about this specifically now,
I was just replying to your earlier comment that it would be hard or slow
to do runtime property access - I think the way Proxy works may mean it is
not too difficult, but making it selective and not for all instances would
still be preferable I assume (which is work in the compiler).



On Fri, May 8, 2020 at 4:59 AM Yishay Weiss  wrote:

> Yes, I was meaning to respond to that. Our client opened up our POC on his
> default browser, which is IE11, and saw nothing working. It’s still out
> there.
>
> >It's interesting that in the same month as someone wants modules to work
> in IE11 we also want to get rid of IE11 support.
>
> On 5/7/20, 2:09 AM, "Greg Dove"  wrote:
>
> Assuming you meant add/remove from classList as you proposed in the
> first
> post, then I think the answer is yes.
>
> yes, that's what I really meant. Ok, I will add that to MXRoyale
> probably
> tomorrow.
>
> Other:
> I do expect to be contributing more to MXRoyale over coming
> weeks/months -
> such as mxDataGrid which still needs more work over time.
> I also saw different behavior with GridItems inside GridRow recently
> when
> there was no height set for example, it was not being set to full
> height by
> default, so I will look into that at some point (I am often using
> workarounds for issues, but noting them as needs attention in Royale -
> I
> don't have time for logging issues for everything with repro at this
> point).
> For styles, yeah I think I saw alternatingColors for datagrid in
> MXRoyale
> is not correctly processed (I think it goes the browser which does not
> understand it - and so ignores it).
> I am working on a client project with similar justifications for
> choosing
> emulation I know others are looking at emulation as well for the
> same
> reasons.
>
> For people who don't care about IE11, (and I actually had someone from
> my
> client ask me 'why do we care about that?' recently with genuine
> surprise)
> then es6 Proxy would support a lot of 'runtime' emulations I think,
> which I
> mentioned to you previously, so I know you are aware of it. I know at
> least
> for certain browsers that es6 Proxy is very performant in spite of it
> being
> a 'Proxy' approach. I am not thinking about this for now, but really I
> think IE11 is the only thing holding us back there. I personally would
> like
> to see us let go of IE11 asap after 1.0 - the more it continues to be
> supported, the more it lingers and I do think we should look forward
> more
> rather than back. I think if people want to keep using old IE browsers
> internally with its risks etc, then they could probably keep using IE10
> just for swf apps (iirc IE10 probably won't, but IE11 will get the
> maintenance update that removes flash player at the end of the
> year if
> IE11 did not, then I can't understand why we would continue to support
> it
> for Royale, IMO, it is just holding us back).
>
> anyway... that's off topic. For another time
>
>
>
> On Thu, May 7, 2020 at 6:37 PM Alex Harui 
> wrote:
>
> > Assuming you meant add/remove from classList as you proposed in the
> first
> > post, then I think the answer is yes.  I think that's simple enough
> to
> > emulate and will work most of the time.  I think you have to u

Re: MXRoyale question - styleName

[Greg Dove]

Assuming you meant add/remove from classList as you proposed in the first
post, then I think the answer is yes.

yes, that's what I really meant. Ok, I will add that to MXRoyale probably
tomorrow.

Other:
I do expect to be contributing more to MXRoyale over coming weeks/months -
such as mxDataGrid which still needs more work over time.
I also saw different behavior with GridItems inside GridRow recently when
there was no height set for example, it was not being set to full height by
default, so I will look into that at some point (I am often using
workarounds for issues, but noting them as needs attention in Royale - I
don't have time for logging issues for everything with repro at this point).
For styles, yeah I think I saw alternatingColors for datagrid in MXRoyale
is not correctly processed (I think it goes the browser which does not
understand it - and so ignores it).
I am working on a client project with similar justifications for choosing
emulation I know others are looking at emulation as well for the same
reasons.

For people who don't care about IE11, (and I actually had someone from my
client ask me 'why do we care about that?' recently with genuine surprise)
then es6 Proxy would support a lot of 'runtime' emulations I think, which I
mentioned to you previously, so I know you are aware of it. I know at least
for certain browsers that es6 Proxy is very performant in spite of it being
a 'Proxy' approach. I am not thinking about this for now, but really I
think IE11 is the only thing holding us back there. I personally would like
to see us let go of IE11 asap after 1.0 - the more it continues to be
supported, the more it lingers and I do think we should look forward more
rather than back. I think if people want to keep using old IE browsers
internally with its risks etc, then they could probably keep using IE10
just for swf apps (iirc IE10 probably won't, but IE11 will get the
maintenance update that removes flash player at the end of the year if
IE11 did not, then I can't understand why we would continue to support it
for Royale, IMO, it is just holding us back).

anyway... that's off topic. For another time



On Thu, May 7, 2020 at 6:37 PM Alex Harui  wrote:

> Assuming you meant add/remove from classList as you proposed in the first
> post, then I think the answer is yes.  I think that's simple enough to
> emulate and will work most of the time.  I think you have to use classList
> instead of className because there will be other things in the classList.
>
> For MXRoyale/SparkRoyale we are trying to have people change their code as
> little as possible.  We are not trying to set them up for the future.  IMO,
> if the migrator is willing to change a lot of code then Jewel or Basic
> should be considered.
>
> CSS is already funky in MXRoyale/SparkRoyale.  Flex supported style
> properties that don't exist in the browser (like gap and horizontalCenter,
> IIRC) and width=100% has a completely different meaning.  The emulation
> will eventually watch for certain styles and decide whether to emulate it
> in browser CSS or never set it in the browser and store the values
> elsewhere for use by getStyle calls from other code.  The layouts do the
> latter in most cases.  PercentWidth is never set on the HTMLElement.  The
> old Flex layout code runs and interprets it.
>
> In the end, it should be a collaborative effort for the migrating team and
> the framework team.  Time is running out on 2020 so the main question is
> what will get someone migrated faster?  Emulation is usually faster and
> safer than changing code paths in many places in the application and helps
> others trying to use the emulations.  But some emulations (runtime property
> access) are too hard or slow so the application does need to be changed.
>
> HTH,
> -Alex
>
> On 5/6/20, 11:08 PM, "Greg Dove"  wrote:
>
> Thanks Alex, but - as a follow-on, do you think the styleName setter
> should
> set the className if it has a string value assignment? Or should we be
> telling people to manually edit the code/mxml and swap styleName string
> value assignments to 'className' value assignments? I think for the
> majority of cases (which I think will be string values), it might be
> good
> to have it 'work by default' and we can add the warnings for
> non-strings,
> like you suggest, but I just wanted to be sure that it is better to
> 'emulate' than to force review/attention
>
>
>
> On Thu, May 7, 2020 at 5:03 PM Alex Harui 
> wrote:
>
> > Without thinking too hard, I would output a warning if someone passes
> > something other than a string.  Then we'll know if anybody really
> needs the
> > more complex cases and can figure out what to do about it then.
> >
> > -Alex
> >
>  

Re: MXRoyale question - styleName

[Greg Dove]

Thanks Alex, but - as a follow-on, do you think the styleName setter should
set the className if it has a string value assignment? Or should we be
telling people to manually edit the code/mxml and swap styleName string
value assignments to 'className' value assignments? I think for the
majority of cases (which I think will be string values), it might be good
to have it 'work by default' and we can add the warnings for non-strings,
like you suggest, but I just wanted to be sure that it is better to
'emulate' than to force review/attention



On Thu, May 7, 2020 at 5:03 PM Alex Harui  wrote:

> Without thinking too hard, I would output a warning if someone passes
> something other than a string.  Then we'll know if anybody really needs the
> more complex cases and can figure out what to do about it then.
>
> -Alex
>
> On 5/6/20, 2:11 PM, "Greg Dove"  wrote:
>
> This question is mainly for Alex or anyone else involved in porting an
> MXRoyale application.
>
> When porting styleName='myStyleName' what is considered the best
> approach?
>
> I would have assumed that styleName could simply be added to the
> underlying
> element's classList if it is a string, so it (I assume) would
> correspond
> closely to how it was used in the original Flex app. But I know
> styleName
> is not always a string in Flex, but in my experience that seems to be
> the
> most frequent case, which relates to a named declaration in the
> stylesheet.
>
> Alex, and others, what are your thoughts? I am dealing with a large
> codebase and would like to use a consistent approach from the outset.
>
> At the moment we have;
>
> set styleName(value:Object /* String, CSSStyleDeclaration, or
> UIComponent
> */):void
> ...
>   // TODO
> trace("styleName not implemented");
>
> if it is a string, then I assume it could be considered as a
> custom/arbitrary css class, similar to how I remember it working in
> Flex.
>
> UIComponent seems more problematic I assume, but I have not thought too
> deeply about it.
>
> Anyway I would welcome thoughts. I guess one simple option is simply to
> change it to className when porting if it is a string. But for
> MXRoyale I
> wondered if this should work (if it can) without changes
>
>
>

MXRoyale question - styleName

[Greg Dove]

This question is mainly for Alex or anyone else involved in porting an
MXRoyale application.

When porting styleName='myStyleName' what is considered the best approach?

I would have assumed that styleName could simply be added to the underlying
element's classList if it is a string, so it (I assume) would correspond
closely to how it was used in the original Flex app. But I know styleName
is not always a string in Flex, but in my experience that seems to be the
most frequent case, which relates to a named declaration in the stylesheet.

Alex, and others, what are your thoughts? I am dealing with a large
codebase and would like to use a consistent approach from the outset.

At the moment we have;

set styleName(value:Object /* String, CSSStyleDeclaration, or UIComponent
*/):void
...
  // TODO
trace("styleName not implemented");

if it is a string, then I assume it could be considered as a
custom/arbitrary css class, similar to how I remember it working in Flex.

UIComponent seems more problematic I assume, but I have not thought too
deeply about it.

Anyway I would welcome thoughts. I guess one simple option is simply to
change it to className when porting if it is a string. But for MXRoyale I
wondered if this should work (if it can) without changes

Re: SWF Graphics api emulation.

[Greg Dove]

I just had it pointed out to me that this thread was in the Flex dev list.
That was not my intention, this topic is in relation to Royale. It should
have been on that list. Sorry for any confusion this may have caused.
To eliminate the possibility of any misunderstanding: The drawing api
emulation is definitely not for 'Flex' , it will be for Royale, to support
enhanced compatibility with legacy as3 code in html5 output.


On Tue, Dec 10, 2019 at 9:01 PM Harbs  wrote:

> Cool!
>
> At some point I’d love to get this kind of stuff working in Canvas as well.
>
> BTW, I like your domain name. :-)
>
> Harbs
>
> > On Dec 10, 2019, at 9:12 AM, Greg Dove  wrote:
> >
> > This is player level emulation of [1], supporting (as much as possible)
> > direct use of legacy flash player-level (i.e. no graphics lib) drawing
> > code. So it is more the flash.display.* stuff that relates to drawing,
> and
> > it's not going to be the right solution for everyone (even the client
> that
> > wants it, I will try to move them to svg, but for now this is a good
> > option, and I think it will help others. I also think I can get some
> > 'flash' people interested in the project who never used Flex in the
> past).
> >
> > I'm also making sure it emulates the various quirks in the flash drawing
> > api, which sometimes can be relied upon (negative widths, negative corner
> > radii etc)
> > I have the gradient and solid colors working, Currently no bitmapData,
> but
> > I plan to add that.
> >
> > Here's how I am testing across machines [1]. If you want to test
> arbitrary
> > code, you can go into the console and simply type in 'graphics' and
> > 'Matrix' commands from javascript, it will run them in both flash and
> > javascript at the same time. I have it to the point where (partly because
> > Adobe Animate timeline as3 is a bit more loosely typed) I can paste
> between
> > the js console and Adobe Animate and it works in both, which has been
> > helpful for testing various things.
> > Don't try this on a mobile device, I really only built it for desktop
> > without any thought for mobile, you need a FHD+ monitor for the side by
> > side view to be practical. If you see any issues please let me know.
> >
> >
> >
> > 1.
> >
> https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Graphics.html
> >
> > 2.
> >
> http://interactionscript.com/royale/swf-graphics/index.html?defaultTest=2,0
> >
> > On Tue, Dec 10, 2019 at 7:44 PM Harbs  wrote:
> >
> >> How is the work different than the current Graphics project and the svg
> >> package in Basic?
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On Dec 10, 2019, at 4:51 AM, Greg Dove  wrote:
> >>>
> >>> Just some early advice that I expect to have a very close emulation of
> >> the
> >>> flash graphics API available by early January at the latest. I had a
> >> client
> >>> express a need for this, and I have quite a lot of progress already.
> >>> I know we have various graphics support already in Graphics and
> MXRoyale,
> >>> but the emphasis for this will be on the closest match to swf that I
> can
> >>> reasonably achieve. I'm reasonably familiar with this stuff from
> things I
> >>> have done in the past (although much of that was 10-12 years ago now).
> >>>
> >>> There are some things that, while technically possible may not be
> >>> 'practical' to emulate based on how heavy the code would be to achieve
> >> that
> >>> in JS. One of these is the miter joint implementation in flash which is
> >> not
> >>> currently available in a similar way in svg. Unfortunately it seems
> that
> >>> will not be available in svg 2.0 even though it was intended to be.
> >>> Also some browser/OS combinations seem to not handle certain gradients
> >> very
> >>> well. In general windows is better than mac for these, and Safari on
> Mac
> >>> seems to be the most problematic so far. I did not focus a lot on
> mobile,
> >>> but things were working quite good in a 2013 Galaxy Tablet, for
> example.
> >>>
> >>> Anyhow I just wanted to let others know I was working on this, and hope
> >> to
> >>> share progress soon.
> >>>
> >>> -Greg
> >>
> >>
>
>

Re: SWF Graphics api emulation.

[Greg Dove]

Here's how I am testing across machines [1]  <-- that should be [2]


On Tue, Dec 10, 2019 at 8:12 PM Greg Dove  wrote:

>
> This is player level emulation of [1], supporting (as much as possible)
> direct use of legacy flash player-level (i.e. no graphics lib) drawing
> code. So it is more the flash.display.* stuff that relates to drawing, and
> it's not going to be the right solution for everyone (even the client that
> wants it, I will try to move them to svg, but for now this is a good
> option, and I think it will help others. I also think I can get some
> 'flash' people interested in the project who never used Flex in the past).
>
> I'm also making sure it emulates the various quirks in the flash drawing
> api, which sometimes can be relied upon (negative widths, negative corner
> radii etc)
> I have the gradient and solid colors working, Currently no bitmapData, but
> I plan to add that.
>
> Here's how I am testing across machines [1]. If you want to test arbitrary
> code, you can go into the console and simply type in 'graphics' and
> 'Matrix' commands from javascript, it will run them in both flash and
> javascript at the same time. I have it to the point where (partly because
> Adobe Animate timeline as3 is a bit more loosely typed) I can paste between
> the js console and Adobe Animate and it works in both, which has been
> helpful for testing various things.
> Don't try this on a mobile device, I really only built it for desktop
> without any thought for mobile, you need a FHD+ monitor for the side by
> side view to be practical. If you see any issues please let me know.
>
>
>
> 1.
> https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Graphics.html
>
> 2.
> http://interactionscript.com/royale/swf-graphics/index.html?defaultTest=2,0
>
> On Tue, Dec 10, 2019 at 7:44 PM Harbs  wrote:
>
>> How is the work different than the current Graphics project and the svg
>> package in Basic?
>>
>> Thanks,
>> Harbs
>>
>> > On Dec 10, 2019, at 4:51 AM, Greg Dove  wrote:
>> >
>> > Just some early advice that I expect to have a very close emulation of
>> the
>> > flash graphics API available by early January at the latest. I had a
>> client
>> > express a need for this, and I have quite a lot of progress already.
>> > I know we have various graphics support already in Graphics and
>> MXRoyale,
>> > but the emphasis for this will be on the closest match to swf that I can
>> > reasonably achieve. I'm reasonably familiar with this stuff from things
>> I
>> > have done in the past (although much of that was 10-12 years ago now).
>> >
>> > There are some things that, while technically possible may not be
>> > 'practical' to emulate based on how heavy the code would be to achieve
>> that
>> > in JS. One of these is the miter joint implementation in flash which is
>> not
>> > currently available in a similar way in svg. Unfortunately it seems that
>> > will not be available in svg 2.0 even though it was intended to be.
>> > Also some browser/OS combinations seem to not handle certain gradients
>> very
>> > well. In general windows is better than mac for these, and Safari on Mac
>> > seems to be the most problematic so far. I did not focus a lot on
>> mobile,
>> > but things were working quite good in a 2013 Galaxy Tablet, for example.
>> >
>> > Anyhow I just wanted to let others know I was working on this, and hope
>> to
>> > share progress soon.
>> >
>> > -Greg
>>
>>

Re: SWF Graphics api emulation.

[Greg Dove]

This is player level emulation of [1], supporting (as much as possible)
direct use of legacy flash player-level (i.e. no graphics lib) drawing
code. So it is more the flash.display.* stuff that relates to drawing, and
it's not going to be the right solution for everyone (even the client that
wants it, I will try to move them to svg, but for now this is a good
option, and I think it will help others. I also think I can get some
'flash' people interested in the project who never used Flex in the past).

I'm also making sure it emulates the various quirks in the flash drawing
api, which sometimes can be relied upon (negative widths, negative corner
radii etc)
I have the gradient and solid colors working, Currently no bitmapData, but
I plan to add that.

Here's how I am testing across machines [1]. If you want to test arbitrary
code, you can go into the console and simply type in 'graphics' and
'Matrix' commands from javascript, it will run them in both flash and
javascript at the same time. I have it to the point where (partly because
Adobe Animate timeline as3 is a bit more loosely typed) I can paste between
the js console and Adobe Animate and it works in both, which has been
helpful for testing various things.
Don't try this on a mobile device, I really only built it for desktop
without any thought for mobile, you need a FHD+ monitor for the side by
side view to be practical. If you see any issues please let me know.



1.
https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Graphics.html

2.
http://interactionscript.com/royale/swf-graphics/index.html?defaultTest=2,0

On Tue, Dec 10, 2019 at 7:44 PM Harbs  wrote:

> How is the work different than the current Graphics project and the svg
> package in Basic?
>
> Thanks,
> Harbs
>
> > On Dec 10, 2019, at 4:51 AM, Greg Dove  wrote:
> >
> > Just some early advice that I expect to have a very close emulation of
> the
> > flash graphics API available by early January at the latest. I had a
> client
> > express a need for this, and I have quite a lot of progress already.
> > I know we have various graphics support already in Graphics and MXRoyale,
> > but the emphasis for this will be on the closest match to swf that I can
> > reasonably achieve. I'm reasonably familiar with this stuff from things I
> > have done in the past (although much of that was 10-12 years ago now).
> >
> > There are some things that, while technically possible may not be
> > 'practical' to emulate based on how heavy the code would be to achieve
> that
> > in JS. One of these is the miter joint implementation in flash which is
> not
> > currently available in a similar way in svg. Unfortunately it seems that
> > will not be available in svg 2.0 even though it was intended to be.
> > Also some browser/OS combinations seem to not handle certain gradients
> very
> > well. In general windows is better than mac for these, and Safari on Mac
> > seems to be the most problematic so far. I did not focus a lot on mobile,
> > but things were working quite good in a 2013 Galaxy Tablet, for example.
> >
> > Anyhow I just wanted to let others know I was working on this, and hope
> to
> > share progress soon.
> >
> > -Greg
>
>

SWF Graphics api emulation.

[Greg Dove]

Just some early advice that I expect to have a very close emulation of the
flash graphics API available by early January at the latest. I had a client
express a need for this, and I have quite a lot of progress already.
I know we have various graphics support already in Graphics and MXRoyale,
but the emphasis for this will be on the closest match to swf that I can
reasonably achieve. I'm reasonably familiar with this stuff from things I
have done in the past (although much of that was 10-12 years ago now).

There are some things that, while technically possible may not be
'practical' to emulate based on how heavy the code would be to achieve that
in JS. One of these is the miter joint implementation in flash which is not
currently available in a similar way in svg. Unfortunately it seems that
will not be available in svg 2.0 even though it was intended to be.
Also some browser/OS combinations seem to not handle certain gradients very
well. In general windows is better than mac for these, and Safari on Mac
seems to be the most problematic so far. I did not focus a lot on mobile,
but things were working quite good in a 2013 Galaxy Tablet, for example.

Anyhow I just wanted to let others know I was working on this, and hope to
share progress soon.

-Greg

Re: Can't debug. Plug-ins do nothing.

[Greg Dove]

I went through this not so long ago. fyi the best option I found was Opera.
It's now like Chrome, but flash debugging still worked for me. If you can't
get anything else to work, you might want to try that.



On Fri, Dec 7, 2018 at 6:27 PM Piotr Zarzycki 
wrote:

> Hi Dannemann,
>
> If I remember correctly you have to push your application to the server.
> Open in the browser and than attach debugger. This is the only way of
> resolving that issue.
>
> Thanks, Piotr
>
> pt., 7 gru 2018 o 05:52 Dannemann  napisał(a):
>
> > I cannot debug after installing the debuggers (version 31).
> >
> > I looks like firefox has disabled npapi and edge has it sandboxed.. I
> saw a
> > topic in microsoft where the support says it is impossible to debug in it
> > right now.. same thing in chrome.. I am using windows 10 and the most
> > updated browsers
> >
> > I get the message "To view this page ensure that Adobe Flash Player
> version
> > 31.0.0 or greater is installed. "
> >
> > thank you in advance
> >
> >
> >
> > --
> > Sent from: http://apache-flex-development.247.n4.nabble.com/
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>

Re: [Discuss] Apache Flex SDK Installer 3.3.2 RC1*

[Greg Dove]

I just gave it a try (Win 10).

It's definitely not without some friction, but it works!

I think I did not realize that it had launched the downloaded 64 bit
version so I did exit and relaunch from 32 bit again before I 'got' it.
Anyhow I installed 4.16.1/Air 30 sdk sucessfully with it.

Observations:
It also did have a weird startup window position where it was spanning
monitors and had a vertical offset in my multi-monitor setup when launched
(which may be something new or may be because I have a new setup and this
is the first time I am using the installer on it) but that is just a simple
matter of moving the window.

I saw a couple of Norton warnings along the way, including one for the
downloaded 64 bit version missing a valid signature.


On Thu, Jun 21, 2018 at 11:14 AM Alex Harui 
wrote:

> Can some folks on Windows try this version of the Installer?  You will
> need to uninstall the current Installer first.
>
>
> https://dist.apache.org/repos/dist/dev/flex/installer/3.3.2/rc2/binaries/apache-flex-sdk-installer-3.3.2-bin.exe
>
> In theory, this will install the 32-bit installer which will warn you it
> will upgrade to the 64-bit installer then warn you that it will launch the
> 64-bit installer and close the 32-bit Installer.  And then, installing with
> the 64-bit installer should actually work.
>
> Thanks,
> -Alex
>
> On 6/19/18, 11:38 PM, "Alex Harui"  wrote:
>
> I think we're just plain running out of memory in 32-bit Windows.
>
> AFAICT, you still can't build a 64-bit Windows Native Installer even
> with AIR 30.  I think we want a Native Installer so that it can be launched
> from our website and we don't have to write some other installer.
>
> So today, I tried a trick where I taught the 32-bit installer to
> download and launch a 64-bit Captive Runtime Installer.  It works locally,
> so I pushed the changes so I can try it on Mac to make sure I didn't break
> anything.  The build changed to generate both a 32-bit Native Installer and
> a 64-bit Captive Runtime on Windows.
>
> It isn't a great user experience but it seemed easier than trying to
> implement some other 64-bit Captive Runtime Installer.  The 32-bit Native
> Installer knows how to create shortcuts in the Windows Start Menu.  Each
> time you run the Windows version of the Installer, it will put up an Alert
> saying it will launch the 64-bit version and close.  If someone wants to
> make a better experience, feel free.
>
> In the next RC, we'll need to post both the 32-bit Native and 64-bit
> Captive and update sdk-installer-config-4.0.xml to point to the 64-bit
> Captive.  To test locally, you can use the command-iine argument
> -64-bit=file:///C:/
>
> I think I'm out of time for tonight so will test Mac tomorrow.  Others
> are welcome to jump in.
>
> HTH,
> -Alex
>
> On 6/19/18, 9:27 AM, "Alex Harui"  wrote:
>
> I see that too on Windows.  Mac seems ok.  Looking into it.
>
> On 6/18/18, 4:25 PM, "extraordinaryalien" 
> wrote:
>
> Having issues on Windows - here's the log (at least we're able
> to pull FLEX
> :p):
>
> Installer version 3.3.2 (windows)
> Using Locale: en_US
> Fetched the SDK download mirror URL from the CGI.
> SDK version Apache Flex SDK 4.16.1
> AIR version 30.0
> Flash Player version 30.0
> Creating Apache Flex home
> Creating temporary directory
> Downloading Apache Flex SDK from:
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache.cs.utah.edu%2Fflex%2F4.16.1%2Fbinaries%2Fapache-flex-sdk-4.16.1-bin.zip=02%7C01%7Caharui%40adobe.com%7C126875e8c9314db9740408d5d572cfe6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636649611450867090=DM4brfWC%2FpUxUvI9QFvY3mFLCHAcgc8OBQpeQrUcPc0%3D=0
> Verifying Apache Flex SDK MD5 Signature
> The Apache Flex SDK MD5 Signature of the downloaded files
> matches the
> reference. The file is valid.
> Uncompressing:
> C:\Users\stho...@beyondconnect.com
> \Documents\Flex\temp\apache-flex-sdk-4.16.1-bin.zip
> Finished uncompressing:
> C:\Users\stho...@beyondconnect.com
> \Documents\Flex\temp\apache-flex-sdk-4.16.1-bin.zip
> Downloading Adobe AIR Runtime Kit for Windows from:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fairdownload.adobe.com%2Fair%2Fwin%2Fdownload%2F30.0%2F%2FAdobeAIRSDK.zip=02%7C01%7Caharui%40adobe.com%7C126875e8c9314db9740408d5d572cfe6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636649611450867090=ATzeaOFv0QE4%2BhqX%2BuJABWZuptcGyp14xnhJQFTyo2w%3D=0
> Error #1000
> Error: Error #1000
> at flash.net::URLLoader/onComplete()
> Installation aborted:
>
> 

[FlexJS] Re: Remote object for Flex JS

[Greg Dove]

Hi Alex,


Nice to see this stuff progressing within the framework itself. I moved
this comment to dev because of content below, and I will try to take a look
at this, to see if I can also test things in the coming week.

I quickly looked at some of the commits, perhaps I have missed something
and you may have already addressed these somewhere in the code, but here
are some quick comments just in case:
I saw some parts where you were accessing the reflection data directly.

Exclude static data items from variables and accessors
for accessors and variables they can be static as well which need to be
excluded
to keep the data compact I made the output prepend a pipe char "|" to the
items data fields that represent static members - the Refection API classes
(TypeDefinition) support this currently.

Avoid getter-only or setter-only accessors
For accessors data, there is an 'access' field which should filter those
only include accessors with access: 'readwrite' for serialization purposes.
This field has the same values as the xml data in flash native reflection.

Check Overrides
Overrides may provide duplicated data items when collected through the
inheritance chain.

This is an area that I need to test more in the Reflection classes, and it
may affect classification of accessors for serialization purposes.

Overriden accessors may perhaps represent themselves differently at
different levels iirc - I need to check this - I can't recall if I set it
up so the access status is resolved from inheritance in the data or not.
There may be a case where only a getter or setter is overridden is a
subclass from a getter/setter pair in a base class and the reflection data
may indicate it is writeonly or readonly (at the subclass level) when it is
not because of the base class definition. There could be other unusual
combinations here. (e.g. setter in base class and new getter added in
subclass which together provide readWrite access in the subclass but not
the base class). I am intending to write tests for these cases and address
any issues for the reflection api.

That's all I can think of for now, but as mentioned, I will try to check
this out in the coming week.

cheers
Greg



On Sat, Sep 2, 2017 at 6:38 AM, Alex Harui <aha...@adobe.com.invalid> wrote:

> Hi Folks,
>
> I just pushed changes that include a back port of amf.js to ActionScript.
> In doing so, the AMF code now uses the Reflection APIs that Greg Dove
> contributed.  The test still only passes a String to the server, but in
> doing so, it has to wrap the String in an AsyncMessage subclass and I
> think I have watched the AMF code correctly serialize and deserialize
> those FlexJS classes to AMF and back.
>
> Next step is to try it with an actual ValueObject.  Can someone help with
> what changes would need to be made to the service to handle a custom Java
> class instead of just a String?
>
> One other note:  In doing the back port, I created an AMFBinaryData that
> works like BinaryData, but doesn't subclass it.  That's because it appears
> to me that APIs like writeUTF do differently things.  Maybe we can factor
> out some common base class at some point.  But I think you can now use
> AMFBinaryData.writeObject/readObject to clone objects like we do with
> ByteArray.  AMFBinaryData is currently only for JS, but I think it could
> easily have SWF code that writes to a ByteArray added to it.
>
> Thanks,
> -Alex
>
> On 8/23/17, 10:32 AM, "Alex Harui" <aha...@adobe.com.INVALID> wrote:
>
> >Hi Prashant,
> >
> >The AMF work is in a separate branch so make sure you get the latest code.
> > Maybe Piotr or another volunteer will merge the branch into develop so it
> >appears in the nightly.
> >
> >-Alex
> >
> >On 8/23/17, 9:52 AM, "PKumar" <prashaku...@gmail.com> wrote:
> >
> >>Sure, I will download the FlexJS nightly build and check it.
> >>
> >>On 23-Aug-2017 10:01 PM, "Alex Harui-2 [via Apache Flex Users]" <
> >>ml+s246n1580...@n4.nabble.com> wrote:
> >>
> >>> Hi Prashant,
> >>>
> >>> If you could add to RemoteObjectAMFTest and SampleAmfWebApp to work
> >>>with
> >>> an actual ValueObject, that would be great!
> >>>
> >>> Thanks,
> >>> -Alex
> >>>
> >>> On 8/23/17, 9:21 AM, "PKumar" <[hidden email]
> >>> <http:///user/SendEmail.jtp?type=node=15807=0>> wrote:
> >>>
> >>> >Really great Alex,  if you  need my help in testing  or creating demo.
> >>>Do
> >>> >please let me know.
> >>> >
> >>> >On 23-Aug-2017 9:46 PM, "Alex Harui-2 [via Apache Flex U

Re: [3/8] git commit: [flex-asjs] [refs/heads/feature/amf] - ClassAliasBead for registering class aliases for AMF

[Greg Dove]

Hi Alex, I see you are working on amf.

Not sure if you noticed already or not, but just in case I did add
class alias support methods in the reflection package for both targets. I
tested this to work the same for swf and js. (for multiple aliases etc).
registerClassAlias
getAliasByClass
getClassByAlias

see flexUnitTests.reflection.ReflectionTesterTestAlias inside
manualtests/UnitTests




On Wed, Aug 23, 2017 at 3:20 PM,  wrote:

> ClassAliasBead for registering class aliases for AMF
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/4c2b0cfb
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/4c2b0cfb
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/4c2b0cfb
>
> Branch: refs/heads/feature/amf
> Commit: 4c2b0cfb03256391af170324687c9293cc07d13a
> Parents: 909caf1
> Author: Alex Harui 
> Authored: Tue Aug 22 18:09:16 2017 -0700
> Committer: Alex Harui 
> Committed: Tue Aug 22 18:17:09 2017 -0700
>
> --
>  .../flex/org/apache/flex/core/ClassAliasBead.as | 91 
>  .../Core/src/main/resources/basic-manifest.xml  |  1 +
>  2 files changed, 92 insertions(+)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 4c2b0cfb/frameworks/projects/Core/src/main/flex/org/apache/
> flex/core/ClassAliasBead.as
> --
> diff --git 
> a/frameworks/projects/Core/src/main/flex/org/apache/flex/core/ClassAliasBead.as
> b/frameworks/projects/Core/src/main/flex/org/apache/flex/
> core/ClassAliasBead.as
> new file mode 100644
> index 000..85ee702
> --- /dev/null
> +++ b/frameworks/projects/Core/src/main/flex/org/apache/flex/
> core/ClassAliasBead.as
> @@ -0,0 +1,91 @@
> +///
> /
> +//
> +//  Licensed to the Apache Software Foundation (ASF) under one or more
> +//  contributor license agreements.  See the NOTICE file distributed with
> +//  this work for additional information regarding copyright ownership.
> +//  The ASF licenses this file to You under the Apache License, Version
> 2.0
> +//  (the "License"); you may not use this file except in compliance with
> +//  the License.  You may obtain a copy of the License at
> +//
> +//  http://www.apache.org/licenses/LICENSE-2.0
> +//
> +//  Unless required by applicable law or agreed to in writing, software
> +//  distributed under the License is distributed on an "AS IS" BASIS,
> +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> +//  See the License for the specific language governing permissions and
> +//  limitations under the License.
> +//
> +///
> /
> +package org.apache.flex.core
> +{
> +COMPILE::SWF
> +{
> +import flash.net.registerClassAlias;
> +import flash.utils.getDefinitionByName;
> +
> +import org.apache.flex.events.Event;
> +import org.apache.flex.events.IEventDispatcher;
> +import org.apache.flex.events.ValueEvent;
> +}
> +
> +/**
> + *  The ClassAliasBead class is the registers class
> + *  aliases for serialization/deserialization.
> + *  Place this bead in the strand of the Application.
> + *  The compiler leaves information about class aliases
> + *  on the Application's info object.
> + *
> + *  @langversion 3.0
> + *  @playerversion Flash 10.2
> + *  @playerversion AIR 2.6
> + *  @productversion FlexJS 0.0
> + */
> +   public class ClassAliasBead implements IBead
> +   {
> +/**
> + *  Constructor.
> + *
> + *  @langversion 3.0
> + *  @playerversion Flash 10.2
> + *  @playerversion AIR 2.6
> + *  @productversion FlexJS 0.0
> + */
> +   public function ClassAliasBead()
> +   {
> +   }
> +
> +private var _strand:IStrand;
> +
> +/**
> + *  @copy org.apache.flex.core.IBead#strand
> + *
> + *  @flexjsignorecoercion org.apache.flex.core.IFlexInfo
> + *  @flexjsignorecoercion Class
> + *  @langversion 3.0
> + *  @playerversion Flash 10.2
> + *  @playerversion AIR 2.6
> + *  @productversion FlexJS 0.0
> + */
> +public function set strand(value:IStrand):void
> +{
> +_strand = value;
> +COMPILE::SWF
> +{
> +var app:IFlexInfo = value as IFlexInfo;
> +var info:Object = app.info();
> +var map:Object = info.remoteClassAliases;
> +if (map)
> +{
> +for 

[FlexJS] ManualTests updates

[Greg Dove]

I just made some changes in manual tests, including updates to the ant
scripts to be more consistent with the ant scripts in the regular examples.
I fixed a couple of issues in the GenericTests and renamed it to UnitTests
and also added a maven build for that project. It should be easy to add
maven to other manual tests if required and set ant build to be compatible
with maven. This might make it easier for others to join in because maven
setup seems a bit easier than ant (in terms of all the env vars).

I'd like to suggest a bit of a cleanup in here though.

Here's a bit of a status report:

1. General observations:
I do see some mouse event coercion issues in swf in some examples
(exceptions thrown in debug player). Did not investigate further.

DatabindingTestbed has a broken constant binding in swf build. Fix required
is most likely required in compiler BindingInfo:
Details:
org.apache.flex.compiler.internal.codegen.databinding.BindingInfo

line 504:
sourceString = leftDef.getBaseName() + "." + def.getBaseName();
isSimplePublicProperty = true;

The above works for as-is for js, but not for swf in the case of leftDef
being a ClassDefinition (I think)

e.g. something like 

covering this case with isSimplePublicProperty = false in BindingInfo will
fix it, but this could also likely be optimized.

2. I made some quick fixes in some of the tests:
-EffectsExample- added back the Effects timer

-FlexJSTest_SVG - changed some namespaces and gave Container width and
height (to avoid clipping at zero width and height).

-FormExample - gave Container for form inputs explicit height to avoid
clipping at zero height in js.

-ImageTest - fixed 'src' attribute for Image

-ListsTest - fixed 'src' property for Image in ProductItemRenderer

3. The following tests need review (and possible removal if they are no
longer needed?):
-DataGridXcompile build completely broken
-FlexJSTest_createjs broken (swf build)
-FlexJSTest_HTML5 broken (swf build)
-FormatExample build completely broken
-TLFEditTestFlexJS result is broken in JS (I see missing dependencies - is
this is compiler problem?)
-VanillaSDK_POC - based on the ant script, this seems obsolete and could
probably be removed?

Re: Package, Class and Method renaming

[Greg Dove]

I guess that might help with the code minification, but it may be
irrelevant with the longer original strings with something like gzip
compression already there are so many levels to this.


On Wed, Aug 9, 2017 at 9:12 AM, Greg Dove <greg.d...@gmail.com> wrote:

> Alex fyi I have wondered about breaking the class strings into literal
> concatenation expressions with package parts for CLASS_INFO and in the
> reflection data. This should end up minifying via closure compiler much
> better, I think.
> e.g.
>
> 'org.'+'apache.'+'flex.'+'events.'+'Event'
>
>
>
>
> On Wed, Aug 9, 2017 at 9:01 AM, Alex Harui <aha...@adobe.com.invalid>
> wrote:
>
>> So I just pushed a first crack at suppressing most @export statements.
>> Set -export-public-symbols=false and many @export statements should go
>> away.  The before size of TLFEditTestFlexJS was 813493 bytes.  I
>> recompiled TLF without @export symbols and the after size was 679609
>> bytes.  And it ran.
>>
>> Some things I found were that MXML isn't a problem because the id maps to
>> a getter/setter which maps to Object.DefineProperty which takes an object
>> structure where the ids are keys so they don't get renamed.  I noticed
>> that class names take up a lot of strings because they are used as a
>> literal in the FLEXJS_CLASS_INFO and thus never get minified/renamed.
>>
>> Anyway, try compiling and running your application code with this option
>> set to false and see if it obfuscates things enough or not, and whether
>> the result still runs.
>>
>> Thanks,
>> -Alex
>>
>> On 8/7/17, 9:06 AM, "Alex Harui" <aha...@adobe.com.INVALID> wrote:
>>
>> >From the output side, it probably isn't hard, but there is no way
>> succinct
>> >way to tell the compiler which classes should use @export or not.  You
>> >could annotate the class definitions, but then you can't choose to output
>> >@export without changing source.
>> >
>> >Why do you think we need per-class control over this output?
>> >
>> >-Alex
>> >
>> >On 8/7/17, 8:54 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>> >
>> >>Cool.
>> >>
>> >>How difficult would it be to allow this on a class-by-class basis?
>> >>
>> >>> On Aug 7, 2017, at 6:35 PM, Alex Harui <aha...@adobe.com.INVALID>
>> >>>wrote:
>> >>>
>> >>> First thing I will do, though, is allow turning off @export output on
>> >>> entire compiler sessions.  That might allow you to have your text
>> >>>engine
>> >>> and your application logic more aggressively renamed but not require
>> us
>> >>>to
>> >>> fix code in other SWCs that might use bracket access.
>> >>
>> >
>>
>>
>

Re: Package, Class and Method renaming

[Greg Dove]

Alex fyi I have wondered about breaking the class strings into literal
concatenation expressions with package parts for CLASS_INFO and in the
reflection data. This should end up minifying via closure compiler much
better, I think.
e.g.

'org.'+'apache.'+'flex.'+'events.'+'Event'




On Wed, Aug 9, 2017 at 9:01 AM, Alex Harui  wrote:

> So I just pushed a first crack at suppressing most @export statements.
> Set -export-public-symbols=false and many @export statements should go
> away.  The before size of TLFEditTestFlexJS was 813493 bytes.  I
> recompiled TLF without @export symbols and the after size was 679609
> bytes.  And it ran.
>
> Some things I found were that MXML isn't a problem because the id maps to
> a getter/setter which maps to Object.DefineProperty which takes an object
> structure where the ids are keys so they don't get renamed.  I noticed
> that class names take up a lot of strings because they are used as a
> literal in the FLEXJS_CLASS_INFO and thus never get minified/renamed.
>
> Anyway, try compiling and running your application code with this option
> set to false and see if it obfuscates things enough or not, and whether
> the result still runs.
>
> Thanks,
> -Alex
>
> On 8/7/17, 9:06 AM, "Alex Harui"  wrote:
>
> >From the output side, it probably isn't hard, but there is no way succinct
> >way to tell the compiler which classes should use @export or not.  You
> >could annotate the class definitions, but then you can't choose to output
> >@export without changing source.
> >
> >Why do you think we need per-class control over this output?
> >
> >-Alex
> >
> >On 8/7/17, 8:54 AM, "Harbs"  wrote:
> >
> >>Cool.
> >>
> >>How difficult would it be to allow this on a class-by-class basis?
> >>
> >>> On Aug 7, 2017, at 6:35 PM, Alex Harui 
> >>>wrote:
> >>>
> >>> First thing I will do, though, is allow turning off @export output on
> >>> entire compiler sessions.  That might allow you to have your text
> >>>engine
> >>> and your application logic more aggressively renamed but not require us
> >>>to
> >>> fix code in other SWCs that might use bracket access.
> >>
> >
>
>

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

[Greg Dove]

I assume it is if (unknownNumOrNaN != unknownNumOrNaN )

I have used things like if (unknownNumOrNaN *0 !=0) in the past but the
above seems better


On Thu, Aug 3, 2017 at 6:20 PM, Harbs <harbs.li...@gmail.com> wrote:

> I’m curious. How does that work?
> unknownNumOrNaN != NaN will always be true
>
> > On Aug 3, 2017, at 1:37 AM, Josh Tynjala <joshtynj...@gmail.com> wrote:
> >
> > Good one! To avoid the overhead of the isNaN() function call, I
> frequently
> > rely on the fact that NaN != NaN.
> >
> > - Josh
> >
> > On Wed, Aug 2, 2017 at 3:32 PM, Harbs <harbs.li...@gmail.com> wrote:
> >
> >> Thanks for the history lesson. :-)
> >>
> >> This does bring up another difference between an initialized value of
> NaN
> >> and undefined:
> >>
> >> NaN != NaN, while undefined == undefined
> >>
> >>> On Aug 3, 2017, at 1:00 AM, Dave Fisher <dave2w...@comcast.net> wrote:
> >>>
> >>> I hate this Macbook’s touch top bar which puts a send button directly
> >> above the delete key.
> >>>
> >>>> On Aug 2, 2017, at 2:50 PM, Dave Fisher <dave2w...@comcast.net>
> wrote:
> >>>>
> >>>> Hi Folks,
> >>>>
> >>>> A peanut gallery look at NaN which is really a bit encoding for
> various
> >> kinds of floating point number errors like underflow, overflow, divided
> by
> >> 0, etc. In my Fortran past life we used XMISS as a special valu
> >>>
> >>> Value. Essentially undefined.
> >>>
> >>> IEEE had very particular definitions and Apple published a book about
> >> SANE.
> >>>
> >>> At any rate what you guys are observing is by design: NaN always
> results
> >> in false in any comparison. And it is a number. But it is not a number
> in
> >> floating point so much as it is an error condition.
> >>>
> >>> https://stackoverflow.com/questions/1565164/what-is-the-
> >> rationale-for-all-comparisons-returning-false-for-ieee754-nan-values
> >>>
> >>> https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
> >>>
> >>> My father complained about when the IBM 360 came out in the early
> 1960’s
> >> he had to go to doubles because the IBM architecture went from 6 - 6 bit
> >> words for a single to 4 - 8 bit words. The practical result was twice as
> >> much magnetic tape both length and number of reals.
> >>>
> >>> Regards,
> >>> Dave
> >>>
> >>>>
> >>>>> On Aug 1, 2017, at 3:21 PM, Greg Dove <greg.d...@gmail.com> wrote:
> >>>>>
> >>>>> Yes it does. NaN is an 'instance' of the Number type (even though it
> is
> >>>>> 'Not a Number' ;)  )
> >>>>>
> >>>>>
> >>>>> On Wed, Aug 2, 2017 at 10:18 AM, Harbs <harbs.li...@gmail.com>
> wrote:
> >>>>>
> >>>>>> Interesting.
> >>>>>>
> >>>>>> I’m not sure that I realized that NaN passes that test. Does it?
> >>>>>>
> >>>>>>> On Aug 2, 2017, at 1:12 AM, Greg Dove <greg.d...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> I agree undefined works the same as NaN for many things for
> example,
> >> but
> >>>>>> it
> >>>>>>> fails on very basic things like if (x is Number)
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> >>
>
>

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

[Greg Dove]

s,
> > -Alex
> >
> > On 8/1/17, 8:48 PM, "Harbs" <harbs.li...@gmail.com> wrote:
> >
> >> What I mean is that if we can somehow have the values uninitialized in
> >> JS, but in all cases where uninitialized values somehow diverge with
> >> ActionScript behavior be solved (so the use cases would behave
> >> correctly), then we’d have the advantages of undefined together with
> >> expected AS behavior.
> >>
> >> I don’t know that this is possible, but that would be ideal in my book.
> >>
> >> If that’s not possible, then yes, I agree that two compiler options is
> >> the best we can do.
> >>
> >> Hope that’s clearer,
> >> Harbs
> >>
> >>> On Aug 2, 2017, at 1:49 AM, Greg Dove <greg.d...@gmail.com> wrote:
> >>>
> >>> I’d prefer if we could somehow get the best of both worlds.
> >>>
> >>> Sorry Harbs, but I don't get it. I think the agreement is already to
> >>> 'have
> >>> the best of both worlds'.
> >>> The issue is what the default should be. I know that you don't think
> you
> >>> could have both behaviours as the default :).
> >>>
> >>> If we take away personal preferences, and think in terms of where
> >>> developers will be coming from for FlexJS, and if we assume that this
> >>> includes a large proportion of people who are already familiar with
> >>> actionscript and therefore have expectations based on that familiarity,
> >>> then I don't see how having default behaviour that is different to
> those
> >>> expectations will be helpful to the uptake in use of flexjs.
> >>>
> >>> If it is not the case then we need to have documentation that supports
> >>> the
> >>> divergence from official actionscript language documentation elsewhere,
> >>> and
> >>> the hope that new users will read it as the authoritative source.
> >>>
> >>>
> >>> On Wed, Aug 2, 2017 at 10:31 AM, Harbs <harbs.li...@gmail.com> wrote:
> >>>
> >>>> I’d prefer if we could somehow get the best of both worlds.
> >>>>
> >>>> I don’t see a solution to that dilemma at the moment, but maybe we’ll
> >>>> come
> >>>> up with something...
> >>>>
> >>>> Harbs
> >>>>
> >>>>> On Aug 2, 2017, at 1:24 AM, Josh Tynjala <joshtynj...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> Don't get me wrong. If you see value in it, then we definitely
> >>>>> shouldn't
> >>>>> remove it as an option. However, for compatibility with the existing
> >>>>> language, I'd prefer to see initialization be the default instead.
> >>>>>
> >>>>> - Josh
> >>>>>
> >>>>> On Tue, Aug 1, 2017 at 3:14 PM, Harbs <harbs.li...@gmail.com> wrote:
> >>>>>
> >>>>>> Any maybe vice versa... ;-p
> >>>>>>
> >>>>>> Alex was planning on looking into whether he can solve the boolean
> >>>>>> problem, so let’s hold off until he does that.
> >>>>>>
> >>>>>> I think comparing two booleans is pretty rare although I have
> already
> >>>> run
> >>>>>> into if(myBool == false) not working. Changing it to if(!myBool) was
> >>>> simple
> >>>>>> enough, but I do agree with you that it’s currently broken.
> >>>>>>
> >>>>>> For now, we’re going to have to agree to disagree on initializing
> >>>> values.
> >>>>>> I’ve seen a lot of value in leaving them undefined. It makes it
> >>>>>> really
> >>>>>> clear while debugging whether the value has been set or not.
> >>>>>>
> >>>>>> Harbs
> >>>>>>
> >>>>>>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <joshtynj...@gmail.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>> Maybe I'll convince others eventually.
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >
>
>

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

[Greg Dove]

I’d prefer if we could somehow get the best of both worlds.

Sorry Harbs, but I don't get it. I think the agreement is already to 'have
the best of both worlds'.
The issue is what the default should be. I know that you don't think you
could have both behaviours as the default :).

If we take away personal preferences, and think in terms of where
developers will be coming from for FlexJS, and if we assume that this
includes a large proportion of people who are already familiar with
actionscript and therefore have expectations based on that familiarity,
then I don't see how having default behaviour that is different to those
expectations will be helpful to the uptake in use of flexjs.

If it is not the case then we need to have documentation that supports the
divergence from official actionscript language documentation elsewhere, and
the hope that new users will read it as the authoritative source.


On Wed, Aug 2, 2017 at 10:31 AM, Harbs  wrote:

> I’d prefer if we could somehow get the best of both worlds.
>
> I don’t see a solution to that dilemma at the moment, but maybe we’ll come
> up with something...
>
> Harbs
>
> > On Aug 2, 2017, at 1:24 AM, Josh Tynjala  wrote:
> >
> > Don't get me wrong. If you see value in it, then we definitely shouldn't
> > remove it as an option. However, for compatibility with the existing
> > language, I'd prefer to see initialization be the default instead.
> >
> > - Josh
> >
> > On Tue, Aug 1, 2017 at 3:14 PM, Harbs  wrote:
> >
> >> Any maybe vice versa... ;-p
> >>
> >> Alex was planning on looking into whether he can solve the boolean
> >> problem, so let’s hold off until he does that.
> >>
> >> I think comparing two booleans is pretty rare although I have already
> run
> >> into if(myBool == false) not working. Changing it to if(!myBool) was
> simple
> >> enough, but I do agree with you that it’s currently broken.
> >>
> >> For now, we’re going to have to agree to disagree on initializing
> values.
> >> I’ve seen a lot of value in leaving them undefined. It makes it really
> >> clear while debugging whether the value has been set or not.
> >>
> >> Harbs
> >>
> >>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala 
> wrote:
> >>>
> >>> Maybe I'll convince others eventually.
> >>
> >>
>
>

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

[Greg Dove]

Yes it does. NaN is an 'instance' of the Number type (even though it is
'Not a Number' ;)  )


On Wed, Aug 2, 2017 at 10:18 AM, Harbs <harbs.li...@gmail.com> wrote:

> Interesting.
>
> I’m not sure that I realized that NaN passes that test. Does it?
>
> > On Aug 2, 2017, at 1:12 AM, Greg Dove <greg.d...@gmail.com> wrote:
> >
> > I agree undefined works the same as NaN for many things for example, but
> it
> > fails on very basic things like if (x is Number)
>
>

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

[Greg Dove]

Maybe I'll convince others eventually.

fwiw Josh, I agree with you.

I agree undefined works the same as NaN for many things for example, but it
fails on very basic things like if (x is Number)  that to me is quite
wrong and would be quite unexpected for anyone expecting flexjs
actionscript to behave like regular actionscript.
Perhaps there are ways to optimize it out in the compiler or GCL, but until
that happens I personally think the defaults should be actionscript
compatibility.




On Wed, Aug 2, 2017 at 9:54 AM, Josh Tynjala  wrote:

> I think if booleans could fail even non-strict equality checks when they
> are not initialized, then we should always initialize booleans, like we
> currently do with int and uint. It doesn't even make sense to make it an
> option for booleans, if that's the case. It's just broken.
>
> I would still like the see the compiler initialize everything by default so
> that ActionScript behaves like ActionScript. I think we're making a mistake
> by making non-initialization the default. Maybe I'll convince others
> eventually.
>
> - Josh
>
> On Tue, Aug 1, 2017 at 11:09 AM, Harbs  wrote:
>
> > One suggestion on this:
> >
> > Instead of making it a simple true/false, I’d suggest a tristate control
> > of true/false/booleans.
> >
> > The reason I’m making that suggestion is because even without strict
> > equality, setting booleans to false has the benefit that bool1 == bool2
> > will work as expected where undefined might not.
> >
> > FWIW, I have discovered that undefined for Numbers generally behaves the
> > same as NaN. I have also discovered that it’s very useful to NOT
> initialize
> > Numbers. Most NaN math errors I get are due to math with numbers which
> have
> > not been properly initialized. Anytime I get an unexpected NaN value,
> I’ve
> > found it’s very easy to walk up the stack trace to discover where math
> has
> > been done with an undefined value which basically without fail exposes
> the
> > bug. Initializing the values to NaN would mask the issues and make them
> > harder to find.
> >
> > My $0.02,
> > Harbs
> >
> > > On Aug 1, 2017, at 1:02 AM, joshtynj...@apache.org wrote:
> > >
> > > Repository: flex-falcon
> > > Updated Branches:
> > >  refs/heads/develop b04074bf0 -> c500b3fe5
> > >
> > >
> > > compiler-jx: Added -js-default-initializers option to force
> > uninitialized variables to default to the same values in JS as they do in
> > SWF.
> > >
> > > -js-default-initializers defaults to false and is completely optional,
> > but may be useful for porting SWF projects to JS if an existing codebase
> > uses strict equality and relies on the SWF default initializers.
> > >
> > >
> > > Project: http://git-wip-us.apache.org/repos/asf/flex-falcon/repo
> > > Commit: http://git-wip-us.apache.org/repos/asf/flex-falcon/commit/
> > c500b3fe
> > > Tree: http://git-wip-us.apache.org/repos/asf/flex-falcon/tree/c500b3fe
> > > Diff: http://git-wip-us.apache.org/repos/asf/flex-falcon/diff/c500b3fe
> > >
> > > Branch: refs/heads/develop
> > > Commit: c500b3fe52299272dbf201033723296057c79413
> > > Parents: b04074b
> > > Author: Josh Tynjala 
> > > Authored: Mon Jul 31 14:47:24 2017 -0700
> > > Committer: Josh Tynjala 
> > > Committed: Mon Jul 31 14:54:24 2017 -0700
> > >
> > > --
> > > .../flex/compiler/clients/JSConfiguration.java  | 19 ++
> > > .../codegen/js/jx/VarDeclarationEmitter.java| 61
> > 
> > > 2 files changed, 68 insertions(+), 12 deletions(-)
> > > --
> > >
> > >
> > > http://git-wip-us.apache.org/repos/asf/flex-falcon/blob/
> > c500b3fe/compiler-jx/src/main/java/org/apache/flex/compiler/
> > clients/JSConfiguration.java
> > > --
> > > diff --git a/compiler-jx/src/main/java/org/apache/flex/compiler/
> clients/JSConfiguration.java
> > b/compiler-jx/src/main/java/org/apache/flex/compiler/
> > clients/JSConfiguration.java
> > > index ab1c73c..9f6bbe9 100644
> > > --- a/compiler-jx/src/main/java/org/apache/flex/compiler/
> > clients/JSConfiguration.java
> > > +++ b/compiler-jx/src/main/java/org/apache/flex/compiler/
> > clients/JSConfiguration.java
> > > @@ -118,6 +118,25 @@ public class JSConfiguration extends Configuration
> > > }
> > >
> > > //
> > > +// 'js-default-initializers'
> > > +//
> > > +
> > > +private boolean jsDefaultInitializers = false;
> > > +
> > > +public boolean getJsDefaultInitializers()
> > > +{
> > > +return jsDefaultInitializers;
> > > +}
> > > +
> > > +@Config
> > > +@Mapping("js-default-initializers")
> > > +public void setJsDefaultInitializers(ConfigurationValue cv,
> > boolean value)
> > > +throws ConfigurationException
> > > +{
> > > +

Re: PAYG

[Greg Dove]

Josh, that was the general idea with the wiki docs:

-One section for 'definitions'

-And another section for examples/archetypes with advantages/disadvantages
of each - as a form of 'guidance', emphasis on the practical, but not a
proscriptive approach.

I'm sorry I have not had time to come back and consolidate the various
discussions on this. I still have that intention, just not the time
available right now. Please do not hesitate if you want to kick this off in
the wiki yourself.




On Tue, Jul 25, 2017 at 9:44 AM, Josh Tynjala  wrote:

> Okay, so PAYG can't have One True Definition. How you implement PAYG
> depends on context.
>
> I wonder if some kind of PAYG pattern cookbook would be helpful? I was
> thinking that our situations with PAYG remind me of software design
> patterns. Design patterns aren't really defined with an exact
> implementation, but they offer guidance for how you can solve problems of a
> certain category. With PAYG, I think we're going to have different
> categories that will need similar implementations, but not exactly the
> same. That's where PAYG patterns could help provide a framework for
> implementation.
>
> Let's find common patterns. Maybe even give them names to make them
> memorable and easy to refer to.
>
> - Josh
>
> On Thu, Jul 13, 2017 at 10:42 AM, Alex Harui 
> wrote:
>
> > Hi,
> >
> > I promised some feedback on Greg's PAYG page.  After thinking about it
> > some more, I'm proposing my take on it below.  I know past discussion
> > tried to break off component set definitions from PAYG, but I think PAYG
> > is always going to be subjective enough that the goals of the various
> > component sets will affect decisions about what goes in the default
> beads.
> >  I can't say this often enough though:  one main goal of beads is to
> avoid
> > spending energy on what is the one right way, and also, on exactly what
> > PAYG means.  If you don't agree with what PAYG means to the others
> working
> > on a component set, go start a new component set.
> >
> > So, I am going to try to discuss all of the related factors in one place
> > below.
> >
> > Thanks,
> > -Alex
> >
> > --- Pay-as-you-go (PAYG) ---
> >
> >
> > PAYG means that Download Size, Startup Time, Memory Usage, Line of Code
> > goes up and Performance goes down as new features are added to the
> > Application.
> >
> > PAYG leverages well-known computer science principles:  Re-usable code,
> > Separation of Concerns, Modularity, Abstraction.
> >
> > PAYG cannot be defined objectively.  You can be too granular or not
> > granular enough.
> > Too Much:  Put a for loop in a re-usable function.  Everybody must call
> > this function.
> > Too Little:  Regular Flex SDK.  13,000 line base classes.
> > Just Right:  Make it possible that an application has no unused code
> paths
> > in the framework code it uses.  IOW, no just-in-case code.
> >
> > FlexJS uses modules called "Beads" to implement features in a PAYG
> > fashion.  Beads are placed on Strands so composition is primary pattern.
> >
> > PAYG has no required implementation patterns.  There is no one right way.
> > Subclassing, sharing utility functions, beads sharing other beads are all
> > valid implementations.  The key is to see how it measures up against the
> > metrics of Download Size, Startup Time, Memory Usage, etc.  Other
> > computer-science principles like DRY should be considered as well.  There
> > doesn't have to be only one version of a bead.  There can be beads with
> > different implementations and tradeoffs on those metrics.
> >
> > ---Additional Guidelines for FlexJS---
> >
> > Naming:  Pick a relatively small/simple set of features that are likely
> to
> > be used in several applications.Give it a name starting with Simple,
> > or something descriptive and well-known like Panel.  Additional features
> > expand the name with prefixes (DropDownList instead of ListForDropDown)
> or
> > suffixes like PanelWithControlBar.  Reduced/inlined versions will also
> get
> > expanded names.
> >
> > Defensive Code:  Rarely needed.  Bad inputs should be found and fixed
> > before deploying the app.  Folks who take the time to do that should be
> > rewarded with smaller code and faster performance.  Use of goog.DEBUG to
> > have debug-time input checking is allowed.  There is a trade-off between
> > any performance hit of debug-time checking vs the developer productivity
> > of having those errors caught early.
> >
> > Bead Removal:  We may someday decide that beads should almost never be
> > removed.  Implementing a flag to disable a bead might be cheaper than
> > removing it.
> >
> > Component Sets:  Different component sets have different goals.
> >   Basic:  smallest SWF-equivalent implementations
> >   Express:  Pre-package Basic beads and thus SWF-equivalent
> >   MDL:  No interest in SWF equivalence.
> >
> > JS metrics are more important than SWF metrics.
> >
> >
> >
>

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Greg Dove]

Harbs I think that jsfiddle is not working because of the missing quotes in
the bracket access.

There are a bunch of uses of the bracket access throughout the framework,
including, iirc, some things like ['flex-basis'] etc.

imo, I agree these should be using the javascript camel case properties,
but perhaps we need to do a sweep through all the code for that.





On Fri, Jul 14, 2017 at 10:11 AM, Harbs  wrote:

> I’m not understanding. What worked and what didn’t?
>
> In this fiddle: https://jsfiddle.net/Harbs/9c8zezx5/ <
> https://jsfiddle.net/Harbs/9c8zezx5/>
>
> You should get an alert when clicking on every div except div1 (the top
> left one). Are you seeing something different?
>
> > On Jul 14, 2017, at 12:52 AM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> >> IIRC, style["pointer-events"] works in some browsers but not all.
> >
> > I tests on Firefox, Safari and Chrome on OSX and in all cases this
> failed to work:
> >
> > style.pointerEvents = "none”;
> >
> > and the other two styles did work.
> >
> > Perhaps it’s different on windows?
> >
> > Thanks,
> > Justin
>
>

Re: [FlexJS] Bindable and consts

[Greg Dove]

I have a vague recollection of needing some deprecated annotation @expose
for static accessors to work in the past because @export did not work.
Maybe it was related?

-Greg
[sent from my phone]

On 13/07/2017 6:24 PM, "Alex Harui"  wrote:

Well, I looked into this and this definitely falls into the category of
"how did this ever work?"

The use of [] access is on purpose.  When you use [Bindable], everything
becomes a getter (and setter if writable) and for statics we have to use
[] access to deal with GCC renaming.  See this background thread if you're
interested [1]

The reason it didn't work was that a FlexJS class had an exportSymbol near
the end of the file, but other methods and variables earlier in the file
with @export where being exported before the class's exportSymbol got
called.  This meant that the export logic would build up a plain object of
the @exports then the exportSymbol would wipe that out by replacing that
plain object with a reference to the class.

I moved the exportSymbol earlier in the file and things seem to work.  But
I think this means that any access of static getters never worked before!?

-Alex

[1]
https://lists.apache.org/thread.html/9802158cb9bf3b3737d7841ff950130d8e7a6e
10f563e1775aca3b5b@%3Cdev.flex.apache.org%3E



On 7/10/17, 9:22 AM, "Harbs"  wrote:

>Not urgent right now. Once I figured out what the problem was, I removed
>the Bindable tag. It was not strictly necessary.
>
>In my case the public static const was not exported. Not sure why.
>
>I’m not sure that we always want to export these things either, but
>that’s a whole ‘nother discussion that I keep putting off until we’re in
>a better place.
>
>Harbs
>
>> On Jul 10, 2017, at 6:54 PM, Alex Harui 
>>wrote:
>>
>> How urgent is this?  I'm trying to figure out why the compiler did not
>> respond properly to bad MXML.
>>
>> I thought public APIs were all exported so they would survive getting
>> renamed.  In the minified JS, the code will often access the renamed
>> variable, but a tree of objects with properties also gets created.
>>
>> -Alex
>>
>> On 7/10/17, 2:12 AM, "Harbs"  wrote:
>>
>>> It appears that this is the case with any public static getter.
>>>
>>> public static function get FOO():String{return “foo”}
>>> or
>>> public static function get FOO():Foo{return _foo}
>>>
>>> I don’t see any reason why bracket notation would be needed. Is this a
>>> throwback from before we had the get__ functions?
>>>
>>> Thanks,
>>> Harbs
>>>
 On Jul 9, 2017, at 11:27 PM, Harbs  wrote:

 I just discovered something:

 Foo.as:
 package com.acme.foobaz.model{
[Bindable]public class Foo{
static public const BAZ:String = “baz”;
}
 }

 In some other class:

 if(baz == Foo.BAZ){//do something}

 compiles to:
 if(baz == com.acme.foobaz.model.Foo[“BAZ”])

 If you remove the [Bindable] meta tag on the Foo class, it compiles
to:
 if(baz == com.acme.foobaz.model.Foo.BAZ)

 In the debug build, these two are functionally identical. However,
when
 Google minifies the file, it has no way of knowing that Foo.BAZ is
used.
 This results in calling  (assuming com.acme.foobaz.model.Foo becomes
k)
 k.BAZ even though k.BAZ was optimized away and k.BAZ is undefined.

 Why does [Bindable] on a class cause the bracket notation to be used?

 Harbs
>>>
>>
>

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

[Greg Dove]

Reflection support was opt-in.  Hopefully it still is.  As in, if your app
doesn't call any code that uses the reflection data structures they are
not in the minified output.

I had not realised that (nor had I checked), that sounds great.


On Wed, Jul 12, 2017 at 5:20 PM, Alex Harui <aha...@adobe.com.invalid>
wrote:

> Reflection support was opt-in.  Hopefully it still is.  As in, if your app
> doesn't call any code that uses the reflection data structures they are
> not in the minified output.
>
> DataBinding in general requires exports.  Any use of bracket access does
> as well.  But yes, I believe a smarter compiler can reduce the number of
> exports.
>
> I'm pretty sure --generate_exports is required to turn our @export
> notation into symbols in the minified output.  But the main app has a
> generated exportSymbol call so --generate_exports will not always be
> required for FlexJS.
>
> Again, though, I think this optimization isn't urgent.
>
> goog.DEBUG is already being used in Language.as.
>
> -Alex
>
> On 7/11/17, 4:01 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >I'll try those things, I have not tried any of those options so far.
> >
> >Future need to support modules has been mentioned as a reason for keeping
> >@export before.
> >
> >Another is to support reflection (in its current form). Reflection support
> >probably needs to be opt-in, I think this has been discussed before also.
> >
> >Perhaps another in this case might be to support constant bindings.
> >This is one area that could probably benefit from jx-compiler optimisation
> >for primitive constant lookups - iirc I *think* that constant bindings are
> >still happening via bracket access, and probably could simply be replaced
> >by the literal values for string, number etc.
> >
> >
> >
> >
> >On Wed, Jul 12, 2017 at 9:57 AM, Harbs <harbs.li...@gmail.com> wrote:
> >
> >> Hi Greg,
> >>
> >> There probably is too much use of @export. @const is probably more
> >>correct
> >> than @export — as long as we are sure that there’s no use of bracket
> >> notation anywhere. I’d be interested in hearing your findings.
> >>
> >> Personally, I’m not sure there’s a lot of value to be using @export at
> >>all
> >> unless an app is using modules of some sort (which I’m not even sure
> >>how to
> >> do with FlexJS). (but I might be missing something with the @export tag)
> >>
> >> What happens if the compiler is run without --generate_exports? Do the
> >> @exports get stripped out? If yes, is there some kind of “super export”?
> >> There needs to be some way to invoke the app…
> >>
> >> Harbs
> >>
> >> > On Jul 11, 2017, at 11:40 PM, Greg Dove <greg.d...@gmail.com> wrote:
> >> >
> >> > Guys, we certainly have been here before.
> >> >
> >> > From a js release 'size' perspective, I don't think it matters
> >>whether we
> >> > use constants or liteterals, I think the main difference is that if
> >>the
> >> > static const exists it will also be included in the release output as
> >>I
> >> > expect it has an @export annotation. This means it should be
> >> 'reflectable'
> >> > via array/bracket access syntax via its original package/class naming.
> >> But
> >> > in terms of usage sites within the codebase, it should already be
> >> optimised
> >> > via GCC, becuase GCC is already capable of inlining anything annotated
> >> as a
> >> > constant [1].
> >> > So I would expect it to already be inlined in the js-release, and we
> >> > *should not need* to write any code in the jx compiler to do that,
> >>unless
> >> > we specifically need this inlining (for some reason) in the debug
> >>version
> >> > of the js output.
> >> >
> >> > GCC also creates a single short named variable to refer to repeated
> >> > literals througout the compiled codebase, so I would expect the
> >>inlining
> >> of
> >> > consts would get this as a 2nd optimization pass as well. In the end I
> >> > expect the only output difference between the two approaches should be
> >> that
> >> > we also get an extra exported constant that retains the same naming
> >> > convention of lookups etc because we are @export-ing it.
> >> >
> >> > I'm pretty sure this is correct, but I might be wrong. I will check
> &

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

[Greg Dove]

I'll try those things, I have not tried any of those options so far.

Future need to support modules has been mentioned as a reason for keeping
@export before.

Another is to support reflection (in its current form). Reflection support
probably needs to be opt-in, I think this has been discussed before also.

Perhaps another in this case might be to support constant bindings.
This is one area that could probably benefit from jx-compiler optimisation
for primitive constant lookups - iirc I *think* that constant bindings are
still happening via bracket access, and probably could simply be replaced
by the literal values for string, number etc.




On Wed, Jul 12, 2017 at 9:57 AM, Harbs <harbs.li...@gmail.com> wrote:

> Hi Greg,
>
> There probably is too much use of @export. @const is probably more correct
> than @export — as long as we are sure that there’s no use of bracket
> notation anywhere. I’d be interested in hearing your findings.
>
> Personally, I’m not sure there’s a lot of value to be using @export at all
> unless an app is using modules of some sort (which I’m not even sure how to
> do with FlexJS). (but I might be missing something with the @export tag)
>
> What happens if the compiler is run without --generate_exports? Do the
> @exports get stripped out? If yes, is there some kind of “super export”?
> There needs to be some way to invoke the app…
>
> Harbs
>
> > On Jul 11, 2017, at 11:40 PM, Greg Dove <greg.d...@gmail.com> wrote:
> >
> > Guys, we certainly have been here before.
> >
> > From a js release 'size' perspective, I don't think it matters whether we
> > use constants or liteterals, I think the main difference is that if the
> > static const exists it will also be included in the release output as I
> > expect it has an @export annotation. This means it should be
> 'reflectable'
> > via array/bracket access syntax via its original package/class naming.
> But
> > in terms of usage sites within the codebase, it should already be
> optimised
> > via GCC, becuase GCC is already capable of inlining anything annotated
> as a
> > constant [1].
> > So I would expect it to already be inlined in the js-release, and we
> > *should not need* to write any code in the jx compiler to do that, unless
> > we specifically need this inlining (for some reason) in the debug version
> > of the js output.
> >
> > GCC also creates a single short named variable to refer to repeated
> > literals througout the compiled codebase, so I would expect the inlining
> of
> > consts would get this as a 2nd optimization pass as well. In the end I
> > expect the only output difference between the two approaches should be
> that
> > we also get an extra exported constant that retains the same naming
> > convention of lookups etc because we are @export-ing it.
> >
> > I'm pretty sure this is correct, but I might be wrong. I will check all
> > this later today, and report back.
> >
> > 1.
> > https://github.com/google/closure-compiler/wiki/
> Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
> >
> >
> >
> > On Wed, Jul 12, 2017 at 3:47 AM, Harbs <harbs.li...@gmail.com> wrote:
> >
> >> +1.
> >>
> >> I also think that we have bigger fish to fry first.
> >>
> >> My point was not to force one way or the other. Rather that the way it
> >> currently stands there’s a valid reason to use string literals. I was
> not
> >> suggesting changing anything.
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <joshtynj...@gmail.com>
> wrote:
> >>>
> >>> That sounds like the proper way to handle this! We should be able to
> >>> reference constants in our ActionScript so that we can get compile-time
> >>> errors from typos, while the compiler makes sure that generated
> >> JavaScript
> >>> can be properly minified.
> >>>
> >>> - Josh
> >>>
> >>> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <aha...@adobe.com.invalid>
> >>> wrote:
> >>>
> >>>> AIUI, there is a cost in the minified JS to using constants.
> >>>>
> >>>> However, there is a cost to screwing up the typing of a string literal
> >> as
> >>>> well.
> >>>>
> >>>> The best answer for now, IMO, is to not care whether folks use
> constants
> >>>> or string literals.  There are much bigger fish to fry.  I don't want
> to
> >>>> see sweeping changes of 

Re: [FlexJS]Runtime type checking and PAYG

[Greg Dove]

In application development I would normally do this type of thing inside
CONFIG::dev
blocks, or similar, so having the possibility, as described, to exclude
development-only code (extra type checking, null checks etc) would
definitely also be helpful PAYG-wise from within the framework.

The general issue here I think is that using this approach for the
framework requires a dev build of the framework and a separate
produciton-ready build, so the approach of using GCC to avoid this via
annotations sounds like a great solution to that. I don't know how we could
do this on the swf side though without having two framework builds?

btw React/React-Native has something like this as well iirc, including
removal of a bunch of runtime type-checking support in the release builds,
so having something like this seems like it would be a good thing to for
comparison with others.

I terms of the 'type check' in this case, personally I think it could be as
simple as

ba = bytes ? bytes as ArrayBuffer : new ArrayBuffer(0);
if (bytes && !ba) throw new Error('unexpected constructor argument type');

I think that could be used for both swf and js.



On Wed, Jul 12, 2017 at 8:56 AM, Alex Harui 
wrote:

> I've mentioned the notion of debug-mode beads on the mailing list a couple
> of times.  It would be great to see this idea explored more.
>
> By definition, now that you've debugged your code, any type-checking code
> path becomes unused in production, which is what we don't want.  But
> adding code paths that go away in production, or swapping in different
> beads during development that have more code paths that check for common
> mistakes is certainly within the charter.  We want to maximize developer
> productivity.
>
> I think Google Closure Compiler supports a debug flag you can use in
> COMPILE::JS blocks that gets dropped in production.  If we need to mimic a
> similar flag for SWF so code can compile outside of COMPILE::JS blocks
> that might be ok.
>
> -Alex
>
> On 7/11/17, 1:07 PM, "Harbs"  wrote:
>
> >I just wasted over an hour because I was initializing a BinaryData with a
> >string instead of an ArrayBuffer.
> >
> >I would like to add a typecheck to the bytes argument in the BinaryData
> >constructor to throw an error if something other than an ArrayBuffer is
> >provided. We cannot use strict typing to catch this in the compiler,
> >because the argument is different for SWF and JS. Is this a violation of
> >PAYG? It’s sort-of just in case code, but not really because it’s
> >protecting against errors.
> >
> >Thoughts? Other solutions?
> >Harbs
>
>

Re: [FlexJS]Runtime type checking and PAYG

[Greg Dove]

oops, that last idea won't work so well with  @flexjsignorecoercion
ArrayBuffer above it :)

On Wed, Jul 12, 2017 at 9:54 AM, Greg Dove <greg.d...@gmail.com> wrote:

>
> In application development I would normally do this type of thing inside
> CONFIG::dev
> blocks, or similar, so having the possibility, as described, to exclude
> development-only code (extra type checking, null checks etc) would
> definitely also be helpful PAYG-wise from within the framework.
>
> The general issue here I think is that using this approach for the
> framework requires a dev build of the framework and a separate
> produciton-ready build, so the approach of using GCC to avoid this via
> annotations sounds like a great solution to that. I don't know how we could
> do this on the swf side though without having two framework builds?
>
> btw React/React-Native has something like this as well iirc, including
> removal of a bunch of runtime type-checking support in the release builds,
> so having something like this seems like it would be a good thing to for
> comparison with others.
>
> I terms of the 'type check' in this case, personally I think it could be
> as simple as
>
> ba = bytes ? bytes as ArrayBuffer : new ArrayBuffer(0);
> if (bytes && !ba) throw new Error('unexpected constructor argument type');
>
> I think that could be used for both swf and js.
>
>
>
> On Wed, Jul 12, 2017 at 8:56 AM, Alex Harui <aha...@adobe.com.invalid>
> wrote:
>
>> I've mentioned the notion of debug-mode beads on the mailing list a couple
>> of times.  It would be great to see this idea explored more.
>>
>> By definition, now that you've debugged your code, any type-checking code
>> path becomes unused in production, which is what we don't want.  But
>> adding code paths that go away in production, or swapping in different
>> beads during development that have more code paths that check for common
>> mistakes is certainly within the charter.  We want to maximize developer
>> productivity.
>>
>> I think Google Closure Compiler supports a debug flag you can use in
>> COMPILE::JS blocks that gets dropped in production.  If we need to mimic a
>> similar flag for SWF so code can compile outside of COMPILE::JS blocks
>> that might be ok.
>>
>> -Alex
>>
>> On 7/11/17, 1:07 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>> >I just wasted over an hour because I was initializing a BinaryData with a
>> >string instead of an ArrayBuffer.
>> >
>> >I would like to add a typecheck to the bytes argument in the BinaryData
>> >constructor to throw an error if something other than an ArrayBuffer is
>> >provided. We cannot use strict typing to catch this in the compiler,
>> >because the argument is different for SWF and JS. Is this a violation of
>> >PAYG? It’s sort-of just in case code, but not really because it’s
>> >protecting against errors.
>> >
>> >Thoughts? Other solutions?
>> >Harbs
>>
>>
>

Re: [FlexJS] Question about Events/possible bugs

[Greg Dove]

Thanks for the clarification, and for your fixes Harbs,

I will make the other changes to add the import to cover js build scope for
ApplicationBase and the two layout beads today.



On Tue, Jul 11, 2017 at 4:40 AM, Josh Tynjala <joshtynj...@gmail.com> wrote:

> That sounds reasonable.
>
> - Josh
>
> On Mon, Jul 10, 2017 at 9:32 AM, Alex Harui <aha...@adobe.com.invalid>
> wrote:
>
> > Well, the goal is to not have the framework code use the native Event.
> > Maybe we should add a warning that we can turn on for our code but is off
> > by default.
> >
> > -Alex
> >
> > On 7/10/17, 8:52 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
> >
> > >This behavior is because the native HTML classes aren't in a package.
> The
> > >compiler treats everything that's not in a package the same as classes
> > >like
> > >Number, Boolean, and String, which you don't need to import.
> > >
> > >It seems potentially tricky to change this behavior, unless you have a
> > >whitelist. You wouldn't want to be forced to import Number, for
> instance.
> > >That would be a pretty drastic change from existing behavior.
> > >
> > >If you do happen to require imports for native HTML classes in the
> JSFlex
> > >target, I'd like to see the JS target keep treating them normally. The
> > >HTML
> > >classes should not need to be imported with the JS target.
> > >
> > >- Josh
> > >
> > >On Mon, Jul 10, 2017 at 8:40 AM, Alex Harui <aha...@adobe.com.invalid>
> > >wrote:
> > >
> > >> Yes, good catch.
> > >>
> > >> I'm wondering if the compiler should not auto-import native HTML
> > >>classes.
> > >>
> > >> -Alex
> > >>
> > >> On 7/10/17, 1:16 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> > >>
> > >> >Good catch.
> > >> >
> > >> >Without looking at them, I’d guess that they are bugs. Clipboard was
> my
> > >> >error and I just committed a fix for that.
> > >> >
> > >> >Thanks,
> > >> >Harbs
> > >> >
> > >> >> On Jul 10, 2017, at 11:06 AM, Greg Dove <greg.d...@gmail.com>
> wrote:
> > >> >>
> > >> >> I noticed a problem with VerticalFlexLayout in IE11 (and presumably
> > >> >>older
> > >> >> IE browsers).
> > >> >>
> > >> >> The JS output causing problems has
> > >> >>
> > >> >> child.dispatchEvent(new Event("layoutNeeded"));
> > >> >>
> > >> >> The reason is that the org.apache.flex.events.Event import is
> missing
> > >> >>from
> > >> >> the
> > >> >> COMPILE::JS build scope
> > >> >> So it is falling back to what I assume is the native html Event
> class
> > >> >>(via
> > >> >> externs)
> > >> >>
> > >> >> This works fine in Chrome, but not so in IE11.
> > >> >> Changing the actionscript source for VerticalFlexLayout to add
> > >> >> import  org.apache.flex.events.Event;
> > >> >>
> > >> >> to cover  javascript as welll as SWF, fixes the issue.
> > >> >>
> > >> >> I then unzipped all the JS swcs and file-searched in the js output
> > >>for
> > >> >>'new
> > >> >> Event'
> > >> >>
> > >> >> It looks like there are a total of 14 cases of output in the js
> which
> > >> >>are
> > >> >> new Event('something') instead of new
> > >> >> org.apache.flex.events.Event('something')
> > >> >>
> > >> >> These are in
> > >> >> org.apache.flex.core.ApplicationBase (x6)
> > >> >> org.apache.flex.svg.GraphicContainer (x3)
> > >> >> org.apache.flex.html.beads.layouts.VerticalFlexLayout (x1)
> > >> >> org.apache.flex.html.beads.layouts.HorizontalFlexLayout (x1)
> > >> >> org.apache.flex.textLayout.edit.Clipboard (x3)
> > >> >>
> > >> >> I suspect these are import omissions that may cause bugs (perhaps
> > >>only
> > >> >>in
> > >> >> certain older browsers).
> > >> >> But thought I would check before doing any changes in case I am
> > >>missing
> > >> >> something that I don't understand about the events in js
> > >> >>
> > >> >> What do others think?
> > >> >
> > >>
> > >>
> >
> >
>

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

[Greg Dove]

Guys, we certainly have been here before.

>From a js release 'size' perspective, I don't think it matters whether we
use constants or liteterals, I think the main difference is that if the
static const exists it will also be included in the release output as I
expect it has an @export annotation. This means it should be 'reflectable'
via array/bracket access syntax via its original package/class naming. But
in terms of usage sites within the codebase, it should already be optimised
via GCC, becuase GCC is already capable of inlining anything annotated as a
constant [1].
So I would expect it to already be inlined in the js-release, and we
*should not need* to write any code in the jx compiler to do that, unless
we specifically need this inlining (for some reason) in the debug version
of the js output.

GCC also creates a single short named variable to refer to repeated
literals througout the compiled codebase, so I would expect the inlining of
consts would get this as a 2nd optimization pass as well. In the end I
expect the only output difference between the two approaches should be that
we also get an extra exported constant that retains the same naming
convention of lookups etc because we are @export-ing it.

I'm pretty sure this is correct, but I might be wrong. I will check all
this later today, and report back.

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



On Wed, Jul 12, 2017 at 3:47 AM, Harbs  wrote:

> +1.
>
> I also think that we have bigger fish to fry first.
>
> My point was not to force one way or the other. Rather that the way it
> currently stands there’s a valid reason to use string literals. I was not
> suggesting changing anything.
>
> Thanks,
> Harbs
>
> > On Jul 11, 2017, at 6:33 PM, Josh Tynjala  wrote:
> >
> > That sounds like the proper way to handle this! We should be able to
> > reference constants in our ActionScript so that we can get compile-time
> > errors from typos, while the compiler makes sure that generated
> JavaScript
> > can be properly minified.
> >
> > - Josh
> >
> > On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui 
> > wrote:
> >
> >> AIUI, there is a cost in the minified JS to using constants.
> >>
> >> However, there is a cost to screwing up the typing of a string literal
> as
> >> well.
> >>
> >> The best answer for now, IMO, is to not care whether folks use constants
> >> or string literals.  There are much bigger fish to fry.  I don't want to
> >> see sweeping changes of replacing all string literals with constants or
> >> vice versa.  If you've got that kind of time on your hands, learn the
> >> compiler code and see if you can make the cross-compiler replace all
> >> constants with string literals.  IMO, that's the right answer.
> >>
> >> -Alex
> >>
> >> On 7/11/17, 5:37 AM, "Harbs"  wrote:
> >>
> >>> Here’s what is output in the minimized code:
> >>>
> >>> function
> >>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
> >> w('org.apache.flex
> >>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
> >> HTTPConstants.PUT'
> >>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
> >> ENCODED',Fm);w('org.
> >>> apache.flex.net.HTTPConstants.DELETE','DELETE'
> >> );w('org.apache.flex.net.HTT
> >>> PConstants.OPEN','open');w('org.apache.flex.net.
> >> HTTPConstants.COMPLETE',Bt
> >>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
> >> ERROR',At);w('org.apa
> >>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
> >>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
> >> 'securityError');w('o
> >>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
> >> org.apache.flex.net.HTTPCo
> >>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
> >> prototype.h={names:[{na
> >>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
> >>>
> >>> elsewhere:
> >>> IF='org.apache.flex.net.HTTPConstants’,
> >>>
> >>> That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
> >>>
> >>> No idea what wiki you are referring to.
> >>>
> >>> Harbs
> >>>
>  On Jul 11, 2017, at 2:36 PM, Justin Mclean 
>  wrote:
> 
>  Hi,
> 
> > As it stands now, use of constants result in more JS code after
> > compiled.
> 
>  Debug yes but not optimised / release.
> 
> > It’s possible that this can be optimized, but currently the most
> > efficient JS code is produced if using string literals rather than
> > constants. (The Google compiler created variables for string literals
> > used more than once.)
> 
>  That's not we found in a previous thread on this list, the google
>  compiler optimises the constants and there is no penalty in using
> them.
>  You mind provide examples that show the above is the actually case and
>  document it on the wiki?
> 
>  My vote would be not the duplicate the strings 

[FlexJS] Question about Events/possible bugs

[Greg Dove]

I noticed a problem with VerticalFlexLayout in IE11 (and presumably older
IE browsers).

The JS output causing problems has

child.dispatchEvent(new Event("layoutNeeded"));

The reason is that the org.apache.flex.events.Event import is missing from
the
COMPILE::JS build scope
So it is falling back to what I assume is the native html Event class (via
externs)

This works fine in Chrome, but not so in IE11.
Changing the actionscript source for VerticalFlexLayout to add
import  org.apache.flex.events.Event;

to cover  javascript as welll as SWF, fixes the issue.

I then unzipped all the JS swcs and file-searched in the js output for 'new
Event'

It looks like there are a total of 14 cases of output in the js which are
new Event('something') instead of new
org.apache.flex.events.Event('something')

These are in
org.apache.flex.core.ApplicationBase (x6)
org.apache.flex.svg.GraphicContainer (x3)
org.apache.flex.html.beads.layouts.VerticalFlexLayout (x1)
org.apache.flex.html.beads.layouts.HorizontalFlexLayout (x1)
org.apache.flex.textLayout.edit.Clipboard (x3)

I suspect these are import omissions that may cause bugs (perhaps only in
certain older browsers).
But thought I would check before doing any changes in case I am missing
something that I don't understand about the events in js

What do others think?

Re: [FlexJS] question about porting an Adobe Flex 3 project to HTML+JS

[Greg Dove]

I took a quick look at SearchBox.mxml

there are at least some basic xml errors in it.

xmlns:ns="library://ns.apache.org/flexjs/svg> <- missing quote

 wrote:

> Allen,
>
> SearchBox.mxml - look good to me - of course if you have ISearchable - but
> I
> don't see it. Apart of that you have in this project file called
> "deallist.as" - which has a lot of old Flex classes - it's not going to
> build. Not sure what you wanted to achieve ?
>
> Thanks,
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-question-about-
> porting-an-Adobe-Flex-3-project-to-HTML-JS-tp62698p62999.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

RE: [FlexJS] question about porting an Adobe Flex 3 project to HTML+JS

[Greg Dove]

I just glanced back at your mxml. Not sure if this will help... but you
could try moving the fx:Script tag outside the HContainer tag so it is top
level inside your mxml. This seems more conventional although I am not sure
whether it is the cause of the compiler issues you are seeing or not.

-Greg
[sent from my phone]

On 9/07/2017 6:32 AM, "Allen YANG"  wrote:

Hi Alex,
I am leaving SearchBox.mxml compiler issue aside for now since I have no
idea how to solve it.
Following the MyInitialView.mxml example, I was finally able to convert a
Flex 3 MXML file called UpdateResources.mxml  which starts with
  and has a Canvas with HBox, VBox and Buttons inside.
The result is a very slimmed down version of FlexJS implementation which
starts with  and includes a  with HContainer,
VContainer, and TextButtons inside.  I lost most of the formatting of the
pages because many attributes are not there anymore.  Could you comment
whether that's about right, or I have completely got it wrong?
(The complied result could run but certainly I lost most of the original
UI's screen formatting due to many of the properties not being supported.)

Thanks and Regards,
Allen


-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID]
Sent: Saturday, July 08, 2017 10:42 AM
To: dev@flex.apache.org
Subject: Re: [FlexJS] question about porting an Adobe Flex 3 project to
HTML+JS

Hi Allen,

These are great questions.

Many examples have a MyInitialView.mxml file with js:View as the top tag.
You might want to refer to those examples.

The current Panel does have an optional close button so it can substitute
as TitleWindow, but I am currently refactoring it for 0.9.0 to be more
pay-as-you-go.

Unless you need more than one floating window, you shouldn't need
PopUpManager (which is why it doesn't exist in FlexJS yet).  Instead use
code like:

var host:IPopUpHost;
host = UIUtils.findPopUpHost(this); // this is the main view
IPopUpHost(host).addElement(popUp as IChild);

HGroup or HContainer can swap in for HBox.


Use Group or Container instead of Canvas.


Good luck,
-Alex

On 7/8/17, 6:00 AM, "Allen YANG"  wrote:

>Hi Yishay,
>You are right.  I rechecked the demo.zip file and panelview.as is not
>there. Maybe I was trying to learn about TitleWindow replacement and
>break the code into a separate file, ended up leaving it there.
>No luck yet in converting my MXML file for TitleWindow equivalent
>because it also has PopUpManager and uses HBox and Canvas in the same MXML
file.
>I cannot get a simple MXML file (less than 40 lines) to compile.
>
>I am confused why the same code compiles and works when it is part of
>the MXML file inside of  but when I tried to create a
>separate MXML file for a panel inside of a View it doesn't compile.
>In other words, 
>will be fine inside  but cannot be standalone. This must
>be another newbie question.
>Regards,
>Allen
>
>-Original Message-
>From: yishayw [mailto:yishayj...@hotmail.com]
>Sent: Saturday, July 08, 2017 4:58 AM
>To: dev@flex.apache.org
>Subject: RE: [FlexJS] question about porting an Adobe Flex 3 project to
>HTML+JS
>
>I don't see panelview.as in the sources. But anyway, I don't remember
>it being part of the demo so you can ignore it for now. Any luck with
>creating a TitleWindow equivalent?
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-
>fle
>x-development.247.n4.nabble.com%2FFlexJS-question-about-porting-an-
>Ado
>be-Flex-3-project-to-HTML-JS-tp62698p62960.html=02%7C01%7C%7C547b2
>515
>c4244d1105d608d4c6014a6d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
>363
>51156227326642=Vwy%2BU1qoAoMSD1R1jN3t%2BZLAjrCtOS1%2BMXjgdnWzUI8%
>3D&
>reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
>
>
>Ce message, ainsi que tous les fichiers joints à ce message, peuvent
>contenir des informations sensibles et/ ou confidentielles ne devant
>pas être divulguées. Si vous n'êtes pas le destinataire de ce message
>(ou que vous recevez ce message par erreur), nous vous remercions de le
>notifier immédiatement à son expéditeur, et de détruire ce message.
>Toute copie, divulgation, modification, utilisation ou diffusion, non
>autorisée, directe ou indirecte, de tout ou partie de ce message, est
>strictement interdite.
>
>
>This e-mail, and any document attached hereby, may contain confidential
>and/or privileged information. If you are not the intended recipient
>(or have received this e-mail in error) please notify the sender
>immediately and destroy this e-mail. Any unauthorized, direct or
>indirect, copying, disclosure, distribution or other use of the
>material or parts thereof is strictly forbidden.




Ce message, ainsi que tous les fichiers joints à ce message, peuvent
contenir des informations sensibles et/ ou confidentielles ne devant pas
être 

Re: [FlexJS] technical debt

[Greg Dove]

>> Well Object is always THE base class. It may not be known what the
actual base class should be and it is certainly not flexible to always
create a base class just to have a one to satisfy the rule.

>Nor would I suggest that. There are some cases where creating a new class
with properties is going to make sense, there other in where having the
flexibility of Object make sense. You may not be aware there a big
difference between Object and something that extends Object. Objects’s are
dynamic and properties (and methods) can be added at runtime but this comes
at a performance cost. Class that extend Object are not dynamic and you
can’t do this and as a result are faster.

>> Justin - If you have clear performance results then please document them
in the wiki.

>Other people have already researched this and it’s well known AFAIK. For
example here's an old article by Alex [1] where for accessing properties
there’s a 20x performance increase. Obviously there’s a little more to it
than just that but more recent article also have similar results. Object
can be useful but it does come at a performance cost.

I'm not sure if performance concern is a priority here or not, because
although it is important in AVM, it may not be relevant in the browser
where things are untyped in any case. I vaguely recall reading something in
another thread recently that left me with the impression that javascript
output was the priority (for performance, I think) and that the primary
objectives for swf were to achieve compatibility. I think this was in
relation to some view or layout code, but I do wonder if it is a general
'guidance' that would be relevant for things like this. If it is, it would
be good to document that as an explicit piece of guidance (if it is not
already stated somewhere).



On Fri, Jul 7, 2017 at 12:19 PM, Justin Mclean 
wrote:

> Hi,
>
> > That is the concern, but it may be that the developer was making a
> speculative change. If I were cleaning then I would do one of two actions.
> >
> > (a) Review the history of that change and see if the associated comments
> provide a reason.
> > (b) Ask the developer who made the change.
>
> Both are courses of action that I would take assuming the info in the VC
> comments and/or the developer is still about. Sometimes that may not be the
> case.
>
> > Well Object is always THE base class. It may not be known what the
> actual base class should be and it is certainly not flexible to always
> create a base class just to have a one to satisfy the rule.
>
> Nor would I suggest that. There are some cases where creating a new class
> with properties is going to make sense, there other in where having the
> flexibility of Object make sense. You may not be aware there a big
> difference between Object and something that extends Object. Objects’s are
> dynamic and properties (and methods) can be added at runtime but this comes
> at a performance cost. Class that extend Object are not dynamic and you
> can’t do this and as a result are faster.
>
> > Justin - If you have clear performance results then please document them
> in the wiki.
>
> Other people have already researched this and it’s well known AFAIK. For
> example here's an old article by Alex [1] where for accessing properties
> there’s a 20x performance increase. Obviously there’s a little more to it
> than just that but more recent article also have similar results. Object
> can be useful but it does come at a performance cost.
>
> > Thanks. Do you know how to deactivate useless rules?
>
> Yes.
>
> Thanks,
> Justin
>
> 1. http://blogs.adobe.com/aharui/2007/10/actionscript_
> readwrite_perform_1.html

Re: [FlexJS] PAYG definitions and guidance, Please participate

[Greg Dove]

Really pleased to see the input from you all, and thanks for the revisions
and corrections so far.

"To me it's a bit difficult to digest in its current format. I would prefer
to
see a list of design patterns with descriptions of concrete problems and
proposed solutions."

I definitely agree. I had already considered splitting it into two docs :
definitions and implementation guide, but it was mostly 'notes' to begin
with so I just kept them all in the one doc. I think we should split it out
like that once we agree that the definitions are solid, then we can focus
on the implementation guide, populating it with content from discussions
that have already begun, and then adding more in the future in exactly the
way ( PAYG-ish ) that you describe.

"I'm just not sure we are ready to start paving roads and putting up street
signs."
If by this you mean end-user documentation, then I had only suggested that
it would be easier to get there flowing on from things like this. This
effort is simply about being cohesive for the overall direction we are
supposed to be heading together as a project. If we can't describe
fundamental things in a way we all understand and agree with then it can
make it difficult to collaborate in order to proceed together in the same
direction. That's more about general project management than it is to do
with anything else, in my experience. What I had suggested (or had intended
to convey) was that this type of documentation would also make it easier to
create other more user-focused content for 1.0 and beyond as well, but that
is not the main reason for this now.

" We also DESPERATELY need better documentation and guides. Unfortunately
most of us are not great writers. :-("

I'm assume none of us actually 'likes' writing documentation (I certainly
don't!). But we (a few of us at least) can't say we don't actually have
time to write documentation, because we do have time to write (sometimes
very long, like this one) discussion posts. All we need is a discussion
topic that is focused on the output of a specific piece of content
(document topic heading) and we can all work on it together 'while not
really writing documentation' :). And all we need as a starting point for
that is a skeletal document outline. The idea here is not to do more work,
or even to do things we don't 'like' but to use an activity we already
actually do to in what I think is a more productive way. If we can get this
to work once for PAYG, maybe we can keep it rolling with new topic areas.

Can we please start a new discussion for definition of the component sets
and respective goals (and the degree of relevance or irrelevance to PAYG as
a concept), and keep this thread for  general content
(corrections/omissions etc)

I will start another thread on beads before too long and bring in as much
of the historical content from previous discussions in as a starting point.
This would be for the 'implementation guide' part.

Thanks to Harbs and Alex for already editing the doc.

I will harvest any additional content I can get from this thread into the
wiki doc and also other topic threads suggested above if that is what
people prefer. And I will split the wiki doc out to definitions and
implementation guide as separate pages this coming weekend, as per Yishay's
request.

I'm going to stop there!

On Tue, Jul 4, 2017 at 12:03 PM, Justin Mclean 
wrote:

> Hi,
>
> > You could be right that folks are just too used to the old Flex way of
> > thinking.  If you've never hit the performance and size issues I've seen
> > then maybe you can't understand the motivation behind it, but that might
> > mean the active committers are self-selected.
>
> I’ve worked on many large enterprise Flex systems and while we run into
> performance issues from time to time but they were generally solvable.
> Sometimes in the code itself or at worse by monkey patching the SDK. Not
> everyone experience is going to be the same.
>
> > it could be that the big enterprises that have been
> > burned by old Flex's size and performance are no longer active Flex
> > customers.
>
> There are a large number of reasons for that i.e a lot of big enterprises
> like paid support from a supplier, some are still reluctant to using open
> source (although that is changing) and finding Flex developers these days
> is hard and/or expensive, other frameworks may have more traction,
> popularity, hype or larger communities behind them.
>
> > Documentation is always a good thing, but as I've said several times,
> this
> > is bleeding-edge development.
>
> Having worked on a number of bleeding-edge systems IMO I’m not sure it
> really qualifies for the term. There are other frameworks in this space,
> other cross compilers etc etc and there’s nothing really that cutting edge
> about it. It’s true that it’s currently mostly untested in production so in
> that way it may qualify.
>
> >  I'm just not sure we are ready to start paving roads and putting 

Re: [FlexJS] PAYG definitions and guidance, Please participate

[Greg Dove]

Thanks Alex,

I look forward to your feedback. It would be great to see  (from you or
anyone else) -  within this thread - suggested improvements/corrections or
other topics that should be added, or questions that should be addressed.

I know there are areas that need improvement in a number of areas of the
document, but I'm hoping that this will be 'fixed' by making it a shared
goal and getting input from others, not by me kludging away in the
background. I wanted to get something up that is a starting point only.

I do understand the avoidance of the 'swiss army knife' approach to base
classes in Flex 4, but had wondered about whether we were focusing on the
19% of functionality that might be useful for 5% of developers (Basic) vs.
the 20% of that will suit 80% of developers (e.g. express) -I'm not saying
 that the pareto relationships there are correct, just using it for
'relative' comparison. But I think it is just a case of getting used to a
new way to thinking, which is different to Flex4 (and Flex3). It would be
really great if you can lead a thread specifically about this.

I also suspect there will be no 'one true way' to make incremental
functionality beads either. But documenting the pros and cons of each
approach (which we already started in one of the other threads) might
provide useful guidance about when to choose which approach (inheritance
and/or utility functions etc). I'm looking forward to that discussion
because I think I was getting a lot out of the earlier discussion on that
already.

In the end writing these things in a document is not something I call fun.
"I'd much rather be coding". But I do believe that having 'team-sourced'
content, as an output of focused list discussions, could make the
generation of the document content a much easier process, and that the
process itself could help  improve decision quality, build consensus, and
provide resources that will be useful for team alignment and future
reference info for others. I think any one of those reasons is enough for
me to stop trying to create more of the content myself!



On Sun, Jul 2, 2017 at 3:57 AM, Alex Harui <aha...@adobe.com.invalid> wrote:

> Hi Greg,
>
> Thanks for writing this up.  I took a quick read.  I'll do a more careful
> read next week and have more detailed comments.  One thing I wanted put up
> for discussion now is the notion of "defaults".  Really, I'm trying to get
> away from the notion that there is one default we have to decide on.  IMO,
> that's another old way of thinking from Flex.  FlexJS is designed to
> support multiple component sets.  Express will have different defaults.
> MDL has different defaults.  The Basic set has a particular design goal
> (feature parity with SWF) and thus will have different defaults.  There is
> often no one right answer, so we build different component sets and folks
> will try them and decide for themselves.
>
> Thoughts?
> -Alex
>
> On 6/30/17, 3:29 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Following on from other discussions, I have made a start on something here
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fcwiki.apa
> >che.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%
> 3D71013028=02
> >%7C01%7C%7C35f519d4ea87431fd80808d4c0078bc3%
> 7Cfa7b1b5a7b34438794aed2c178de
> >cee1%7C0%7C0%7C636344586020292933=aj4YiAsUQDGoW5Bf%
> 2BQ2wyJxgqmguZ18T
> >Zng2jGcWIkY%3D=0
> >
> >In the end this will only work if people want to do it. But I do believe
> >that one way of getting everyone on the same page here (and we do have
> >clear signs that not everyone is), is to, quite literally, get everyone on
> >the same page :).
> >
> >It is currently half content, half notes. There is more to harvest from
> >list discussions I think, some topics have progressed further than when I
> >started trying to capture ideas, so please correct any mistakes in the
> >definitions or add topics and questions that need 'resolution'/guidance.
> >
> >I personally would like to see some concrete guidance in the 'How does
> >PAYG
> >get implemented' section. There were definitely the beginnings of some
> >healthy discussions around some of the options for beads for example.
> >(DRY,
> >inheritance, utility functions etc).
> >
> >The goal here is to turn any list discussions around
> >uncertainties/misunderstandings into something that represents consensus.
> >I
> >think this should be do-able by simple discussions about specific topics,
> >maybe with informal voting if necessary. If there is no consensus then I
> >guess PMC could do a formal vote? (I don't know what makes sense here)
> >
> >Beyond work on the SDK, this type of information (in some form) might also
> >be helpful as part of the documentation for 1.0 when we get there, so it
> >could save someone time later on as well as being useful in the near term
> >(I hope).
>
>

[FlexJS] PAYG definitions and guidance, Please participate

[Greg Dove]

Following on from other discussions, I have made a start on something here
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=71013028

In the end this will only work if people want to do it. But I do believe
that one way of getting everyone on the same page here (and we do have
clear signs that not everyone is), is to, quite literally, get everyone on
the same page :).

It is currently half content, half notes. There is more to harvest from
list discussions I think, some topics have progressed further than when I
started trying to capture ideas, so please correct any mistakes in the
definitions or add topics and questions that need 'resolution'/guidance.

I personally would like to see some concrete guidance in the 'How does PAYG
get implemented' section. There were definitely the beginnings of some
healthy discussions around some of the options for beads for example. (DRY,
inheritance, utility functions etc).

The goal here is to turn any list discussions around
uncertainties/misunderstandings into something that represents consensus. I
think this should be do-able by simple discussions about specific topics,
maybe with informal voting if necessary. If there is no consensus then I
guess PMC could do a formal vote? (I don't know what makes sense here)

Beyond work on the SDK, this type of information (in some form) might also
be helpful as part of the documentation for 1.0 when we get there, so it
could save someone time later on as well as being useful in the near term
(I hope).

Re: [FlexJS] Question about wiki access

[Greg Dove]

Thanks Alex,

My username is gregdove same as jira, unless I messed up somewhere.

I won't be able to get to it until tonight my time earliest, which is 10-12
hours away, so no rush... whenever you get a chance to look into this, that
is very much appreciated.



On Mon, Jun 26, 2017 at 7:04 PM, Alex Harui <aha...@adobe.com.invalid>
wrote:

> What's your wiki username?
>
> On 6/26/17, 12:00 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >I have been trying to get access to the wiki so I can add a page for PAYG
> >under references and guides.
> >
> >Is this functionality intended to be available for committers? I can only
> >see/select 'Aries' as an option under 'Create'
> >
> >If not, then I can provide my draft content to someone else who has access
> >(any volunteers?)
> >
> >cheers,
> >Greg
>
>

[FlexJS] Question about wiki access

[Greg Dove]

I have been trying to get access to the wiki so I can add a page for PAYG
under references and guides.

Is this functionality intended to be available for committers? I can only
see/select 'Aries' as an option under 'Create'

If not, then I can provide my draft content to someone else who has access
(any volunteers?)

cheers,
Greg

Re: [VOTE] Release Apache Flex FalconJX 0.8.0 RC1

[Greg Dove]

Thanks Piotr, I think any reliable repro will be difficult, because it just
seems to 'happen' sometimes. I had maven typedefs build working fine for a
long time before this happened. Then it happened for svg.js and also later
for the google maps js.
It does sound like others have experienced this too, though.

Because the problem seems to be a patched file 'sometimes' appearing in the
cache and being used for next build's 'download', skipCache sounds like it
will fix it for me.

For now (because I have the manual option to check
the .m2\repository\.cache\maven-download-plugin directory for problems I
will continue as is and report if it happens again, and then use skipCache.
It would be good if anyone else who experienced a similar issue could check
to see if it was the same reason in their maven-download-plugin cache
directory.

I do have a setup where the download file cache is on SSD and the typedefs
repo is on a legacy hard drive, but I have no idea what specific conditions
might be necessary to favour repro of this issue.


On Fri, Jun 16, 2017 at 8:17 AM, piotrz  wrote:

> Greg,
>
> If you could once again reproduce this issue and try later whether switch
> off cache help that would be good.
>
> Go to: flex-typedefs\js\pom.xml and add to configuration tag in
> download-maven-plugin
>
> true
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-development
> .247.n4.nabble.com/VOTE-Release-Apache-Flex-FalconJX-0-
> 8-0-RC1-tp62271p62417.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [VOTE] Release Apache Flex FalconJX 0.8.0 RC1

[Greg Dove]

Hi Piotr,

 "If option a - mean avoid caching svg.js file - It is not a problem I know how
to do this for this file and it can be downloaded for each build."

yes, the idea here was to avoid caching the download in the
maven-download-plugin's own cache. I did not know if there was an option to
do with in the
That sounds great (at least for me, I am not concerned about the caching
aspect, but others might be)

for
" b) We are downloading this file to target/downloads/svg.js - Do you mean
changing that location and patch that file in the new location ?"

I don't mean changing the download location, but copying the downloaded
file to a separate location and patching it in a different location.
The idea is that if the maven-download-plugin is caching the file after it
has been patched (and it does seem to happen sometimes, perhaps only
rarely) from the original download location, then copying and patching it
in a different location would avoid the possibility of caching a patched
file from the original download location.

There may be other options to fix the problem I observed  Another option
might be to delay the patching of the downloaded file (maven has build
phases and I notice the patch is in 'validate', same as the download) I did
wonder if it might be possible to defer the patch to a later phase
(assuming any caching activity might then always happen first), but I do
not know enough about this.


Also it looks like we are using version 1.2.1 of the download plugin, and
current version is 1.3.0. I checked the commit history between releases and
there was at least one cache-related commit [1]. A plugin version change
might be worth considering as well, but I am not sure if it will address
the issue.

-Greg



1.
https://github.com/maven-download-plugin/maven-download-plugin/compare/1.2.1...master



On Fri, Jun 16, 2017 at 1:39 AM, piotrz  wrote:

> Hi Greg,
>
> In your points "a" and "b" I'm not sure what do you mean.
>
> If option a - mean avoid caching svg.js file - It is not a problem I know
> how to do this for this file and it can be downloaded for each build.
>
> Option b) We are downloading this file to target/downloads/svg.js - Do you
> mean changing that location and patch that file in the new location ?
>
> Thanks,
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/VOTE-Release-Apache-Flex-
> FalconJX-0-8-0-RC1-tp62271p62410.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [VOTE] Release Apache Flex FalconJX 0.8.0 RC1

[Greg Dove]

"But now that you've run Maven again, what version of
svg.js got cached?  The svg.js in my cache does need patching."

I think we crossed email replies because I already added comments about
that -see my previous post if you did not already.

To verify, I copied the downloaded and patched version of svg.js into the
cache, overwriting the last cached version, which was unpatched, and I can
repro the exact same error that I had before. I can only assure you I *did
not* do this originally :)
What I suggested is speculation, but I cannot see how else this could
happen.

So I think the resolution should either be to a) avoid using the download
plugin file cache somehow - or b) to patch a copy of the downloaded files
in a different temp location other than the original download location. I'm
afraid I don't know how to do either in maven at this point.
For now I am happy to find something that seems to 'fix' the issues I was
having with maven typedefs build. fwiw I also had a similar issue with the
googlemaps patch (only during recently builds) , it was the same type of
thing and was no longer apparent after emptying the same file cache.




On Thu, Jun 15, 2017 at 12:07 PM, Alex Harui <aha...@adobe.com.invalid>
wrote:

> That's interesting.  But now that you've run Maven again, what version of
> svg.js got cached?  The svg.js in my cache does need patching.
>
> -Alex
>
> On 6/14/17, 4:54 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >I just manually emptied the file cache in .m2\repository\.
> >cache\maven-download-plugin
> >
> >And typedefs built fine via maven.
> >So my guess is that the download plugin is caching the files after they
> >have been patched and next time it is 'downloading' the patched file
> >
> >
> >On Thu, Jun 15, 2017 at 11:40 AM, Greg Dove <greg.d...@gmail.com> wrote:
> >
> >> A possible clue:
> >>
> >> I can see the patched file in :
> >> C:\Users\Greg\.m2\repository\.cache\maven-download-plugin
> >>
> >>
> >>
> >> On Thu, Jun 15, 2017 at 11:25 AM, Greg Dove <greg.d...@gmail.com>
> wrote:
> >>
> >>> Alex, fyi if I delete the target directory inside flex-typedefs (to be
> >>> sure it is 'clean', although I am quite sure mvn clean does this also)
> >>>,
> >>> then run mvn clean compile, i get the following in svg.js inside
> >>>downloads:
> >>>
> >>> /**
> >>>  * @param {string} type
> >>>  * @param {!EventListener|(function(!Event): (boolean|undefined))|
> >>>null}
> >>> listener
> >>>  * @param {boolean=} opt_useCapture
> >>>  */
> >>> SVGElementInstance.prototype.addEventListener = function(type,
> >>>listener,
> >>> opt_useCapture){};
> >>>
> >>> so for me at least, it does already seem to have the
> >>>"(function(!Event):"
> >>> etc in it.
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Jun 15, 2017 at 11:09 AM, Alex Harui <aha...@adobe.com.invalid
> >
> >>> wrote:
> >>>
> >>>> I just ran the curl command (sorry if my Outlook has munged the URL).
> >>>> I
> >>>> got the same hash.  When I open it up, I see:
> >>>>
> >>>> /**
> >>>>  * @param {string} type
> >>>>  * @param {!EventListener|(function(Event): (boolean|undefined))|
> >>>>null}
> >>>> listener
> >>>>  * @param {boolean=} opt_useCapture
> >>>>  */
> >>>> SVGElementInstance.prototype.addEventListener = function(type,
> >>>>listener,
> >>>> opt_useCapture){};
> >>>>
> >>>> The patch is trying to replace
> >>>>
> >>>> (function(Event):
> >>>>
> >>>>
> >>>> With:
> >>>>
> >>>> (function(!Event):
> >>>>
> >>>>
> >>>> I verified locally that both my Ant and Maven builds from the repos
> >>>>can
> >>>> successfully download and patch svg.js.  I did a clean before each
> >>>>build
> >>>> to verify that svg.js was not in the repo working copy folders.
> >>>>
> >>>>
> >>>> So you are saying that when you use curl to grab that file it already
> >>>>has
> >>>> "(function(!Event):" in it?  That isn't the case for me.  That is
> >>>>rea

Re: [VOTE] Release Apache Flex FalconJX 0.8.0 RC1

[Greg Dove]

Yeah, I think this might be some caching of the downloaded file and
possibly is not a reliable repro.
I just checked now and the cached file for svg.js in my .m2\repository\.
cache\maven-download-plugin after my latest build is not patched. But it
definitely was before. So it might be a bit 'random'
Perhaps this can be avoided by some setting in the pom for the download
plugin or by copying the downloaded file and patching it in a different
location.

Whether this happens might simply depend on how quickly maven-download-plugin
caches the downloaded file and whether or not it has already been patched
when it does so. This could account for why some people seem to have
experienced this problem and others have not (with the maven typedefs
build).




On Thu, Jun 15, 2017 at 11:57 AM, Alex Harui <aha...@adobe.com.invalid>
wrote:

> Greg,
>
> The Maven build will download and patch the svg.js file so when I look at
> my copy after running "mvn clean install", svg.js does have
> "function(!Event)" as it should.  IOW, the Ant and Maven build should
> download svg.js with "function(Event)" and change it to
> "function(!Event)".  It happens fast so I don't know how to interrupt the
> build to see what actually gets downloaded.  I believe Justin is saying
> that the initial download already has "function(!Event)" but it doesn't
> for me.
>
> If folks are trying to build flex-typedefs via Maven from inside the
> FalconJX RC1 source package, I'm not sure that's ever been tried.  That
> could cause the patch to fail as the flex-typedefs folder is nested one
> level.  I moved the flex-typedefs folder outside of the FalconJX folder
> and Maven worked for me.
>
> Thanks,
> -Alex
>
> On 6/14/17, 4:25 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Alex, fyi if I delete the target directory inside flex-typedefs (to be
> >sure
> >it is 'clean', although I am quite sure mvn clean does this also) , then
> >run mvn clean compile, i get the following in svg.js inside downloads:
> >
> >/**
> > * @param {string} type
> > * @param {!EventListener|(function(!Event): (boolean|undefined))| null}
> >listener
> > * @param {boolean=} opt_useCapture
> > */
> >SVGElementInstance.prototype.addEventListener = function(type, listener,
> >opt_useCapture){};
> >
> >so for me at least, it does already seem to have the "(function(!Event):"
> >etc in it.
> >
> >
> >
> >
> >On Thu, Jun 15, 2017 at 11:09 AM, Alex Harui <aha...@adobe.com.invalid>
> >wrote:
> >
> >> I just ran the curl command (sorry if my Outlook has munged the URL).  I
> >> got the same hash.  When I open it up, I see:
> >>
> >> /**
> >>  * @param {string} type
> >>  * @param {!EventListener|(function(Event): (boolean|undefined))| null}
> >> listener
> >>  * @param {boolean=} opt_useCapture
> >>  */
> >> SVGElementInstance.prototype.addEventListener = function(type,
> listener,
> >> opt_useCapture){};
> >>
> >> The patch is trying to replace
> >>
> >> (function(Event):
> >>
> >>
> >> With:
> >>
> >> (function(!Event):
> >>
> >>
> >> I verified locally that both my Ant and Maven builds from the repos can
> >> successfully download and patch svg.js.  I did a clean before each build
> >> to verify that svg.js was not in the repo working copy folders.
> >>
> >>
> >> So you are saying that when you use curl to grab that file it already
> >>has
> >> "(function(!Event):" in it?  That isn't the case for me.  That is really
> >> strange given the hash was the same.
> >>
> >> Very puzzled,
> >> -Alex
> >>
> >>
> >> On 6/13/17, 7:23 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
> >>
> >> >Hi,
> >> >
> >> >Changing to -1 (binding).
> >> >
> >> >I can confirm the tyoedef issue is not due to differences in git
> >>version.
> >> >
> >> >My guess (but not confirmed) is that some people may to have the js
> >>file
> >> >file cached and that it has changed recently so the patch no longer
> >> >applies.
> >> >
> >> >I can confirm that the current js.patch will not apply to the file
> >> >current file here [1].
> >> >
> >> >Can some mind doing a diff with their version of the file and the
> >>version
> >> >here [1]?
&

Re: [VOTE] Release Apache Flex FalconJX 0.8.0 RC1

[Greg Dove]

I just manually emptied the file cache in .m2\repository\.
cache\maven-download-plugin

And typedefs built fine via maven.
So my guess is that the download plugin is caching the files after they
have been patched and next time it is 'downloading' the patched file


On Thu, Jun 15, 2017 at 11:40 AM, Greg Dove <greg.d...@gmail.com> wrote:

> A possible clue:
>
> I can see the patched file in :
> C:\Users\Greg\.m2\repository\.cache\maven-download-plugin
>
>
>
> On Thu, Jun 15, 2017 at 11:25 AM, Greg Dove <greg.d...@gmail.com> wrote:
>
>> Alex, fyi if I delete the target directory inside flex-typedefs (to be
>> sure it is 'clean', although I am quite sure mvn clean does this also) ,
>> then run mvn clean compile, i get the following in svg.js inside downloads:
>>
>> /**
>>  * @param {string} type
>>  * @param {!EventListener|(function(!Event): (boolean|undefined))| null}
>> listener
>>  * @param {boolean=} opt_useCapture
>>  */
>> SVGElementInstance.prototype.addEventListener = function(type, listener,
>> opt_useCapture){};
>>
>> so for me at least, it does already seem to have the "(function(!Event):"
>> etc in it.
>>
>>
>>
>>
>> On Thu, Jun 15, 2017 at 11:09 AM, Alex Harui <aha...@adobe.com.invalid>
>> wrote:
>>
>>> I just ran the curl command (sorry if my Outlook has munged the URL).  I
>>> got the same hash.  When I open it up, I see:
>>>
>>> /**
>>>  * @param {string} type
>>>  * @param {!EventListener|(function(Event): (boolean|undefined))| null}
>>> listener
>>>  * @param {boolean=} opt_useCapture
>>>  */
>>> SVGElementInstance.prototype.addEventListener = function(type, listener,
>>> opt_useCapture){};
>>>
>>> The patch is trying to replace
>>>
>>> (function(Event):
>>>
>>>
>>> With:
>>>
>>> (function(!Event):
>>>
>>>
>>> I verified locally that both my Ant and Maven builds from the repos can
>>> successfully download and patch svg.js.  I did a clean before each build
>>> to verify that svg.js was not in the repo working copy folders.
>>>
>>>
>>> So you are saying that when you use curl to grab that file it already has
>>> "(function(!Event):" in it?  That isn't the case for me.  That is really
>>> strange given the hash was the same.
>>>
>>> Very puzzled,
>>> -Alex
>>>
>>>
>>> On 6/13/17, 7:23 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>>>
>>> >Hi,
>>> >
>>> >Changing to -1 (binding).
>>> >
>>> >I can confirm the tyoedef issue is not due to differences in git
>>> version.
>>> >
>>> >My guess (but not confirmed) is that some people may to have the js file
>>> >file cached and that it has changed recently so the patch no longer
>>> >applies.
>>> >
>>> >I can confirm that the current js.patch will not apply to the file
>>> >current file here [1].
>>> >
>>> >Can some mind doing a diff with their version of the file and the
>>> version
>>> >here [1]?
>>> >
>>> >Or posting a hash of the file they have:
>>> >$curl
>>> >https://na01.safelinks.protection.outlook.com/?url=https%3A
>>> %2F%2Fstorage.g
>>> >oogleapis.com%2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com
>>> %2Fclo
>>> >sureidl%2Fsvg.js=02%7C01%7C%7C2663b54b26d74c4e011c08d4
>>> b2cc5b6c%7Cfa7b
>>> >1b5a7b34438794aed2c178decee1%7C0%7C0%7C636330038163199802
>>> data=GzJiK3o9QT
>>> >3TcUiBFDUpKJIYELPlBIWbKHVsuIeIzxs%3D=0 > svg.js
>>> >  % Total% Received % Xferd  Average Speed   TimeTime Time
>>> >Current
>>> > Dload  Upload   Total   SpentLeft
>>> >Speed
>>> >100  155k  100  155k0 0  74173  0  0:00:02  0:00:02 --:--:--
>>> >74189
>>> >$md5 svg.js
>>> >MD5 (svg.js) = 568eb2c11ba33da58eb0471beef76cb9
>>> >
>>> >Thanks,
>>> >Justin
>>> >
>>> >1.
>>> >https://na01.safelinks.protection.outlook.com/?url=https%3A
>>> %2F%2Fstorage.g
>>> >oogleapis.com%2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com
>>> %2Fclo
>>> >sureidl%2Fsvg.js=02%7C01%7C%7C2663b54b26d74c4e011c08d4
>>> b2cc5b6c%7Cfa7b
>>> >1b5a7b34438794aed2c178decee1%7C0%7C0%7C636330038163199802
>>> data=GzJiK3o9QT
>>> >3TcUiBFDUpKJIYELPlBIWbKHVsuIeIzxs%3D=0
>>> >
>>>
>>>
>>
>

Re: [VOTE] Release Apache Flex FalconJX 0.8.0 RC1

[Greg Dove]

A possible clue:

I can see the patched file in :
C:\Users\Greg\.m2\repository\.cache\maven-download-plugin



On Thu, Jun 15, 2017 at 11:25 AM, Greg Dove <greg.d...@gmail.com> wrote:

> Alex, fyi if I delete the target directory inside flex-typedefs (to be
> sure it is 'clean', although I am quite sure mvn clean does this also) ,
> then run mvn clean compile, i get the following in svg.js inside downloads:
>
> /**
>  * @param {string} type
>  * @param {!EventListener|(function(!Event): (boolean|undefined))| null}
> listener
>  * @param {boolean=} opt_useCapture
>  */
> SVGElementInstance.prototype.addEventListener = function(type, listener,
> opt_useCapture){};
>
> so for me at least, it does already seem to have the "(function(!Event):"
> etc in it.
>
>
>
>
> On Thu, Jun 15, 2017 at 11:09 AM, Alex Harui <aha...@adobe.com.invalid>
> wrote:
>
>> I just ran the curl command (sorry if my Outlook has munged the URL).  I
>> got the same hash.  When I open it up, I see:
>>
>> /**
>>  * @param {string} type
>>  * @param {!EventListener|(function(Event): (boolean|undefined))| null}
>> listener
>>  * @param {boolean=} opt_useCapture
>>  */
>> SVGElementInstance.prototype.addEventListener = function(type, listener,
>> opt_useCapture){};
>>
>> The patch is trying to replace
>>
>> (function(Event):
>>
>>
>> With:
>>
>> (function(!Event):
>>
>>
>> I verified locally that both my Ant and Maven builds from the repos can
>> successfully download and patch svg.js.  I did a clean before each build
>> to verify that svg.js was not in the repo working copy folders.
>>
>>
>> So you are saying that when you use curl to grab that file it already has
>> "(function(!Event):" in it?  That isn't the case for me.  That is really
>> strange given the hash was the same.
>>
>> Very puzzled,
>> -Alex
>>
>>
>> On 6/13/17, 7:23 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>>
>> >Hi,
>> >
>> >Changing to -1 (binding).
>> >
>> >I can confirm the tyoedef issue is not due to differences in git version.
>> >
>> >My guess (but not confirmed) is that some people may to have the js file
>> >file cached and that it has changed recently so the patch no longer
>> >applies.
>> >
>> >I can confirm that the current js.patch will not apply to the file
>> >current file here [1].
>> >
>> >Can some mind doing a diff with their version of the file and the version
>> >here [1]?
>> >
>> >Or posting a hash of the file they have:
>> >$curl
>> >https://na01.safelinks.protection.outlook.com/?url=https%
>> 3A%2F%2Fstorage.g
>> >oogleapis.com%2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com
>> %2Fclo
>> >sureidl%2Fsvg.js=02%7C01%7C%7C2663b54b26d74c4e011c08d4
>> b2cc5b6c%7Cfa7b
>> >1b5a7b34438794aed2c178decee1%7C0%7C0%7C636330038163199802
>> data=GzJiK3o9QT
>> >3TcUiBFDUpKJIYELPlBIWbKHVsuIeIzxs%3D=0 > svg.js
>> >  % Total% Received % Xferd  Average Speed   TimeTime Time
>> >Current
>> > Dload  Upload   Total   SpentLeft
>> >Speed
>> >100  155k  100  155k0 0  74173  0  0:00:02  0:00:02 --:--:--
>> >74189
>> >$md5 svg.js
>> >MD5 (svg.js) = 568eb2c11ba33da58eb0471beef76cb9
>> >
>> >Thanks,
>> >Justin
>> >
>> >1.
>> >https://na01.safelinks.protection.outlook.com/?url=https%
>> 3A%2F%2Fstorage.g
>> >oogleapis.com%2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com
>> %2Fclo
>> >sureidl%2Fsvg.js=02%7C01%7C%7C2663b54b26d74c4e011c08d4
>> b2cc5b6c%7Cfa7b
>> >1b5a7b34438794aed2c178decee1%7C0%7C0%7C636330038163199802
>> data=GzJiK3o9QT
>> >3TcUiBFDUpKJIYELPlBIWbKHVsuIeIzxs%3D=0
>> >
>>
>>
>

Re: [VOTE] Release Apache Flex FalconJX 0.8.0 RC1

[Greg Dove]

Alex, fyi if I delete the target directory inside flex-typedefs (to be sure
it is 'clean', although I am quite sure mvn clean does this also) , then
run mvn clean compile, i get the following in svg.js inside downloads:

/**
 * @param {string} type
 * @param {!EventListener|(function(!Event): (boolean|undefined))| null}
listener
 * @param {boolean=} opt_useCapture
 */
SVGElementInstance.prototype.addEventListener = function(type, listener,
opt_useCapture){};

so for me at least, it does already seem to have the "(function(!Event):"
etc in it.




On Thu, Jun 15, 2017 at 11:09 AM, Alex Harui 
wrote:

> I just ran the curl command (sorry if my Outlook has munged the URL).  I
> got the same hash.  When I open it up, I see:
>
> /**
>  * @param {string} type
>  * @param {!EventListener|(function(Event): (boolean|undefined))| null}
> listener
>  * @param {boolean=} opt_useCapture
>  */
> SVGElementInstance.prototype.addEventListener = function(type, listener,
> opt_useCapture){};
>
> The patch is trying to replace
>
> (function(Event):
>
>
> With:
>
> (function(!Event):
>
>
> I verified locally that both my Ant and Maven builds from the repos can
> successfully download and patch svg.js.  I did a clean before each build
> to verify that svg.js was not in the repo working copy folders.
>
>
> So you are saying that when you use curl to grab that file it already has
> "(function(!Event):" in it?  That isn't the case for me.  That is really
> strange given the hash was the same.
>
> Very puzzled,
> -Alex
>
>
> On 6/13/17, 7:23 PM, "Justin Mclean"  wrote:
>
> >Hi,
> >
> >Changing to -1 (binding).
> >
> >I can confirm the tyoedef issue is not due to differences in git version.
> >
> >My guess (but not confirmed) is that some people may to have the js file
> >file cached and that it has changed recently so the patch no longer
> >applies.
> >
> >I can confirm that the current js.patch will not apply to the file
> >current file here [1].
> >
> >Can some mind doing a diff with their version of the file and the version
> >here [1]?
> >
> >Or posting a hash of the file they have:
> >$curl
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fstorage.g
> >oogleapis.com%2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com
> %2Fclo
> >sureidl%2Fsvg.js=02%7C01%7C%7C2663b54b26d74c4e011c08d4b2cc
> 5b6c%7Cfa7b
> >1b5a7b34438794aed2c178decee1%7C0%7C0%7C636330038163199802&
> sdata=GzJiK3o9QT
> >3TcUiBFDUpKJIYELPlBIWbKHVsuIeIzxs%3D=0 > svg.js
> >  % Total% Received % Xferd  Average Speed   TimeTime Time
> >Current
> > Dload  Upload   Total   SpentLeft
> >Speed
> >100  155k  100  155k0 0  74173  0  0:00:02  0:00:02 --:--:--
> >74189
> >$md5 svg.js
> >MD5 (svg.js) = 568eb2c11ba33da58eb0471beef76cb9
> >
> >Thanks,
> >Justin
> >
> >1.
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fstorage.g
> >oogleapis.com%2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com
> %2Fclo
> >sureidl%2Fsvg.js=02%7C01%7C%7C2663b54b26d74c4e011c08d4b2cc
> 5b6c%7Cfa7b
> >1b5a7b34438794aed2c178decee1%7C0%7C0%7C636330038163199802&
> sdata=GzJiK3o9QT
> >3TcUiBFDUpKJIYELPlBIWbKHVsuIeIzxs%3D=0
> >
>
>

Re: [DISCUSS] Discuss Release Apache Flex FalconJX 0.8.0 RC1

[Greg Dove]

Piotr, I have been trying to get this to work at various stages also.

fyi inside typedefs/js there is an ant build.xml with a 'make_patch' target
which seems like it is intended to be used for updating the patch, and it
does seem to update it, but then I was hitting other problems after it did,
so I'm not sure about that.





On Wed, Jun 14, 2017 at 5:04 PM, piotrz  wrote:

> Justin,
>
> Thanks for reporting it. I will be focusing today on making Maven steps
> from
> Chris in order to prepare for the next RC. Is someone else have a cycles to
> look into that would awesome. :)
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/DISCUSS-Discuss-Release-
> Apache-Flex-FalconJX-0-8-0-RC1-tp62272p62386.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [2/4] git commit: [flex-asjs] [refs/heads/develop] - LayoutBase Fix for strand set to null in remove bead, plus performance improvements in js

[Greg Dove]

I happened to be testing against FlexJSStore at the time I discovered the
need for this, and there is some removing going on.

I think I improved performance compared to how it was originally by
removing coercion in js and using local references for some of the repeat
listener references/avoiding repeat closure lookups on js, so it is
probably 'less' PAYG than it was before, with more safety, but I get the
point.

I'm not sure about injection, but I will come back to this and add a
removable layout subclass for the FlexJSStore demo (not sure if the
PanelView or whatever seems to be doing this is also used in other
examples, I have not checked).




On Sat, Jun 10, 2017 at 10:45 AM, Alex Harui <aha...@adobe.com> wrote:

> I guess I don't believe that removing beads is so common that every app
> needs to carry this code around.  I wonder if there is a way to inject
> removability as needed.
>
> Having a RemovableXXXLayout could override the strand setter and remove
> listeners if the handlers are protected.
>
> Thoughts?
> -Alex
>
> On 6/8/17, 3:22 PM, "gregd...@apache.org" <gregd...@apache.org> wrote:
>
> >LayoutBase Fix for strand set to null in remove bead, plus performance
> >improvements in js
> >
> >
> >Project:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fgit-wip-us
> >.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Frepo=02%
> 7C01%7C%7Cb863f5cff77
> >e41e305b708d4aebcd62e%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6363255
> >73442866659=NsSQs6LJBQaYIJ36tZ%2FgMmMyuffAlo7pAuwtopOok2g%3D&
> reserve
> >d=0
> >Commit:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fgit-wip-us
> >.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Fcommit%
> 2F08af60c7=02%7C01%7C%
> >7Cb863f5cff77e41e305b708d4aebcd62e%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%
> >7C0%7C636325573442866659=a8HJuqkEEii03BRyFH6lMcvkLFirlc
> lo6HwG%2F6w4J
> >kA%3D=0
> >Tree:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fgit-wip-us
> >.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Ftree%2F08af60c7&
> data=02%7C01%7C%7C
> >b863f5cff77e41e305b708d4aebcd62e%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C
> >0%7C636325573442866659=CcHeFSf6IMQ75kKXSE%
> 2BWY23J7VrbJauoxO1TvG%2BHS
> >Yk%3D=0
> >Diff:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fgit-wip-us
> >.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Fdiff%2F08af60c7&
> data=02%7C01%7C%7C
> >b863f5cff77e41e305b708d4aebcd62e%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C
> >0%7C636325573442866659=E%2B6iEUFqZB3%2BO15%
> 2BK3sHlnaiuIkWgm8DvWVcmUm
> >nnIk%3D=0
> >
> >Branch: refs/heads/develop
> >Commit: 08af60c7755a9c7dd64ab62cbfff97443841bda7
> >Parents: b0f7013
> >Author: greg-dove <greg.d...@gmail.com>
> >Authored: Fri Jun 9 10:07:20 2017 +1200
> >Committer: greg-dove <greg.d...@gmail.com>
> >Committed: Fri Jun 9 10:17:54 2017 +1200
> >
> >--
> > .../flex/org/apache/flex/core/LayoutBase.as | 40
> +++-
> > 1 file changed, 30 insertions(+), 10 deletions(-)
> >--
> >
> >
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fgit-wip-us
> >.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Fblob%2F08af60c7%
> 2Fframeworks%2Fpro
> >jects%2FBasic%2Fsrc%2Fmain%2Fflex%2Forg%2Fapache%2Fflex%
> 2Fcore%2FLayoutBas
> >e.as=02%7C01%7C%7Cb863f5cff77e41e305b708d4aebc
> d62e%7Cfa7b1b5a7b344387
> >94aed2c178decee1%7C0%7C0%7C636325573442866659=
> fnKUKGhxZfwPRFkiMwfiri
> >aNYV21HE8X7463sLtyYOo%3D=0
> >--
> >diff --git
> >a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> core/LayoutBase.
> >as
> >b/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> core/LayoutBase.
> >as
> >index adadc75..be7d642 100644
> >---
> >a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> core/LayoutBase.
> >as
> >+++
> >b/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> core/LayoutBase.
> >as
> >@@ -76,19 +76,39 @@ package org.apache.flex.core
> >  *  @productversion FlexJS 0.8
> >*
> >* @flexjsignorecoercion org.apache.flex.core.ILayoutChild
> >+   * @flexjsignorecoercion org.apache.flex.events.
> IEventDispatcher
> >  */
> >   public function set strand(value:IStrand):v

[FlexJS] [Typedefs] [Maven] build issues

[Greg Dove]

I have had a few issues with maven build of typedefs (in develop) over recent 
times.

I think others may have experienced this also, at least I have seen similar 
things mentioned previously.

For me this seems to be related to patches being applied when the content that 
is being downloaded is already patched (I *think*, based on eyeballing the 
patch and the download js content). 

In the past I had this with svg.js and today I had it happen with google maps. 
I hand edited  src/main/patch/js.patch to remove the already patched parts for 
svg.js 

and today I simply removed the patch part of the pom.xml inside googlemaps 
subdir to get it to build.

I have not committed any of this because I have no knowledge or confidence in 
terms of what the correct approach should be here.

ant build seems to not have an issue with applying the patch content that 
(apparently) is no longer needed.

I am on windows if that possibly makes any difference to the way git apples 
patches.

Chris, or others, are you ever seeing the above issue in the dev maven build 
for typedefs?

Re: [FlexJS] Removing PasswordInputBead has no effect

[Greg Dove]

Alex, and Harbs,

Thanks for pointing that out. Actually I will have defifintely looked through 
this early on, but I'd have to say it is quite 'light' on what PAYG actually 
means beyond the general sense that I had. It does have some more detail about 
beads which is great and I could have benefited from revisiting that in recent 
months which I did not do. 

But I can see that the newly created 'DRY' discussion thread is actually 
creating the type of content that I think I would have found really helpful in 
terms of linking a guiding concept to one of its key implementation areas. 

Creating this type of documentation is *hard*. Not just because creating the 
content itself is a lot of work, But also because it is not (usually I think) 
something that a developer wants to do, especially when volunteering their 
time. "I'd much rather be coding". So thanks Alex for what you already created 
there.
However, I think the contents of the new thread look really good as something 
that could be used as a resource to define bead variation in terms of PAYG 
adherence, as an implementation guide, and I do think we really need this.

If there's that level of clarity and, ultimately, agreement in terms of 
definitions and approaches, I expect there will be far less need for threads 
like this one.

If no-one else volunteers to wiki-fy the contents of the new thread at its 
conclusion, I will give it a shot over the coming weekend.



On 2017-06-06 18:55 (+1200), Alex Harui <aha...@adobe.com.INVALID> wrote: 
> This was first published in 2012.
> 
> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
> 
> PAYG and avoiding just-in-case code is mentioned in that document.  As are
> Beads.
> 
> Thanks,
> -Alex
> 
> On 6/5/17, 11:33 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
> 
> >Harbs, a quick comment from the sidelines on: "PAYG is already well
> >understood"
> >
> >I don't really think that is the case, at least it has not been for me. I
> >had a more general notion of PAYG that was nothing to do with beads at
> >all,
> >and was limited to guesswork/my own interpretation of it at the beginning
> >because there was no clear definition.
> >
> >Unless this is documented somewhere then I believe it is actually a
> >barrier
> >(of understanding) for people getting involved. If there's already a
> >difficulty with 'thinking this way' and 'acting this way' as you indicated
> >when you had started and had understood it, then it seems important that
> >it
> >should also be easily understood in the first place in order to make
> >things
> >easier for people wanting to participate.
> >
> >As with a lot of things, once you 'know' it you can tend to take if for
> >granted that everyone else does too. But I think you already hinted at
> >that
> >with what you said...
> >
> >I am of the opinion that 'vision', 'mission', 'goals' and even
> >'architecture' etc don't really exist in a form that is useful for shared
> >understanding unless they are documented in some way. And no, 'it's
> >obvious
> >from the source code' is not what I mean :).
> >They are not considered to do so in many other scenarios, in any case, and
> >I can't understand why it would be different in an open source project,
> >although I definitely have not spent time comparing projects to find out
> >what others do here.
> >
> >
> >On Tue, Jun 6, 2017 at 5:21 PM, Harbs <harbs.li...@gmail.com> wrote:
> >
> >> We’ve all already been implementing things as Alex states. He
> >>architected
> >> the framework and it’s a good architecture. No need to change things. We
> >> need consistent architecture. We can’t have a free-for-all...
> >>
> >> Percentage of code really has nothing to do with it. Unless something is
> >> functionality that you would (virtually) always need, it’s a separate
> >>bead.
> >> That’s the way the whole SDK is implemented. If there are cases where
> >>it’s
> >> not, it’s a bug and should be fixed. Removal of password functionality
> >>is
> >> NOT usually required for password beads.
> >>
> >> PAYG is already well understood: All functionality should be implemented
> >> as beads when practical. Beads should be as modular as possible with the
> >> smallest possible functional set.
> >>
> >> That’s pretty much it. It’s difficult to make the mental switch to
> >>working
> >> this way. I had similar difficulty when I started implementing things
> >>for
> >> FlexJS. It takes some getting used to, but itâ

Re: [FlexJS] Removing PasswordInputBead has no effect

[Greg Dove]

Harbs, a quick comment from the sidelines on: "PAYG is already well
understood"

I don't really think that is the case, at least it has not been for me. I
had a more general notion of PAYG that was nothing to do with beads at all,
and was limited to guesswork/my own interpretation of it at the beginning
because there was no clear definition.

Unless this is documented somewhere then I believe it is actually a barrier
(of understanding) for people getting involved. If there's already a
difficulty with 'thinking this way' and 'acting this way' as you indicated
when you had started and had understood it, then it seems important that it
should also be easily understood in the first place in order to make things
easier for people wanting to participate.

As with a lot of things, once you 'know' it you can tend to take if for
granted that everyone else does too. But I think you already hinted at that
with what you said...

I am of the opinion that 'vision', 'mission', 'goals' and even
'architecture' etc don't really exist in a form that is useful for shared
understanding unless they are documented in some way. And no, 'it's obvious
from the source code' is not what I mean :).
They are not considered to do so in many other scenarios, in any case, and
I can't understand why it would be different in an open source project,
although I definitely have not spent time comparing projects to find out
what others do here.


On Tue, Jun 6, 2017 at 5:21 PM, Harbs  wrote:

> We’ve all already been implementing things as Alex states. He architected
> the framework and it’s a good architecture. No need to change things. We
> need consistent architecture. We can’t have a free-for-all...
>
> Percentage of code really has nothing to do with it. Unless something is
> functionality that you would (virtually) always need, it’s a separate bead.
> That’s the way the whole SDK is implemented. If there are cases where it’s
> not, it’s a bug and should be fixed. Removal of password functionality is
> NOT usually required for password beads.
>
> PAYG is already well understood: All functionality should be implemented
> as beads when practical. Beads should be as modular as possible with the
> smallest possible functional set.
>
> That’s pretty much it. It’s difficult to make the mental switch to working
> this way. I had similar difficulty when I started implementing things for
> FlexJS. It takes some getting used to, but it’s a very good design.
>
> Harbs
>
> > On Jun 6, 2017, at 1:16 AM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> >> If you have a different vision, you can execute that vision in another
> >> component set or fork FlexJS entirely.  Please do not impose your vision
> >> on my vision.
> >
> > Since when is this your project Alex or that the project has to only
> include your vision? That is not the Apache way.
> >
> > I would prefer that we all come to a consensus of what PAYG means and
> clearly document it rather that you dictating it.
> >
> > Thanks,
> > Justin
>
>

Re: [FlexJS] hard coded event names

[Greg Dove]

Harbs, I think that is only for debug. I don't think they should add bulk
to the release code. At least they do not in the default settings for GCC
optimisation. You will see the definition of the constant only once and
inline replacement is used for the value (with a short name global
variable) everywhere. The only extra cost of a constant seems to be a
lookup reference that may be added. It seems quite minimal.

If you do a search for both the constant value e.g. 'change' or the the
name of the constant (e.g. FORM_SAVED ) in the release output you should
only ever see it once whichever way you do this.


On Wed, May 24, 2017 at 1:28 PM, Harbs  wrote:

> Huh? Why would tests be necessary?
>
> Like I already said; constants add much more bulk to the JS source code.
> Try it and you’ll see…
>
> > On May 23, 2017, at 5:53 PM, Justin Mclean 
> wrote:
> >
> > Have you done any tests to show this is the case?
>
>

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Greg Dove]

Thanks Alex,  I can see it in the swc, so I'm not sure what is causing the
issue.
I will have to revert and use the pre-dual code today, but will come back
to it in two days to try to figure it out again, after an imminent deadline
that I need to focus on.



On Tue, May 2, 2017 at 8:41 AM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 5/1/17, 1:33 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Just as a quick follow-up (in case anyone else is looking for the same)
> >
> >adding:
> >js
> >to all the swc dependencies in the pom meant I could compile the js-only
> >project. JS alone was not enough.
> >
> >However I am seeing some runtime errors with things like
> >base.js:628 goog.require could not find:
> >org.apache.flex.core.HTMLElementWrapper
>
> Unzip the SWCs and see if HTMLElementWrapper is Basic.swc and/or
> BasicJS.swc.  Basic is "new" so it may need to be added to some POMs.  The
> examples build for me, so I think I got it right in the repo.
>
> HTH,
> -Alex
>
>

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Greg Dove]

Just as a quick follow-up (in case anyone else is looking for the same)

adding:
js
to all the swc dependencies in the pom meant I could compile the js-only
project. JS alone was not enough.

However I am seeing some runtime errors with things like
base.js:628 goog.require could not find:
org.apache.flex.core.HTMLElementWrapper

and similar.

I'm currently trying to figure this out.


On Tue, May 2, 2017 at 5:19 AM, Greg Dove <greg.d...@gmail.com> wrote:

> Thanks Alex,
>
> This helps
> JS
> Still some stuff left to figure out, but that is progress. Pretty sure
> that falls into "I am hoping there is something simple that I didn't see" -
> thanks again.
>
> btw I think :
> true
>
> is presumably redundant in any pom.xml now, including that example. My
> reason for thinking that is that it is coming up 'red', with tooltip
> "Element outputJavaScript is not allowed here", for a local project via
> code highlighting in Intellij (which was really helpful initially to
> understand this change).
>
>
>
> On Tue, May 2, 2017 at 4:42 AM, Alex Harui <aha...@adobe.com> wrote:
>
>> I believe examples/native/ButtonExample only produces JS output.
>>
>> -Alex
>>
>> On 5/1/17, 9:11 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>>
>> >Chris, or perhaps Alex:
>> >With the latest changes for maven, I am trying to figure out how to get
>> >the
>> >same result with maven as
>> >true
>> >
>> >which previously permitted js-only compilation so that COMPILE::JS was
>> not
>> >needed in js-only target project, and it was possible to use, for
>> example,
>> >var style:CSSStyleDeclaration,
>> >window['Intl'] etc
>> >outside of COMPILE::JS
>> >
>> >Is this still possible in some way after the change? I can see options
>> for
>> >maven like
>> >skipAS etc, but have not figured out a combination that achieves the
>> same.
>> >
>> >I am hoping there is something simple that I didn't see - I am still
>> >getting my head around using maven, (apart from finding it mostly very
>> >intuitive to 'read').
>> >If not, I can always go through the code and wrap things in COMPILE::JS,
>> >was just hoping that I don't need to do that.
>> >Thanks,
>> >Greg
>> >
>> >
>> >On Tue, May 2, 2017 at 2:51 AM, Christofer Dutz
>> ><christofer.d...@c-ware.de>
>> >wrote:
>> >
>> >> But in general, “mvn clean compile” should have worked. I even double
>> >> checked with the debugger … if the other modules are part of the build
>> >>it
>> >> would acutally resolve the artifacts from the target directories
>> >>instead of
>> >> from the maven local repo … I’ll continue investigating this.
>> >>
>> >> Chris
>> >>
>> >> Am 30.04.17, 23:42 schrieb "Justin Mclean" <jus...@classsoftware.com>:
>> >>
>> >> Hi,
>> >>
>> >> > You are running “mvn clean compile” which compiles each module
>> and
>> >> created the swcs in the target directories. Unfortunately, they just
>> >>stay
>> >> there as they are not copied to your maven local repository.
>> >>
>> >> Thanks Chris that would explain the error.
>> >>
>> >> > To do that, you need to run “mvn clean install”. I would give
>> >>that a
>> >> try.
>> >>
>> >> Looks like typedef is now broken as I’m getting this:
>> >>
>> >> [INFO] --- exec-maven-plugin:1.5.0:exec (patch-js) @
>> >> flexjs-typedefs-js ---
>> >> error: patch failed: js/target/downloads/svg.js:401
>> >> error: js/target/downloads/svg.js: patch does not apply
>> >> [ERROR] Command execution failed.
>> >>
>> >> I’m assume the patch file no longer matches what’s at [1]?
>> >>
>> >> Thanks,
>> >> Justin
>> >>
>> >> 1.
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3
>> A%2F%2Fstorage.
>> >>googleapis.com%2Fgoogle-code-archive-=02%7C01%7C%7C6d
>> 802edc936741aa1
>> >>c4e08d490acbcb6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0
>> %7C636292518959
>> >>818809=XnKepN4BFugfoG%2BrYp3Kpsc%2F8ZGRT64IpOKGuJ0%2
>> Fk%2Fo%3D
>> >>ved=0
>> >> downloads/v2/code.google.com/closureidl/svg.js
>> >>
>> >>
>> >>
>> >>
>>
>>
>

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Greg Dove]

Thanks Alex,

This helps
JS
Still some stuff left to figure out, but that is progress. Pretty sure that
falls into "I am hoping there is something simple that I didn't see" -
thanks again.

btw I think :
true

is presumably redundant in any pom.xml now, including that example. My
reason for thinking that is that it is coming up 'red', with tooltip
"Element outputJavaScript is not allowed here", for a local project via
code highlighting in Intellij (which was really helpful initially to
understand this change).



On Tue, May 2, 2017 at 4:42 AM, Alex Harui <aha...@adobe.com> wrote:

> I believe examples/native/ButtonExample only produces JS output.
>
> -Alex
>
> On 5/1/17, 9:11 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Chris, or perhaps Alex:
> >With the latest changes for maven, I am trying to figure out how to get
> >the
> >same result with maven as
> >true
> >
> >which previously permitted js-only compilation so that COMPILE::JS was not
> >needed in js-only target project, and it was possible to use, for example,
> >var style:CSSStyleDeclaration,
> >window['Intl'] etc
> >outside of COMPILE::JS
> >
> >Is this still possible in some way after the change? I can see options for
> >maven like
> >skipAS etc, but have not figured out a combination that achieves the same.
> >
> >I am hoping there is something simple that I didn't see - I am still
> >getting my head around using maven, (apart from finding it mostly very
> >intuitive to 'read').
> >If not, I can always go through the code and wrap things in COMPILE::JS,
> >was just hoping that I don't need to do that.
> >Thanks,
> >Greg
> >
> >
> >On Tue, May 2, 2017 at 2:51 AM, Christofer Dutz
> ><christofer.d...@c-ware.de>
> >wrote:
> >
> >> But in general, “mvn clean compile” should have worked. I even double
> >> checked with the debugger … if the other modules are part of the build
> >>it
> >> would acutally resolve the artifacts from the target directories
> >>instead of
> >> from the maven local repo … I’ll continue investigating this.
> >>
> >> Chris
> >>
> >> Am 30.04.17, 23:42 schrieb "Justin Mclean" <jus...@classsoftware.com>:
> >>
> >> Hi,
> >>
> >> > You are running “mvn clean compile” which compiles each module and
> >> created the swcs in the target directories. Unfortunately, they just
> >>stay
> >> there as they are not copied to your maven local repository.
> >>
> >> Thanks Chris that would explain the error.
> >>
> >> > To do that, you need to run “mvn clean install”. I would give
> >>that a
> >> try.
> >>
> >> Looks like typedef is now broken as I’m getting this:
> >>
> >> [INFO] --- exec-maven-plugin:1.5.0:exec (patch-js) @
> >> flexjs-typedefs-js ---
> >> error: patch failed: js/target/downloads/svg.js:401
> >> error: js/target/downloads/svg.js: patch does not apply
> >> [ERROR] Command execution failed.
> >>
> >> I’m assume the patch file no longer matches what’s at [1]?
> >>
> >> Thanks,
> >> Justin
> >>
> >> 1.
> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstorage
> .
> >>googleapis.com%2Fgoogle-code-archive-=02%7C01%7C%
> 7C6d802edc936741aa1
> >>c4e08d490acbcb6%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636292518959
> >>818809=XnKepN4BFugfoG%2BrYp3Kpsc%2F8ZGRT64IpOKGuJ0%
> 2Fk%2Fo%3D
> >>ved=0
> >> downloads/v2/code.google.com/closureidl/svg.js
> >>
> >>
> >>
> >>
>
>

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Greg Dove]

Chris, or perhaps Alex:
With the latest changes for maven, I am trying to figure out how to get the
same result with maven as
true

which previously permitted js-only compilation so that COMPILE::JS was not
needed in js-only target project, and it was possible to use, for example,
var style:CSSStyleDeclaration,
window['Intl'] etc
outside of COMPILE::JS

Is this still possible in some way after the change? I can see options for
maven like
skipAS etc, but have not figured out a combination that achieves the same.

I am hoping there is something simple that I didn't see - I am still
getting my head around using maven, (apart from finding it mostly very
intuitive to 'read').
If not, I can always go through the code and wrap things in COMPILE::JS,
was just hoping that I don't need to do that.
Thanks,
Greg


On Tue, May 2, 2017 at 2:51 AM, Christofer Dutz 
wrote:

> But in general, “mvn clean compile” should have worked. I even double
> checked with the debugger … if the other modules are part of the build it
> would acutally resolve the artifacts from the target directories instead of
> from the maven local repo … I’ll continue investigating this.
>
> Chris
>
> Am 30.04.17, 23:42 schrieb "Justin Mclean" :
>
> Hi,
>
> > You are running “mvn clean compile” which compiles each module and
> created the swcs in the target directories. Unfortunately, they just stay
> there as they are not copied to your maven local repository.
>
> Thanks Chris that would explain the error.
>
> > To do that, you need to run “mvn clean install”. I would give that a
> try.
>
> Looks like typedef is now broken as I’m getting this:
>
> [INFO] --- exec-maven-plugin:1.5.0:exec (patch-js) @
> flexjs-typedefs-js ---
> error: patch failed: js/target/downloads/svg.js:401
> error: js/target/downloads/svg.js: patch does not apply
> [ERROR] Command execution failed.
>
> I’m assume the patch file no longer matches what’s at [1]?
>
> Thanks,
> Justin
>
> 1. https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/closureidl/svg.js
>
>
>
>

Re: [FlexJS][POC] JSFiddle for FlexJS / Compile as-a-service

[Greg Dove]

try haxe has a great example of this type of thing also, with a lot of
pre-defined examples (but no mxml :) ).

https://try.haxe.org/

It may also be a useful reference for planning for future versions of
whatever we do.


On Fri, Apr 28, 2017 at 3:29 AM, Josh Tynjala  wrote:

> Yes, I'm trying to say that a simpler starter project could be to display
> the generated JS code side by side with the AS/MXML. And it would do
> nothing more than that.
>
> I'm not trying to tell you to do this instead of the CodePen/JSFiddle
> project. I'm saying that this simpler project could benefit your
> CodePen/JSFiddle project. It has a smaller scope, so you could release
> something more quickly. Something that potential FlexJS users would find
> useful too! Both projects will integrate with the compiler, though, so a
> lot of the code that you'd write for the simpler project could probably be
> reused in the more complex project.
>
> Maybe you'd prefer to jump right into the more complex CodePen/JSFiddle
> project, and that's totally fine! Just a suggestion.
>
> - Josh
>
>
>
> On Thu, Apr 27, 2017 at 7:42 AM, OK  wrote:
>
> > Josh Tynjala wrote
> > > In this simpler project, the generated code wouldn't even be run (maybe
> > > that's the part that you missed?)
> >
> > I think this is the part that I don't understand. Where do you think the
> > generated code comes from?
> > I thought if it comes from the compiler it always runs?
> >
> > Or is the idea to just prepare some pre-compiled examples and display the
> > MXML/AS3 and HTML/JS side by side?
> >
> > Sorry, I'm lost ;-)
> >
> > Thanks,
> > Olaf
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://apache-flex-
> > development.247.n4.nabble.com/FlexJS-POC-JSFiddle-for-
> > FlexJS-Compile-as-a-service-tp61369p61388.html
> > Sent from the Apache Flex Development mailing list archive at Nabble.com.
> >
>

Re: [FlexJS] Issue with JSON.stringify and Bindable VO objects

[Greg Dove]

I will try to look at it this coming weekend. I have some looming deadlines
with work at the moment that could cause me to end up not having much spare
time :)


On Wed, Apr 26, 2017 at 5:13 PM, piotrz  wrote:

> Hi Greg,
>
> Any chance that you look into that before 0.8 release?
>
> Thanks,
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-Issue-with-JSON-
> stringify-and-Bindable-VO-objects-tp61195p61364.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] Issue with JSON.stringify and Bindable VO objects

[Greg Dove]

Hi Piotr, you should not be concerned about that. For example, your
bindable VO is also IEventDispatcher but you did not code that. The
compiler did it for you after you marked it [Bindable]. So it could also,
for example, add an interface that indicates the class has compiler
generated toJson support if that is helpful to check at runtime. Maybe the
interface is not needed if all you are looking for is the autogenerated
toJson method.

Also my suggestion may not be the best option and I was focusing more on
json to VO than VO to json in that discussion.

-Greg
[sent from my phone]

On 22/04/2017 7:07 PM, "piotrz"  wrote:

> Hi Greg,
>
> Reading your code we landed again to giving our VO some kind of interface ?
> If yes, that's resolve issue, but it won't be to handy. I don't want to
> implement by my VO any interface - I just wanted to have function toJSON -
> which is recognizable by deserializer default.
>
> var book:Book = new Book();
>
> var str:String = JSON.stringify(book) - inside stringify toJSON is being
> called if exists.
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-Issue-with-JSON-
> stringify-and-Bindable-VO-objects-tp61195p61277.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] Issue with JSON.stringify and Bindable VO objects

[Greg Dove]

Thanks for that info.
Most often for client work, I don't choose the data transfer format, and
tbh I would probably choose json vs. xml if I could choose between the two.
The simplest json based 'typed' data I have seen sends
"__type":"typename_here" in the generic objects, which can be used during
deserialization. This is kind of like class alias, but afaik there is no
official standard for anything like this (I have not searched/checked
recently).

I think it could be useful to add compiler-generated support into
metadata-marked classes so that they supported the ability to create and/or
update existing values for values from generic objects, which might include
nested complex types.

something like (pseudo code) (inside ThisClass ):

//support methods
private static const _permittedFields:Array = ['field1', 'field2'];
public static function fromObject(object:Object,
inst:ThisClass=null):ThisClass{
  if (!inst) inst = new ThisClass();
   for (var field:String in obj) {
 //the raw object might have meta data for deserialization or
unlrelated fields:
  if(_permittedFields.indexOf(field)==-1) continue;
  switch (field) {
//compiler-generated special-casing of complex type fields:
case "complexField" :
   inst[field] = ComplexFieldType.fromObject(ob
j[field],inst[field]]);
 break;
default:
   inst[field] = obj[field]
   break;
  }
   }
 return inst;
}

public static function toObject


//interface methods
public function updateFrom(obj:Object) :void{
  fromObject(object,this)
}

public function getAsObject():Object{
  //tbd but similar to a reverse version of the above
}

This type of thing could support both the simple VO case and more complex
deserialization
I have done the above sort of thing manually in the past on a few occasions
at least.

I haven't thought too deeply about this (inherited fieldsets need to be
considered and whether a parent class has the option enabled or not so that
part needs some thought, for example) so maybe there are flaws in the above
idea and perhaps it is more complicated to have the compiler support it
than I think. But if there is consensus that this type of thing is
worthwhile, I would be happy to try for this as some sort of opt-in
compiler support.



On Fri, Apr 21, 2017 at 3:08 AM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 4/19/17, 1:29 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Yes I was thinking more in terms of the times I did this type of thing to
> >support nested typed objects from raw json, more than simple VOs. Not so
> >much in terms of using reviver, but going through from json -> generic
> >object -> typed object with most of the support for the last part being in
> >the abstract base class, and extra field mappings to complex field types
> >defined in subclasses for specific fields. It was maintainable at the
> >individual class level, but still quite complicated. Poor man's amf.
> >
> >Probably not relevant here for simple VOs.
>
> Did you look at the AMFX classes (not regular AMF)?  It might serve as a
> starting point for a JSON version.
>
> [1]
> https://books.google.com/books?id=qtlUSkC4HRQC=PT1458
> =PT1458=AMFX
> +specification+adobe=bl=1Hx1n3jo0d=puxfHwWuDS
> kP-jwbXVKGFmriy
> 64=en=X=0ahUKEwipx8fAp7PTAhXpsVQKHSL1Cf4Q6AEIRjAH#
> v=onepage=AMF
> X%20specification%20adobe=false
> <https://books.google.com/books?id=qtlUSkC4HRQC=PT1458=PT1458=AMFX+specification+adobe=bl=1Hx1n3jo0d=puxfHwWuDSkP-jwbXVKGFmriy64=en=X=0ahUKEwipx8fAp7PTAhXpsVQKHSL1Cf4Q6AEIRjAH#v=onepage=AMFX%20specification%20adobe=false>
>
> -Alex
>
>

Re: [FlexJS] Issue with JSON.stringify and Bindable VO objects

[Greg Dove]

Yes Piotr, although I think we are all guessing what you want, it will be
helpful to be certain.



On Wed, Apr 19, 2017 at 9:03 PM, piotrz  wrote:

> Greg,
>
> In order to touch this subject on compiler sight, would it be helpful if I
> prepare what Alex asked me ?
>
> Scenario and generated code in JS sight ?
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-Issue-with-JSON-
> stringify-and-Bindable-VO-objects-tp61195p61232.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] Issue with JSON.stringify and Bindable VO objects

[Greg Dove]

Yes I was thinking more in terms of the times I did this type of thing to
support nested typed objects from raw json, more than simple VOs. Not so
much in terms of using reviver, but going through from json -> generic
object -> typed object with most of the support for the last part being in
the abstract base class, and extra field mappings to complex field types
defined in subclasses for specific fields. It was maintainable at the
individual class level, but still quite complicated. Poor man's amf.

Probably not relevant here for simple VOs.




On Wed, Apr 19, 2017 at 6:47 PM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 4/18/17, 11:45 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >maybe fromJson is not the best example :)
>
> I'm not sure I understand what you want to do.  Are you trying to support
> types in the JSON reviver?
>
> -Alex
>
> >
> >
> >On Wed, Apr 19, 2017 at 6:42 PM, Greg Dove <greg.d...@gmail.com> wrote:
> >
> >> I'd be happy to look at compiler side support for this at some point
> >> during the next month, it is something I have hand-coded many times and
> >>I
> >> think to/from JSON style support would be helpful for VO, especially
> >> bindables. It would need to add an interface I think so you could cast
> >>the
> >> VO in serialize/deserialize parts of service calls etc.
> >>
> >> e.g. creating VO from json:
> >>
> >> var myVO:VOClass = new VOClass()
> >> (myVO as IJSONable).fromJSON(jsonData)
> >>
> >> I know not everyone likes metadata, but this seems like a VO-specific
> >> metadata on the class, that the compiler would pick up on. It could even
> >> ignore [Transient] members if there are any.
> >>
> >> This keeps it away from being dependent on the reflection data and makes
> >> it specific to the classes that need it
> >>
> >>
> >>
> >>
> >> On Wed, Apr 19, 2017 at 6:23 PM, piotrz <piotrzarzyck...@gmail.com>
> >>wrote:
> >>
> >>> Alex, Harbs,
> >>>
> >>> I understand, but I thought that you will handle those method on the
> >>> compiler sight - Am I miss something ?
> >>>
> >>> Piotr
> >>>
> >>>
> >>>
> >>> -
> >>> Apache Flex PMC
> >>> piotrzarzyck...@gmail.com
> >>> --
> >>> View this message in context: http://apache-flex-development
> >>> .247.n4.nabble.com/FlexJS-Issue-with-JSON-stringify-and-
> >>> Bindable-VO-objects-tp61195p61216.html
> >>> Sent from the Apache Flex Development mailing list archive at
> >>>Nabble.com.
> >>>
> >>
> >>
>
>

Re: [FlexJS] Issue with JSON.stringify and Bindable VO objects

[Greg Dove]

maybe fromJson is not the best example :)


On Wed, Apr 19, 2017 at 6:42 PM, Greg Dove <greg.d...@gmail.com> wrote:

> I'd be happy to look at compiler side support for this at some point
> during the next month, it is something I have hand-coded many times and I
> think to/from JSON style support would be helpful for VO, especially
> bindables. It would need to add an interface I think so you could cast the
> VO in serialize/deserialize parts of service calls etc.
>
> e.g. creating VO from json:
>
> var myVO:VOClass = new VOClass()
> (myVO as IJSONable).fromJSON(jsonData)
>
> I know not everyone likes metadata, but this seems like a VO-specific
> metadata on the class, that the compiler would pick up on. It could even
> ignore [Transient] members if there are any.
>
> This keeps it away from being dependent on the reflection data and makes
> it specific to the classes that need it
>
>
>
>
> On Wed, Apr 19, 2017 at 6:23 PM, piotrz <piotrzarzyck...@gmail.com> wrote:
>
>> Alex, Harbs,
>>
>> I understand, but I thought that you will handle those method on the
>> compiler sight - Am I miss something ?
>>
>> Piotr
>>
>>
>>
>> -
>> Apache Flex PMC
>> piotrzarzyck...@gmail.com
>> --
>> View this message in context: http://apache-flex-development
>> .247.n4.nabble.com/FlexJS-Issue-with-JSON-stringify-and-
>> Bindable-VO-objects-tp61195p61216.html
>> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>>
>
>

Re: [FlexJS] Issue with JSON.stringify and Bindable VO objects

[Greg Dove]

I'd be happy to look at compiler side support for this at some point during
the next month, it is something I have hand-coded many times and I think
to/from JSON style support would be helpful for VO, especially bindables.
It would need to add an interface I think so you could cast the VO in
serialize/deserialize parts of service calls etc.

e.g. creating VO from json:

var myVO:VOClass = new VOClass()
(myVO as IJSONable).fromJSON(jsonData)

I know not everyone likes metadata, but this seems like a VO-specific
metadata on the class, that the compiler would pick up on. It could even
ignore [Transient] members if there are any.

This keeps it away from being dependent on the reflection data and makes it
specific to the classes that need it




On Wed, Apr 19, 2017 at 6:23 PM, piotrz  wrote:

> Alex, Harbs,
>
> I understand, but I thought that you will handle those method on the
> compiler sight - Am I miss something ?
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-Issue-with-JSON-
> stringify-and-Bindable-VO-objects-tp61195p61216.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: git commit: [flex-asjs] [refs/heads/develop] - CORS security. Allow auth credentials to be passed when using cross site calls. This is required as well as setting the Access-Control-Allow-Origin h

[Greg Dove]

Actually I wasn't sure whether the compiler eliminated the dead js code.
But we know that it can.

I get the point about the 'swiss-army-knife' but I don't think that applies
here, because I think this is more a 'standard tool'. I can only directly
recall one Flex project in the last 6 years that did not require the swf
crossdomain security model. Perhaps I have forgotten some, but I suspect
that the world is becoming more interconnected, not less. I know there will
definitely be some who don't need this, and I guess there are certain types
of application that always will be single-domain. But unless I
misunderstand, it sounds like this need might be more for the majority than
the minority.

The point about the GCC stuff though I think is a little contrasting to the
PAYG philosphy elsewhere.

"AFAIK, public APIs have @export and are kept around.  Which will be a
good thing
in multi-module apps some day."

It sounds like we are keeping a lot of code that could be optimized or
automatically excluded because it will be a good thing "some day" (the day
when we support module loading). That sounds like the opposite of PAYG to
me, because many projects may not need 'module loading' (and we don't have
this yet anyway). I'm just trying to throw a potentially different way of
looking at this in here, because, in theory at least, the closure compiler
should be able to make a whole bunch of stuff go away in the release build
if it is not used (dead code elimination, DCE). In practice, I have not
tried it with any sizeable codebase, but I know other typedLanguage-toJS
compilers get the job done here, and I know that things like including
reflection data or not are also choices included in the options for output
in at least one other toJS compiler.

If this can work properly then we could actually have our cake and eat it
too. And yes the future might mean other things for modules, but perhaps
there are ways to get that working even with the renaming (DCE maybe not so
much, I agree).






On Mon, Apr 10, 2017 at 8:32 PM, Justin Mclean 
wrote:

> Hi,
>
> >  And the net result should be that code you didn't in your app, isn't in
> your app.
>
> As Greg pointed out the compiler can removed unused JS code i.e. methods
> that are not called. See for instance [1] for details. So in this case if
> you don’t use it will not end up in the AS code (as it’s JS only) and will
> not end up in production JS code.
>
> > So when you break stuff out into a bead, we want the net code size and
> performance for
> > someone not using the bead to be the same or better.
>
> In this case it is the same, if it was moved to a bead it would be worse
> for people who needed it. Only by tiny amounts but that’s the point you’re
> trying to make i.e. slow dead by a 1000 tiny additions, and as you say lots
> of people will need CORS support.
>
> > It is certainly worth revisiting the code we've written to see if other
> > stuff can be pulled out into beads, so thanks for reviewing HTTPService.
> > It is one of the early classes and probably needs a review.  Given the
> > above, my responses are inline below.
>
> We should provide clear documentation on this, currently there is none?
> Having our own code not following the same philosophy is a barrier for
> people contributing. In most other Apache projects if someone submits a
> patch that may not be “perfect” other committers will help to improve it.
> Pull request welcome and all that.
>
> > Possibly.  As long as the implementation for folks not using headers
> would
> > be smaller/faster.
>
> That is likely to be the case, but it will be slower for people who do use
> headers. How do we determine what is the most common use case? Isn’t that
> going to vary by use / customer so we going to end penalising someone no
> matter which way we go.
>
> > Possibly, but I claim that nobody should go into production without
> > supporting timeouts, so I would leave that baked in.
>
> So why does this not apply to the method I added? Every single project
> I’ve worked on has made cross domain calls. It's very uncommon for web
> applications to have their database, rest services, API calls on the same
> domain and quite common to call 3rd party services.
>
> And I’m sure no one would go into production without supporting security
> of some form. I’m concerned her that we are making security an optional
> feature here and not having it supported by default.
>
> > Again, if you can find a way to refactor that out without making the
> > HTTPService bigger/slower, then great.
>
> Anytime you place something in a bead it is going to be bigger and slower
> for the people that need that functionality. It will be faster/smaller for
> the others who don't. So again how do we determine what is the most common
> use case? Do more people use AIR status code than don’t use them? I would
> guess not in this case and it should be a bead but it’s just a guess.
>
> > Like Timeout, I claim that 

Re: git commit: [flex-asjs] [refs/heads/develop] - CORS security. Allow auth credentials to be passed when using cross site calls. This is required as well as setting the Access-Control-Allow-Origin h

[Greg Dove]

Just a general question about this type of thing:

Because this is JS-only, does GCC eliminate it as deadcode in a release
version if the method is never used? I would expect that, but I have not
checked that yet... if it does then perhaps the PAYG concern might be moot
(love that word!)

On Sun, Apr 9, 2017 at 4:48 PM, Alex Harui  wrote:

> IMO, with PAYG, this would go in an extension of HTTPService.  Not all
> apps will need CORS.
>
> Thanks,
> -Alex
>
> On 4/8/17, 8:26 PM, "jmcl...@apache.org"  wrote:
>
> >Repository: flex-asjs
> >Updated Branches:
> >  refs/heads/develop 11ef21aae -> 326d69791
> >
> >
> >CORS security. Allow auth credentials to be passed when using cross site
> >calls. This is required as well as setting the
> >Access-Control-Allow-Origin header on the server.
> >
> >
> >Project:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fgit-wip-us
> >.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Frepo=02%
> 7C01%7C%7C58994717190
> >044f003a908d47ef83ba7%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6362730
> >52005920291=eQwxowk79ikXeDxbqXV3OeVrXUzTXN
> fFR0eKzhU8wiw%3D=
> >0
> >Commit:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fgit-wip-us
> >.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Fcommit%
> 2F326d6979=02%7C01%7C%
> >7C58994717190044f003a908d47ef83ba7%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%
> >7C0%7C636273052005930299=f8udpkPpLcL1ivRV3LDW0kJARc8QnL
> hBDHVFGgCko7M
> >%3D=0
> >Tree:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fgit-wip-us
> >.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Ftree%2F326d6979&
> data=02%7C01%7C%7C
> >58994717190044f003a908d47ef83ba7%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C
> >0%7C636273052005930299=t6MMifwasbm2bgCuzsVN2q4%
> 2BCYcB2uB8o7O%2B%2BJu
> >yZ5w%3D=0
> >Diff:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fgit-wip-us
> >.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Fdiff%2F326d6979&
> data=02%7C01%7C%7C
> >58994717190044f003a908d47ef83ba7%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C
> >0%7C636273052005930299=gJDrCW4YbwaorNFSXVCVjLyq3lwTC6
> 7VhCRLEtYlcD0%3
> >D=0
> >
> >Branch: refs/heads/develop
> >Commit: 326d69791b37cc2aaac546bcfcd3a51e88716f2f
> >Parents: 11ef21a
> >Author: Justin Mclean 
> >Authored: Sun Apr 9 13:26:30 2017 +1000
> >Committer: Justin Mclean 
> >Committed: Sun Apr 9 13:26:30 2017 +1000
> >
> >--
> > .../src/main/flex/org/apache/flex/net/HTTPService.as   | 13
> +
> > 1 file changed, 13 insertions(+)
> >--
> >
> >
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fgit-wip-us
> >.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Fblob%2F326d6979%
> 2Fframeworks%2Fpro
> >jects%2FNetwork%2Fsrc%2Fmain%2Fflex%2Forg%2Fapache%2Fflex%
> 2Fnet%2FHTTPServ
> >ice.as=02%7C01%7C%7C58994717190044f003a908d47ef8
> 3ba7%7Cfa7b1b5a7b3443
> >8794aed2c178decee1%7C0%7C0%7C636273052005930299=
> TcDMCOEVbLKxedpsnACV
> >OmZon89YgUkvGxOtd%2F3Qky8%3D=0
> >--
> >diff --git
> >a/frameworks/projects/Network/src/main/flex/org/
> apache/flex/net/HTTPServic
> >e.as
> >b/frameworks/projects/Network/src/main/flex/org/
> apache/flex/net/HTTPServic
> >e.as
> >index b939751..3a9968c 100644
> >---
> >a/frameworks/projects/Network/src/main/flex/org/
> apache/flex/net/HTTPServic
> >e.as
> >+++
> >b/frameworks/projects/Network/src/main/flex/org/
> apache/flex/net/HTTPServic
> >e.as
> >@@ -505,6 +505,18 @@ package org.apache.flex.net
> >   return null;
> >   }
> >
> >+/**
> >+ *  Allows Javascript cross-site Access-Control requests to be
> >made
> >+ *  using credentials such as cookies or authorization headers
> >+ *
> >+ *  @productversion FlexJS 0.8
> >+ */
> >+COMPILE::JS
> >+public function set withCredentials(value:Boolean):void {
> >+var element:XMLHttpRequest = this.element as XMLHttpRequest;
> >+element.withCredentials = value;
> >+}
> >+
> > COMPILE::SWF
> > private var urlLoader:flash.net.URLLoader;
> >
> >@@ -606,6 +618,7 @@ package org.apache.flex.net
> > }
> > }
> >
> >+
> > if (_method !== HTTPConstants.GET &&
> > !sawContentType && contentData) {
> > element.setRequestHeader(
> >
>
>

Re: [FlexJX][FalconJX]

[Greg Dove]

Thanks, this was used in a local Log utility which is used for indirect
prefixing with info/warn etc. iirc I could not simply use trace
cross-platform for this approach, I think there were problems with
trace.apply for js (I would need to check, but this is what I recall) so I
ended up referencing console.log directly for js

I changed console.log to window.console.log  and that still gave 'No
GoogDep for window'
I think this use should be rare and trace will normally be used, so I added
'window' to NativeUtils and all was well. So I will commit this change.



On Wed, Mar 29, 2017 at 8:21 AM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 3/28/17, 12:12 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >
> >FWIW I tried with remove-circulars again but that broke on 'No GoogDep for
> >console' this time, but I guess you are still working on this.
>
> Actually, I would prefer that folks who hit "No GoogDep" fix it themselves
> by adding what they need to NativeUtils.java.  Although for console, I
> think you could also use "window.console".
>
> Thanks,
> -Alex
>
>

Re: [FlexJX][FalconJX]

[Greg Dove]

Thanks Alex,

I confirm this fixed things with the problem I described. I rebuilt Falcon
using maven, and after that, compiling without remove-circulars does not
have the issue I experienced prior.

It was important to clean the local project first (I only mention this
because I often forget to do this myself and others reading this may need
to remember to do the same).

FWIW I tried with remove-circulars again but that broke on 'No GoogDep for
console' this time, but I guess you are still working on this.

BTW I expect to be able to be more active on the project in the coming
weeks, but I won't be able to do very much specifically within the next
week or two because of looming client deadlines.
I will add tickets as I notice things (I can see some additional fixes in
the reflection area for instance, just have not investigated enough yet to
articulate them)


On Wed, Mar 29, 2017 at 6:13 AM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 3/28/17, 12:59 AM, "Greg Dove" <gregd...@apache.org> wrote:
>
> >Hi Alex, if you have time, perhaps you can shed some light on this?
> >
> >I have an mxml component using states, that implements an Interface,
> >IFormSequence.
> >
> >the generated CLASS_INFO looks like this:
> >FLEXJS_CLASS_INFO = { names: [{ name: 'ActionForm', qName:
> >'components.forms.ActionForm', kind: 'class'  }], interfaces:
> >[components.forms.IFormSequence] };
> >
> >and the goog.require for the interface is there at the top
> >goog.require('components.forms.IFormSequence');
> >
> >I notice that the
> >goog.addDependency('../../../components/forms/IFormSequence.js',
> >['components.forms.IFormSequence'], []);
> >
> >appears after the
> >goog.addDependency('../../../components/forms/ActionForm.js',
> >['components.forms.ActionForm'], ['org.apache.flex.html.Group']);
> >in the index.html.
> >Perhaps the order here is not important and goog resolves everything
> >somehow, but I did wonder if the dependency chain in for ActionForm.js
> >above should also contain the interface (that's a question, not a
> >suggestion - I don't know what is right here). At the moment there is an
> >issue where there is an interface check on startup when states or styles
> >or something like this are being initialized (it is actually a check for
> >a different interface, but because the 'interfaces' array is defined and
> >has length in CLASS_INFO it looks there and tries to follow follow the
> >inheritance chain on the undefined Interface reference, causing mayhem).
> >Because the reference inside the CLASS_INFO evaluates to undefined, I
> >know the dependencies are not loading in the right order.
>
> AFAIK, the order of addDependency not important.  The addDependency calls
> appear to build a lookup table that doesn't get used until evaluating the
> first goog.require.
>
> Without -remove-circulars, any class or interface reference that is
> actually used in the output should have a goog.require for it.  In the
> compiler, the usedNames list keeps track of which classes and interfaces
> are in the output.  Type references do not always end up in the output.
> For example, if the only reference in AS is "var foo:IMyInterface" then
> IMyInterface doesn't go in the output because we don't generate
> type-checking code.
>
> Starting last week, With -remove-circulars, only references via extends,
> implements, and static initializers go in the dependency list and retain
> goog.requires in the output.  But in this case, the interface should still
> be in the list.
>
> Anyway, the list of dependencies was broken until about two commits ago.
> So try again and see if it works.
> And not handling native JS types in static initializers was causing the
> exception in GetListOFFiles until my most recent commit.
>
> So pull down everything and see if the interface appears in the
> addDependency list again (without remove-circulars).
>
> HTH,
> -Alex
>
>

Re: Falcon build failing

[Greg Dove]

Harbs, I saw that error a short while ago, but I am not sure it is related
to the native classes.

Dependencies calculated for 'org.apache.flex.states.SetProperty'
org.apache.flex.states.SetProperty depends on org.apache.flex.core.IDocument
was all the appeared immediately before I saw it.

If you can avoid using remove-circulars (if that is an option for you) then
things might still work.

On Tue, Mar 28, 2017 at 9:29 PM, Harbs  wrote:

> It’s really weird: I can’t see anything in my app which relies on
> Uint8Array and  Uint32Array, and I’m still getting this error. :-(
>
> > On Mar 28, 2017, at 11:21 AM, Harbs  wrote:
> >
> > It was Josh’s tests that were tripping me up. The build fails after
> doing a wipe-all.
> >
> > I’ve been having other problems with Falcon, and the latest logging
> seems to shed some light on what’s wrong:
> >
> >  [java] Dependencies calculated for 'org.apache.flex.states.
> SetProperty'
> >  [java] org.apache.flex.states.SetProperty depends on
> org.apache.flex.core.IDocument
> >  [java] No GoogDep for Uint8Array
> >  [java] No GoogDep for Uint32Array
> >  [java] org.apache.flex.compiler.internal.graph.GoogDepsWriter.
> getListOfFiles(GoogDepsWriter.java:103)org.apache.flex.
> compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.publish(
> MXMLFlexJSPublisher.java:311)org.apache.flex.compiler.
> clients.MXMLJSC.compile(MXMLJSC.java:455)org.apache.
> flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:313)
> org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(
> MXMLJSC.java:270)org.apache.flex.compiler.clients.MXMLJSC.
> staticMainNoExit(MXMLJSC.java:232)org.apache.flex.compiler.
> clients.MXMLJSC.main(MXMLJSC.java:176)
> >
> > It looks like an app which depends on BinaryData will fail. I’m guessing
> that for some reason falcon is trying to add requires for native JS APIs.
> >
> > Harbs
> >
> >> On Mar 27, 2017, at 7:13 AM, Alex Harui > wrote:
> >>
> >>
> >>
> >> On 3/26/17, 1:19 PM, "Harbs" > wrote:
> >>
> >>> I’m having trouble building Falcon.
> >>>
> >>> It looks like it’s failing because a text in FlexJSTestBase.java is
> >>> failing. It’s looking for a file
> >>> flex-asjs/frameworks/as/basic-manifest.xml which does not exist.
> >>
> >> That output has been there for months.  It isn't the cause of a failure.
> >> You have to find the test results and check the output in there.
> >>
> >> -Alex
> >>
> >
>
>

[FlexJX][FalconJX]

[Greg Dove]

Hi Alex, if you have time, perhaps you can shed some light on this?

I have an mxml component using states, that implements an Interface, 
IFormSequence.

the generated CLASS_INFO looks like this:
FLEXJS_CLASS_INFO = { names: [{ name: 'ActionForm', qName: 
'components.forms.ActionForm', kind: 'class'  }], interfaces: 
[components.forms.IFormSequence] };

and the goog.require for the interface is there at the top
goog.require('components.forms.IFormSequence');

I notice that the 
goog.addDependency('../../../components/forms/IFormSequence.js', 
['components.forms.IFormSequence'], []);

appears after the 
goog.addDependency('../../../components/forms/ActionForm.js', 
['components.forms.ActionForm'], ['org.apache.flex.html.Group']);
in the index.html.
Perhaps the order here is not important and goog resolves everything somehow, 
but I did wonder if the dependency chain in for ActionForm.js above should also 
contain the interface (that's a question, not a suggestion - I don't know what 
is right here). At the moment there is an issue where there is an interface 
check on startup when states or styles or something like this are being 
initialized (it is actually a check for a different interface, but because the 
'interfaces' array is defined and has length in CLASS_INFO it looks there and 
tries to follow follow the inheritance chain on the undefined Interface 
reference, causing mayhem). Because the reference inside the CLASS_INFO 
evaluates to undefined, I know the dependencies are not loading in the right 
order. 

This was working last week so either it is something random/unlrelated 
elsewhere in the project that has changed the order, or the compiler has 
changed perhaps. Could your changes to goog.requires ordering have something to 
do with this, do you think?

I have not checked in the compiler to see if mxml "implements' is being treated 
the same as a regular actionscript 'implements' or if there are different code 
paths internally that might create differences for mxml based output vs regular 
AS, which was another thing I thought about here, because I think 'implements' 
is not often used in mxml. I'm happy to do that if you think that might warrant 
investigation, but figured I would check on whether you thought the other 
changes could be affecting this first.

Also, fyi, I was not using removeCirculars (although I don't *think* there are 
any circular references here and that part has not changed since it worked 
previously). fyi, when I tried remove circulars I got a compilation fail at 
org.apache.flex.compiler.internal.graph.GoogDepsWriter.getListOfFiles(GoogDepsWriter.java:103)

Re: [FlexJS] Summary of Changes

[Greg Dove]

I've just done a sweep through one project fixing our 'borked' stuff, I
guess the latest change might re-'bork' some of the fixes, but I think at
least these changes should be easier to address.

Sometimes I needed to swap a Container to a Group and other times not,
because of the relative/absolute changes.
I found it easier to migrate a lot of the layout stuff to pure css for now
using flexbox, thinking that doing so might insulate us from further
changes in the coded layout support. We would have the ability to swap back
to beads etc later if we want to have that in the mxml, once things have
become stable.


On Tue, Mar 28, 2017 at 9:52 AM, Peter Ent  wrote:

> Does the HTML look OK - the structure. Is there anything missing? You
> should see a simplified nesting of DIVs. If that's the case, then maybe
> there is more work to do with the layouts.
>
> The topmost Container, outer controls, doesn't look like it has a layout,
> so with Container that should default to BasicLayout. That's one thing to
> check.
>
> Does the Container with id scrollContainer have a parent somewhere with a
> fixed width and height? The auto margins should still work for HTML.
> Mostly the work is on the SWF side; the JS code was "cleaned up" so maybe
> that's the problem. I took out much of the algorithmic code for Vertical
> and Horizontal layout since I believe HTML would respond property to the
> addition of children, removal of children, resizing, etc. I did have, if I
> remember correctly, to add "white-space:nowrap" to the HorizontalLayout; I
> don't know that will affect you.
>
> Would you mind tinker with the HTML DOM in the browser to see if you can
> get the look you want? That will help determine if the layout code needs
> to be adjusted.
>
> Thanks and so sorry for the problems. *must use feature branch next time*
> —peter
>
> On 3/27/17, 4:35 PM, "Harbs"  wrote:
>
> >Better, but I still have some problems (there’s probably more):
> >
> >   
> >   
> >backgroundColor="0x44"/>
> >   
> >   
> >   
> >marginLeft="auto" marginRight="auto"/>
> >   
> >   
> >   
> >   
> >>click="undo_clickHandler(event)" id="undoButton"
> >src="assets/images/icons/0726-undo.svg">
> >   
> >   
> >   
> >   
> >>click="redo_clickHandler(event)" id="redoButton"
> >src="assets/images/icons/0727-redo.svg">
> >   
> >   
> >   
> >   
> >>click="zoomin_clickHandler(event)"
> >src="assets/images/icons/0806-zoom-in.svg"/>
> >>click="zoomout_clickHandler(event)"
> >src="assets/images/icons/0807-zoom-out.svg"/>
> >>click="fitButton_clickHandler(event)"
> >src="assets/images/icons/0843-expand.svg"/>
> >>click="previewButton_clickHandler(event)"
> >src="assets/images/icons/0786-file-preview-white.svg"/>
> >   
> >>click="finishButton_clickHandler()"
> >src="assets/images/icons/0821-check.svg"/>
> >   
> >>click="cancelButton_clickHandler()"
> >src="assets/images/icons/0822-cross2.svg"/>
> >   
> >
> >1. This used to create a centered group of buttons. Now, the container
> >has a height of 0 and the buttons don’t show up.
> >
> >2.
> >id="scrollContainer"
> >width="100%" height="100%">
> >   
> >   
> >   
> >id="designContainer"
> >className="_holder" y="0">
> >   
> >
>  
> >   
> >   
> >
> >   
> >
> >This used to create a scrolling div that was centered in the the window.
> >It now is aligned left, and I don’t know if it scrolls.
> >
> >There’s other issues, and I’ll see tomorrow what I can work around.
> >
> >> On Mar 27, 2017, at 11:08 PM, Peter Ent  wrote:
> >>
> >> Hi,
> >>
> >> I just pushed a change to UIBase to set position="absolute" when
> >>setting x
> >> or y. I think this is perfectly safe and if someone does set x and y and
> >> then tries to use a 

Re: Typedef issue causing flex-asjs to fail to compile

[Greg Dove]

Alex, I pushed this change, using undefined as discussed in the ticket.
The standard compiler tests all pass, but there is, I think, an unrelated test
in flexjs.dependent.tests that is currently failing
in TestFlexJSMXMLApplication (I admit that I did not revert my change to
check it was occurring prior, but I can't see how it could be related)
It is a css in/css out comparison test.
As near as I can tell the failing css test had the correct css settings in
the output, but the order of them does not always match the expected output
(it does for the most part). So height:176px might appear before color:#ff
in expected result in some parts and occurs the other way around in the
corresponding part of the output, but the expected items are all there. I
did not dig into this, but I perhaps the ordering was changed or some new
functionality was added where perhaps ordering of output was not
guaranteed.




On Tue, Mar 21, 2017 at 3:56 AM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 3/20/17, 12:00 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >I agree that 10 is wrong, but
> >reading both AS and JS doc, I'm now thinking that if the second argument
> >is missing that the compiler should use 0.
>
> +1.  Let's use 0.
>
> Thanks for doing such a through investigation.
> -Alex
>
>

Re: Typedef issue causing flex-asjs to fail to compile

[Greg Dove]

I agree that 10 is wrong, but
reading both AS and JS doc, I'm now thinking that if the second argument
is missing that the compiler should use 0.

Please see the note in the comment of this ticket[1]:
We need to decide whether we should add undefined as the second param (it
seems this is the preferred option by GCC instead of zero, I am not sure
why other than that they specify it) or possibly use the GCL version of
parseInt in these cases for full backwards compatibility with older
browsers.
What are your thoughts about this?

1.
https://issues.apache.org/jira/browse/FLEX-35283?focusedCommentId=15932208=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15932208

Re: Typedef issue causing flex-asjs to fail to compile

[Greg Dove]

to clarify :

I got the typedefs building eventually and compiling the single arg
signature for partseInt is fine, but the compiler makes a fixed assumption
for 10 radix for any string and adds that second param instead of allowing
the native implementation to do its thing.

If there are string formats like octal that get inferred differently from
the string in js but not in swf then that complicates things but if they
are identical (and if there is no requirement to have the js output *not*
have an optional argument) then the simplest thing of course is to pass it
through unchanged.

I will check the various browsers and permutations this weekend to see what
happens. I already added a ticket for me




On Wed, Mar 15, 2017 at 7:03 PM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 3/14/17, 10:42 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >On Wed, Mar 15, 2017 at 6:33 PM, Alex Harui <aha...@adobe.com> wrote:
> >
> >> Here's a better link to the old thread.  Looks like I did mess around
> >>with
> >> parseInt earlier.
> >>
> >> https://s.apache.org/rHq2
> >>
> >>
> >> The goal is to match what AS does and get the performance benefit you
> >> measured and maybe prevent browsers from doing something strange.
> >>
> >> Hopefully it won't require sniffing the first parameter ourselves.
> >>
> >> Thanks,
> >> -Alex
> >>
> >>
> >>
> >Thanks for that link, the original was not working for me.
> >In theory it should simply take the string and deduce the radix internally
> >depending on whether the string has '0x' at the start or not. That's why
> >specifying the radix should always be faster.
> >But we cannot assume it is 10 for all strings in a compiler generated
> >version with the (apparently) mandatory second param for GCL.
> >
> >So it is a bit of challenge if we want to keep the AS behaviour, and if
> >the
> >GCL lib does not like having the second arg missing.
> >Basically for perfomance you need to specify the second param in the
> >native
> >version and that obviously will always be the better option.
> >I think the compiler generated version will need to do some sniffing
> >unfortunately, (if we are to keep behaviour) and will make that
> >performance
> >difference even more true, but will give it a bit more thought.
> >.
>
> I don't think there is any code at runtime that requires the second
> argument.  We patch the files in the JS.swc so the second argument is
> optional.  AFAIK, in the actual browser, the second parameter is optional.
>  IMO, what you see in the original externs is Google's policy for their
> developers, not a runtime API spec.  But you can see in the old thread
> that MDN says you really "should" set a second parameter.
>
> Somehow, that parseInt patch didn't work for Justin and you.  So that's
> the first problem.  Your flex-typedefs/js build should generate a
> parseInt.as with an optional second argument because the es3.js is patched
> to have an optional second argument.
>
> Then we can discuss whether the compiler should set 10 or 0 or trust the
> modern browsers to not think Octal or be unpredictable.  Or make some
> other tradeoff like saying we're going to set 10 and you can't assume
> auto-conversion in FlexJS.  Either way, we should clean up where we are
> using parseInt(, 10) in the FlexJS framework code.
>
> If you have time, it might be worth doing some tests in Flash and browser
> to see if you can set 10 in Flash and it will still sniff out hex, and
> whether using 0 works the same in both AS and JS.  We have set a browser
> baseline of IE9 so we don't have to worry about really old browsers.
>
> Thanks,
> -Alex
>
>

Re: Typedef issue causing flex-asjs to fail to compile

[Greg Dove]

On Wed, Mar 15, 2017 at 6:33 PM, Alex Harui  wrote:

> Here's a better link to the old thread.  Looks like I did mess around with
> parseInt earlier.
>
> https://s.apache.org/rHq2
>
>
> The goal is to match what AS does and get the performance benefit you
> measured and maybe prevent browsers from doing something strange.
>
> Hopefully it won't require sniffing the first parameter ourselves.
>
> Thanks,
> -Alex
>
>
>
Thanks for that link, the original was not working for me.
In theory it should simply take the string and deduce the radix internally
depending on whether the string has '0x' at the start or not. That's why
specifying the radix should always be faster.
But we cannot assume it is 10 for all strings in a compiler generated
version with the (apparently) mandatory second param for GCL.

So it is a bit of challenge if we want to keep the AS behaviour, and if the
GCL lib does not like having the second arg missing.
Basically for perfomance you need to specify the second param in the native
version and that obviously will always be the better option.
I think the compiler generated version will need to do some sniffing
unfortunately, (if we are to keep behaviour) and will make that performance
difference even more true, but will give it a bit more thought.
.

Re: Typedef issue causing flex-asjs to fail to compile

[Greg Dove]

>
> I'm not sure what you are referring to.  I don't think the compiler
> currently supplies the second argument.  I didn't think it was needed, but
> your tests indicate otherwise, so if that's what you are referring to,
> please file a JIRA so we don't forget to do it.
>
>
>
It seems it does - it did in that small test I tried and looks like the
compiler-jx tests are set up to expect this. But I did not look at the code
yet.
I will add a JIRA

Re: Typedef issue causing flex-asjs to fail to compile

[Greg Dove]

If the compiler outputs 10 for everything then it is different to
actionscript which checks for "0x" and decides on 16 or 10
We can change the behaviour, but it won't be identical to :
"Strings beginning with 0x are interpreted as hexadecimal numbers"

Maybe it is better to not support '0x' strings and make developers check
and specify the 16 radix on the substringsbut it is not consistent with
orignal version


On Wed, Mar 15, 2017 at 6:07 PM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 3/14/17, 9:54 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Alex, I agree, it seems whatever prompted this was elsewhere, but the
> >outcome is IMO (a small amount of) better framework code in CSSUtils.
> >I would take this as a small win - nothing is broken, and a utility method
> >is theoretically slightly faster.
>
> I am still confused.  If the compiler should output JS that specifies 10
> for the second parameter if not specified because that will net
> better/faster code we should definitely do that.  But I don't understand
> any reason to actually add the second parameter in the ActionScript source.
>
> Thanks,
> -Alex
>
>

Re: Typedef issue causing flex-asjs to fail to compile

[Greg Dove]

  var test :String = "0x99"
trace(parseInt(test));

gives :
  var /** @type {string} */ test = "0x99";
  org.apache.flex.utils.Language.trace(parseInt(test, 10));

which is wrong

I can take a look at it this weekend if no-one else gets to it


On Wed, Mar 15, 2017 at 6:02 PM, Greg Dove <greg.d...@gmail.com> wrote:

> Actually I just checked and it looks like there is a bug in the compiler
> for this
>
>
>
> Greg Dove
> Dove Software Development Ltd
> http://greg-dove.com
>
> On Wed, Mar 15, 2017 at 5:54 PM, Greg Dove <greg.d...@gmail.com> wrote:
>
>> Alex, I agree, it seems whatever prompted this was elsewhere, but the
>> outcome is IMO (a small amount of) better framework code in CSSUtils.
>> I would take this as a small win - nothing is broken, and a utility
>> method is theoretically slightly faster.
>>
>>
>> On Wed, Mar 15, 2017 at 5:19 PM, Alex Harui <aha...@adobe.com> wrote:
>>
>>> Thanks for running the test.  Maybe I'm not understanding the issue, but
>>> here's my summary.
>>>
>>> Justin was getting a compile error where code that was known to work
>>> wouldn't compile because there was only one argument passed to parseInt
>>> in
>>> ActionScript source.
>>>
>>> ActionScript defines parseInt as having one required parameter and one
>>> default parameter so it should have compiled.
>>>
>>> Thus, the compile error was likely due to the bad typedefs build Justin
>>> referred to earlier in a separate thread.
>>>
>>> It would not be my recommendation to have us add default parameters to
>>> all
>>> of the places we could for "code clarity" or performance. Folks who write
>>> code in ActionScript should know or can find from the documentation that,
>>> for example, the second parameter to parseInt is optional and thus would
>>> wonder why someone bothered to add it.  If the second parameter isn't
>>> there, the assumption should be that the default parameter is used.
>>>
>>> Now, if there is a performance advantage to having the output JS always
>>> set 10 if the second parameter is not specified to parseInt, then that
>>> sounds like a good idea.  Please file a JIRA so we don't forget.
>>>
>>> But, IMO, we are writing ActionScript and we should not make a practice
>>> of
>>> supplying default parameters.  Please figure out why your typedefs aren't
>>> building and remove the optional parameter for parseInt from CSSUtils.as.
>>>
>>> Thanks,
>>> -Alex
>>>
>>>
>>> On 3/14/17, 8:24 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>>>
>>> >I think code clarity is one thing, but performance is another - that
>>> >should
>>> >be faster, so I ran a quick check.
>>> >
>>> >I know it can vary across browsers, but
>>> >
>>> >var timeOne = function(){var d=new Date();var b=0; for (var
>>> >i=0;i<1000;i++) {b= parseInt(""+(127/255)*1000, 10) / 1000;}
>>> >console.log(new Date().getTime()-d.getTime());}
>>> >timeOne()
>>> >approx 715 ms in my chrome over multiple runs
>>> >
>>> >var timeTwo = function(){var d=new Date();var b=0; for (var
>>> >i=0;i<1000;i++) {b= parseInt(""+(127/255)*1000) / 1000;}
>>> >console.log(new Date().getTime()-d.getTime());}
>>> >timeTwo ()
>>> >approx 870 ms in my chrome over multiple runs
>>> >
>>> >so (within the limits of this *very* basic test) I say keep it, for
>>> >clarity
>>> >and speed (about 20% faster)
>>> >
>>> >On Wed, Mar 15, 2017 at 3:26 PM, Justin Mclean <
>>> jus...@classsoftware.com>
>>> >wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> > Please revert CSSUtils and investigate why parseInt is requiring the
>>> >> second argument.
>>> >>
>>> >> Even if it is a typedef bug IMO passing the base there makes the code
>>> >> intent clearer as the code is dealing with both base 16 and base 10
>>> >>numbers.
>>> >>
>>> >> This is the code in question:
>>> >> public static function attributeFromColor(value:uint):String
>>> >> {
>>> >> var hexVal:String = value.toString(16);
>>> >> if(value > 16777215)
>>> >> {
>>> >> //rgba -- return rgba notation
>>> >> var rgba:Array = hexVal.match(/.{2}/g);
>>> >> for(var i:int = 0; i < 4; i++)
>>> >> {
>>> >> rgba[i] = parseInt(rgba[i], 16);
>>> >> }
>>> >> rgba[3] = parseInt(""+(rgba[3]/255)*1000, 10) / 1000;
>>> >> return "rgba(" + rgba.join(",") + ")";
>>> >> }
>>> >> return "#" + StringPadder.pad(hexVal,"0",6);
>>> >> }
>>> >>
>>> >> I added the “,10” to the second parseInt.
>>> >>
>>> >> What do others think? Should it stay or should it go?
>>> >>
>>> >> Thanks,
>>> >> Justin
>>>
>>>
>>
>

Re: Typedef issue causing flex-asjs to fail to compile

[Greg Dove]

Actually I just checked and it looks like there is a bug in the compiler
for this



Greg Dove
Dove Software Development Ltd
http://greg-dove.com

On Wed, Mar 15, 2017 at 5:54 PM, Greg Dove <greg.d...@gmail.com> wrote:

> Alex, I agree, it seems whatever prompted this was elsewhere, but the
> outcome is IMO (a small amount of) better framework code in CSSUtils.
> I would take this as a small win - nothing is broken, and a utility method
> is theoretically slightly faster.
>
>
> On Wed, Mar 15, 2017 at 5:19 PM, Alex Harui <aha...@adobe.com> wrote:
>
>> Thanks for running the test.  Maybe I'm not understanding the issue, but
>> here's my summary.
>>
>> Justin was getting a compile error where code that was known to work
>> wouldn't compile because there was only one argument passed to parseInt in
>> ActionScript source.
>>
>> ActionScript defines parseInt as having one required parameter and one
>> default parameter so it should have compiled.
>>
>> Thus, the compile error was likely due to the bad typedefs build Justin
>> referred to earlier in a separate thread.
>>
>> It would not be my recommendation to have us add default parameters to all
>> of the places we could for "code clarity" or performance. Folks who write
>> code in ActionScript should know or can find from the documentation that,
>> for example, the second parameter to parseInt is optional and thus would
>> wonder why someone bothered to add it.  If the second parameter isn't
>> there, the assumption should be that the default parameter is used.
>>
>> Now, if there is a performance advantage to having the output JS always
>> set 10 if the second parameter is not specified to parseInt, then that
>> sounds like a good idea.  Please file a JIRA so we don't forget.
>>
>> But, IMO, we are writing ActionScript and we should not make a practice of
>> supplying default parameters.  Please figure out why your typedefs aren't
>> building and remove the optional parameter for parseInt from CSSUtils.as.
>>
>> Thanks,
>> -Alex
>>
>>
>> On 3/14/17, 8:24 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>>
>> >I think code clarity is one thing, but performance is another - that
>> >should
>> >be faster, so I ran a quick check.
>> >
>> >I know it can vary across browsers, but
>> >
>> >var timeOne = function(){var d=new Date();var b=0; for (var
>> >i=0;i<1000;i++) {b= parseInt(""+(127/255)*1000, 10) / 1000;}
>> >console.log(new Date().getTime()-d.getTime());}
>> >timeOne()
>> >approx 715 ms in my chrome over multiple runs
>> >
>> >var timeTwo = function(){var d=new Date();var b=0; for (var
>> >i=0;i<1000;i++) {b= parseInt(""+(127/255)*1000) / 1000;}
>> >console.log(new Date().getTime()-d.getTime());}
>> >timeTwo ()
>> >approx 870 ms in my chrome over multiple runs
>> >
>> >so (within the limits of this *very* basic test) I say keep it, for
>> >clarity
>> >and speed (about 20% faster)
>> >
>> >On Wed, Mar 15, 2017 at 3:26 PM, Justin Mclean <jus...@classsoftware.com
>> >
>> >wrote:
>> >
>> >> Hi,
>> >>
>> >> > Please revert CSSUtils and investigate why parseInt is requiring the
>> >> second argument.
>> >>
>> >> Even if it is a typedef bug IMO passing the base there makes the code
>> >> intent clearer as the code is dealing with both base 16 and base 10
>> >>numbers.
>> >>
>> >> This is the code in question:
>> >> public static function attributeFromColor(value:uint):String
>> >> {
>> >> var hexVal:String = value.toString(16);
>> >> if(value > 16777215)
>> >> {
>> >> //rgba -- return rgba notation
>> >> var rgba:Array = hexVal.match(/.{2}/g);
>> >> for(var i:int = 0; i < 4; i++)
>> >> {
>> >> rgba[i] = parseInt(rgba[i], 16);
>> >> }
>> >> rgba[3] = parseInt(""+(rgba[3]/255)*1000, 10) / 1000;
>> >> return "rgba(" + rgba.join(",") + ")";
>> >> }
>> >> return "#" + StringPadder.pad(hexVal,"0",6);
>> >> }
>> >>
>> >> I added the “,10” to the second parseInt.
>> >>
>> >> What do others think? Should it stay or should it go?
>> >>
>> >> Thanks,
>> >> Justin
>>
>>
>

Re: Typedef issue causing flex-asjs to fail to compile

[Greg Dove]

Alex, I agree, it seems whatever prompted this was elsewhere, but the
outcome is IMO (a small amount of) better framework code in CSSUtils.
I would take this as a small win - nothing is broken, and a utility method
is theoretically slightly faster.


On Wed, Mar 15, 2017 at 5:19 PM, Alex Harui <aha...@adobe.com> wrote:

> Thanks for running the test.  Maybe I'm not understanding the issue, but
> here's my summary.
>
> Justin was getting a compile error where code that was known to work
> wouldn't compile because there was only one argument passed to parseInt in
> ActionScript source.
>
> ActionScript defines parseInt as having one required parameter and one
> default parameter so it should have compiled.
>
> Thus, the compile error was likely due to the bad typedefs build Justin
> referred to earlier in a separate thread.
>
> It would not be my recommendation to have us add default parameters to all
> of the places we could for "code clarity" or performance. Folks who write
> code in ActionScript should know or can find from the documentation that,
> for example, the second parameter to parseInt is optional and thus would
> wonder why someone bothered to add it.  If the second parameter isn't
> there, the assumption should be that the default parameter is used.
>
> Now, if there is a performance advantage to having the output JS always
> set 10 if the second parameter is not specified to parseInt, then that
> sounds like a good idea.  Please file a JIRA so we don't forget.
>
> But, IMO, we are writing ActionScript and we should not make a practice of
> supplying default parameters.  Please figure out why your typedefs aren't
> building and remove the optional parameter for parseInt from CSSUtils.as.
>
> Thanks,
> -Alex
>
>
> On 3/14/17, 8:24 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >I think code clarity is one thing, but performance is another - that
> >should
> >be faster, so I ran a quick check.
> >
> >I know it can vary across browsers, but
> >
> >var timeOne = function(){var d=new Date();var b=0; for (var
> >i=0;i<1000;i++) {b= parseInt(""+(127/255)*1000, 10) / 1000;}
> >console.log(new Date().getTime()-d.getTime());}
> >timeOne()
> >approx 715 ms in my chrome over multiple runs
> >
> >var timeTwo = function(){var d=new Date();var b=0; for (var
> >i=0;i<1000;i++) {b= parseInt(""+(127/255)*1000) / 1000;}
> >console.log(new Date().getTime()-d.getTime());}
> >timeTwo ()
> >approx 870 ms in my chrome over multiple runs
> >
> >so (within the limits of this *very* basic test) I say keep it, for
> >clarity
> >and speed (about 20% faster)
> >
> >On Wed, Mar 15, 2017 at 3:26 PM, Justin Mclean <jus...@classsoftware.com>
> >wrote:
> >
> >> Hi,
> >>
> >> > Please revert CSSUtils and investigate why parseInt is requiring the
> >> second argument.
> >>
> >> Even if it is a typedef bug IMO passing the base there makes the code
> >> intent clearer as the code is dealing with both base 16 and base 10
> >>numbers.
> >>
> >> This is the code in question:
> >> public static function attributeFromColor(value:uint):String
> >> {
> >> var hexVal:String = value.toString(16);
> >> if(value > 16777215)
> >> {
> >> //rgba -- return rgba notation
> >> var rgba:Array = hexVal.match(/.{2}/g);
> >> for(var i:int = 0; i < 4; i++)
> >> {
> >> rgba[i] = parseInt(rgba[i], 16);
> >> }
> >> rgba[3] = parseInt(""+(rgba[3]/255)*1000, 10) / 1000;
> >> return "rgba(" + rgba.join(",") + ")";
> >> }
> >> return "#" + StringPadder.pad(hexVal,"0",6);
> >> }
> >>
> >> I added the “,10” to the second parseInt.
> >>
> >> What do others think? Should it stay or should it go?
> >>
> >> Thanks,
> >> Justin
>
>

Re: Typedef issue causing flex-asjs to fail to compile

[Greg Dove]

I think code clarity is one thing, but performance is another - that should
be faster, so I ran a quick check.

I know it can vary across browsers, but

var timeOne = function(){var d=new Date();var b=0; for (var
i=0;i<1000;i++) {b= parseInt(""+(127/255)*1000, 10) / 1000;}
console.log(new Date().getTime()-d.getTime());}
timeOne()
approx 715 ms in my chrome over multiple runs

var timeTwo = function(){var d=new Date();var b=0; for (var
i=0;i<1000;i++) {b= parseInt(""+(127/255)*1000) / 1000;}
console.log(new Date().getTime()-d.getTime());}
timeTwo ()
approx 870 ms in my chrome over multiple runs

so (within the limits of this *very* basic test) I say keep it, for clarity
and speed (about 20% faster)

On Wed, Mar 15, 2017 at 3:26 PM, Justin Mclean 
wrote:

> Hi,
>
> > Please revert CSSUtils and investigate why parseInt is requiring the
> second argument.
>
> Even if it is a typedef bug IMO passing the base there makes the code
> intent clearer as the code is dealing with both base 16 and base 10 numbers.
>
> This is the code in question:
> public static function attributeFromColor(value:uint):String
> {
> var hexVal:String = value.toString(16);
> if(value > 16777215)
> {
> //rgba -- return rgba notation
> var rgba:Array = hexVal.match(/.{2}/g);
> for(var i:int = 0; i < 4; i++)
> {
> rgba[i] = parseInt(rgba[i], 16);
> }
> rgba[3] = parseInt(""+(rgba[3]/255)*1000, 10) / 1000;
> return "rgba(" + rgba.join(",") + ")";
> }
> return "#" + StringPadder.pad(hexVal,"0",6);
> }
>
> I added the “,10” to the second parseInt.
>
> What do others think? Should it stay or should it go?
>
> Thanks,
> Justin

Re: flex-typedefs build failing

[Greg Dove]

I am seeing this also. It almost feels like it is applying the patch on
download and then trying again (but I have really no idea)


ant build works fine with some warnings about LoggerErrorManager println
but I could not get regular maven build to work


One way I could get the mvn build to work was this, which might provide
some clues?:

mvn clean
cd js
ant download
cd..
cd google_maps
ant download
cd..
mvn install

that was fun :)


On Wed, Mar 15, 2017 at 6:51 AM, Alex Harui  wrote:

> Are you running "mvn clean install" or something else?  I don't remember
> what part of the build brings down svg.js and patches it, but if you don't
> bring down svg.js each time, the patch will not apply the second time.
>
> HTH,
> -Alex
>
> On 3/14/17, 5:58 AM, "Justin Mclean"  wrote:
>
> >Hi,
> >
> >Is it just me or is flex-typedefs currently broken? Looks like the patch
> >file may need updating?
> >
> >When trying to compile (on develop) I get this:
> >[INFO] --- exec-maven-plugin:1.5.0:exec (patch-js) @ flexjs-typedefs-js
> >---
> >error: patch failed: js/target/downloads/svg.js:401
> >error: js/target/downloads/svg.js: patch does not apply
> >[ERROR] Command execution failed.
> >
> >Thanks,
> >Justin
>
>

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Greg Dove]

Thanks Alex, much appreciated


On Wed, Mar 8, 2017 at 7:24 PM, Alex Harui <aha...@adobe.com> wrote:

> OK.  I'll take care of it.
>
> On 3/7/17, 10:11 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Yes, I think they are errors with the tests.
> >
> >iirc it was
> >
> >
> >
> >
> >
> >or something like that. So I think the new code is picking up the right
> >things :)
> >
> >I am struggling for time right now, if you have time that would be
> >fantastic, otherwise I will try to get to it later tonight.
> >
> >
> >
> >
> >
> >
> >
> >On Wed, Mar 8, 2017 at 7:06 PM, Alex Harui <aha...@adobe.com> wrote:
> >
> >> Greg,
> >>
> >> I just realized that these might be legitimate errors.  I can fix them
> >>if
> >> you don't have time.
> >>
> >> -Alex
> >>
> >> On 3/7/17, 1:32 PM, "Alex Harui" <aha...@adobe.com> wrote:
> >>
> >> >
> >> >
> >> >On 3/7/17, 1:04 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
> >> >
> >> >>I had never run those tests specifically - I was not even aware of
> >>those
> >> >>yet, the unit tests run during ant all build had proceeded without
> >> >>problems:
> >> >
> >> >There are three sets of unit tests.  Because the compiler is needed to
> >> >build the AS framework, we can't have the compiler tests require the AS
> >> >framework, so the set of tests that runs automatically don't have any
> >>AS
> >> >framework dependencies, then there is a set of tests with flex-sdk
> >> >dependencies and one with flex-asjs dependencies, which is what you
> >>just
> >> >ran.
> >> >
> >> >Ignore the "Unable to parse" for now.
> >> >
> >> >IMO, no need to revert the changes.  I've got plenty of other things to
> >> >do.
> >> >
> >> >Thanks for digging into it.
> >> >-Alex
> >> >
> >>
> >>
>
>

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Greg Dove]

Yes, I think they are errors with the tests.

iirc it was





or something like that. So I think the new code is picking up the right
things :)

I am struggling for time right now, if you have time that would be
fantastic, otherwise I will try to get to it later tonight.







On Wed, Mar 8, 2017 at 7:06 PM, Alex Harui <aha...@adobe.com> wrote:

> Greg,
>
> I just realized that these might be legitimate errors.  I can fix them if
> you don't have time.
>
> -Alex
>
> On 3/7/17, 1:32 PM, "Alex Harui" <aha...@adobe.com> wrote:
>
> >
> >
> >On 3/7/17, 1:04 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
> >
> >>I had never run those tests specifically - I was not even aware of those
> >>yet, the unit tests run during ant all build had proceeded without
> >>problems:
> >
> >There are three sets of unit tests.  Because the compiler is needed to
> >build the AS framework, we can't have the compiler tests require the AS
> >framework, so the set of tests that runs automatically don't have any AS
> >framework dependencies, then there is a set of tests with flex-sdk
> >dependencies and one with flex-asjs dependencies, which is what you just
> >ran.
> >
> >Ignore the "Unable to parse" for now.
> >
> >IMO, no need to revert the changes.  I've got plenty of other things to
> >do.
> >
> >Thanks for digging into it.
> >-Alex
> >
>
>

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Greg Dove]

I had never run those tests specifically - I was not even aware of those
yet, the unit tests run during ant all build had proceeded without problems:

I am seeing this:

[junit] Running
org.apache.flex.compiler.internal.codegen.js.flexjs.TestFlexJSFile
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
4.76 sec
[junit] Running
org.apache.flex.compiler.internal.codegen.mxml.flexjs.TestFlexJSMXMLApplication
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] In initializer for 'basic:initialView', type
org.apache.flex.html.Label is not assignable to target type
'org.apache.flex.core.IApplicationView'.
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] In initializer for 'basic:initialView', type
org.apache.flex.html.Label is not assignable to target type
'org.apache.flex.core.IApplicationView'.
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] In initializer for 'basic:initialView', type
org.apache.flex.html.Label is not assignable to target type
'org.apache.flex.core.IApplicationView'.
[junit] Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml
[junit] In initializer for 'basic:initialView', type
org.apache.flex.html.Label is not assignable to target type
'org.apache.flex.core.IApplicationView'.

I am not sure what 'Unable to parse
D:\FLEXSDKS\_asf\flex-asjs\frameworks\as\basic-manifest.xml' is yet.

but the errors are related to my changes, but also seems like they found
something valid. I can look into this in a about 5-6 hours time. Do you
need me to revert the commit until I get a chance to address those tests?


On Wed, Mar 8, 2017 at 9:53 AM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 3/7/17, 9:41 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Anything else I should be doing?
>
> If you are using Ant to build flex-falcon, please run
>
>ant flexjs.dependent.tests
>
> This may require setting up an ASJS_HOME environment variable or setting
> in env.properties to point to the flex-asjs repo that has previously been
> built so it as the SWCs.
>
> The flex-falcon build just failed.  Not sure if it is due to your changes.
>
> Thanks,
> -Alex
>
>

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Greg Dove]

Anything else I should be doing?

One thing I did not check (and generally have not checked specifically with
anything I did so far in FlexJS) is anything to do with inline
(fx:Component) mxml.

I *think* there are some unit tests for these, I would need to double
check but if you are using that anywhere it would just be helpful to
know that things work correctly inside that. I was intending to come back
and check this explicitly and also maybe add some new unit tests to the
compiler for these new errors.

Aside from that, no, there is nothing specific, apart from making sure that
your app compiles and runs as expected.
In theory, if you got errors on re-compile with the new code, it should
only be helping you. If you get no errors, then you can be more reassured
that your mxml is good (which I am sure it was anyway) :)



On Mon, Mar 6, 2017 at 10:07 PM, Harbs <harbs.li...@gmail.com> wrote:

> I have noticed that MXML compiling does not produce the greatest error
> reports. I should have recorded issues as I saw them, but I didn’t. :-(
>
> These two cases make sense to me, and thanks for fixing them. I’ll be
> happy to update falcon and make sure that things still compile correctly in
> my apps. Anything else I should be doing?
>
> > On Mar 6, 2017, at 10:40 AM, Greg Dove <greg.d...@gmail.com> wrote:
> >
> > "It sound to me like you know what you’re talking about"
> >
> > Haha, Harbs that's probably more reassuring to me than it should be to
> you.
> > In terms of anything at all in the compiler, I am still LAYG (learning as
> > you go) here ;)
> > (btw, you can never have too many 'as you go' acronyms)
> >
> > I actually shared Alex's general concerns over making changes in the mxml
> > parsing, we don't have a large range of tests to cover all the potential
> > mxml variations (otherwise I expect this would have already been
> addressed).
> >
> > Harbs, I understand that you have a (quite possibly) large codebase so
> you
> > might provide the best real-world 'litmus test' in you have a large
> amount
> > of mxml.
> >
> >
> > In simple terms the changes will prevent the following 2 examples from
> > compiling, which currently compile fine in FlexJS, but should not:
> >
> > 
> >
> >
> > 
> >
> > in the above example the view2 instance was being created and assigned
> for
> > the initialView propertty, the first was ignored
> >
> > 
> >
> > 
> >
> > In this case the types are incompatible.
> >
> > I actually think the compiler errors for mxml could be more important
> than
> > a sesaoned Flex user would assume in terms of how new people will form
> > early impressions. When people who potentially don't know actionscript
> > (yet) take some FlexJS examples for a spin, they are probably going to
> look
> > at the mxml and think to themselves 'I can do that', so it will be the
> > first thing they mess with. Mxml-related errors might be the first thing
> > they see from the compiler after they start messing with stuff.
> > That's why I spent a bit of time discussing those...I have gone ahead and
> > gone with the two new ones as I suggested.
> >
> >
> >
> > On Mon, Mar 6, 2017 at 12:08 AM, Harbs <harbs.li...@gmail.com> wrote:
> >
> >> I have to admit that you lost me pretty quickly… ;-)
> >>
> >> It sound to me like you know what you’re talking about, so I’m fine with
> >> whatever you did/want to do… :-)
> >>
> >> Harbs
> >>
> >>> On Mar 5, 2017, at 9:31 AM, Greg Dove <greg.d...@gmail.com> wrote:
> >>>
> >>> OK please brace yourself for an onslaught of text.
> >>>
> >>> I tested across Flex 4 and FlexJS through a bunch of variations. This
> >>> change passes all tests. In the end this is a very small and isolated
> >> code
> >>> change (I am almost certain it will not contribute to anyone's merge
> >>> conflicts) and I believe it gives greater compile-time type safety to
> >> mxml,
> >>> so I think it's necessary. But the error descriptions are open for more
> >>> input/review... I have favored a strong consistency with the Flex 4
> >>> descriptions, which were specific for mxml, over using the related
> >>> actionscript descriptions.
> >>>
> >>> BTW I had forgotten, but there was also a comment (it was not marked
> as a
> >>> todo) in the falcon MXMLPropertySpecifierNode class that indicated that
> >>> this type of work still needed to be 

Re: git commit: [flex-asjs] [refs/heads/develop] - Add JS support for non pixel numeric properties ie fontWeight

[Greg Dove]

I'm going to throw a comment in here from the sidelines

At the end of reading this, you might think it seems like a trivial
suggestion, but here goes anyway:

I understand the logic in striving for a basic set of browser/swf
compatible styles and I agree with the need. But I actually don't think it
deserves the name 'Simple', and that this naming may be part of the reason
people are coming at this from different directions.

Simple has two general meanings:
-plain/basic
-easy/not difficult

I don't know for sure, but I suspect the original choice of 'Simple' here
was in the 'plain or basic' sense, with a sense of constraint to support
both swf and js targets. But I'm not sure this is been the general
interpretation..

For someone trying to target JS first and not so concerned about SWF,
SimpleCSSStylesImpl may not be an easy option, it would be 'constrained' or
'restricted' perhaps.
I think it probably needs to be called what it is :SWFCompatibleCSSImpl
(given that js side has the 'super-set') or even CrossPlatformCSSImpl or
something like this.

Then the name of the class would make it clear to people using it what to
expect, and to people contributing to the framework what should go in it,
and what should not.
I suspect if it was named something like that you ("constant reader") would
never have ended up reading this thread.

Just a thought, anyway...



On Mon, Mar 6, 2017 at 7:45 PM, Alex Harui  wrote:

>
>
> On 3/5/17, 10:11 PM, "Justin Mclean"  wrote:
>
> >Hi,
> >
> >> How will we achieve parity on the SWF side?  And keep the SWF
> >> implementation simple.  SWF only knows about "bold" and "normal".
> >>That's
> >> one reason SimpleCSSStylesImpl is "simple”.
> >
> >Is this a real concern? There are several other styles in that class that
> >don't have parity between JS and AS i.e  background image, border style,
> >vertical align and padding. May also be others I’ve not looked at all
> >properties in detail.
>
> They may not have parity today due to bugs, but the goal is to reduce the
> differences to zero if possible.  I think we can do that for the styles in
> there, and if we can't, we'll probably pull out the ones we can't.
>
> >
> >It seems wrong to me to disable something in the JS side just because
> >it’s not supported in the AS side.
>
> It isn't disabling something on the JS side, it is giving users choices
> about size, performance and features.  That is the nature of PAYG.  There
> is no one "right" answer.  Users are not required to use
> SimpleCSSStylesImpl, and I doubt SimpleCSSStylesImpl will be the most
> popular IValuesImpl.  But it has a goal of being "simple", small, and
> parity.
>
> We definitely need the code you wrote, but in a different class.  We need
> other IValuesImpls.
>
> Thanks,
> -Alex
>
>

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Greg Dove]

--
in Falcon this currently does not cause a compiler error for mxml,
compilation completes normally, and in js the value of number will be the
"Something else", in swf it is NaN. IMO this is clearly wrong.


PROPOSED FIX (DONE)
---
Please let me know if you agree, or suggest alternative.
I have added a new Problem to be closer to what was shown before in Flex 4:
This is the new one I mirrored from Flex 4 (with same description) in FlexJS
GenericTests.mxml(56): col: 4 Error: In initializer for 'local:number',
type String is not assignable to target type 'Number'.
Something else
^
Multiple initializers
-
   
23.56


23.56

this gives the following in Flex 4:
Error:(24, 0) [flex4testforFlexJS]: Multiple initializers for property
'number'.
In FlexJS (with or without the proposed fixes for the other issues above)
GenericTests.mxml(58): col: 9 Error: Child tag 'number' bound to namespace
'*' is already specified for element 'local:TestView'. It will be ignored.

^
(In both Flex 4 and FlexJS the line number reported is for the beginning of
the 2nd initializer tag , which is correct)
CURRENT BUG
---
I believe the error description should be improved - it currently says "It
will be ignored" and that is not what actually happens (not being ignored
is correct, IMO).
And (unless I am missing something important) the rest seems too verbose.
PROPOSED FIX (NOT DONE):
---
This is easy to change please let me know if you agree.
I suggest changing the FlexJS error description to be similar to Flex 4, to:
Multiple initializers for 'local:number' are not permitted for element
'local:TestView'.
   
^




On Sat, Mar 4, 2017 at 8:46 PM, Greg Dove <greg.d...@gmail.com> wrote:

>
> I believe MXML is supposed to treat more than one child in a child tag as
> an array.  And thus, the equivalent AS code for:
>
> 
>   
>   
> 
>
> is:
>
>   initialView = [ new MyInitialView, new MyOtherInitialView];
>
>
>
> I understood the same, but I had thought it was supposed to be a bit
> smarter than that and only assume an implicit  wrapper if it is
> assigning to an Array typed property (maybe even 'Arraylike') property. I
> will check the behavior using Flex 4 - I assume we want to keep whatever
> 'smarts' were implemented there, or at least as close as makes sense? I'll
> also double check the compiler error for this same scenario in Flex 4,
> which I did not do yet.
>
> If you code that in AS, you will get an error (I hope), and I think the
> compiler should report the same error for this MXML scenario, since
> initialView is of type IApplicationView or something like that.
>
>
> There might arguably be some justification for having an 'mxml version' of
> an error, describing things more in mxml terms, particularly for new users
> as they come on board and perhaps play with mxml examples first before
> learning actionscript, but I will check both the actionscript error in
> FlexJS and the mxml error in Flex 4 (assuming there is one)  for this
> scenario and report back here for consensus.
>
> 
>   
> 
>
> Is the equivalent of:
> var initialView:IApplicationView = new SimpleCSSValuesImpl().
>
>
>
> Exactly, and in the fix, I have this currently being described as:
> In initializer for 'js:initialView', type 
> org.apache.flex.core.SimpleCSSValuesImpl
> is not assignable to target type 'org.apache.flex.core.IApplicationView'.
>
> I will check the FlexJS actionscript error for this also, but I definitely
> pulled that one above as-is from Flex 4 for the same mxml problem (which is
> also correctly treated as a compile time error)
>
>
>
> On Fri, Mar 3, 2017 at 6:33 PM, Alex Harui <aha...@adobe.com> wrote:
>
>> Hi Greg,
>>
>> Thanks for digging into this.
>>
>> Without having dug into it myself, I would like to suggest returning a
>> type mismatch error of some sort.  IIRC, the DuplicateChildTagProblem is
>> for the following:
>>
>> 
>>   
>> 
>> 
>>   
>>
>> 
>>
>> The child tag (js:initialView) is really in there twice.
>>
>>
>> I believe MXML is supposed to treat more than one child in a child tag as
>> an array.  And thus, the equivalent AS code for:
>>
>> 
>>   
>>   
>> 
>>
>> is:
>>
>>   initialView = [ new MyInitialView, new MyOtherInitialView];
>>
>> If you code that in AS, you will get an error (I hope), and I think the
>> compiler should report the same error for this MXML scenario, since
>> initialView is of type IApplicationView or something like that.
&

Re: [FlexJS] Working to fix a compiler bug - problem with the Problems

[Greg Dove]

I believe MXML is supposed to treat more than one child in a child tag as
an array.  And thus, the equivalent AS code for:


  
  


is:

  initialView = [ new MyInitialView, new MyOtherInitialView];



I understood the same, but I had thought it was supposed to be a bit
smarter than that and only assume an implicit  wrapper if it is
assigning to an Array typed property (maybe even 'Arraylike') property. I
will check the behavior using Flex 4 - I assume we want to keep whatever
'smarts' were implemented there, or at least as close as makes sense? I'll
also double check the compiler error for this same scenario in Flex 4,
which I did not do yet.

If you code that in AS, you will get an error (I hope), and I think the
compiler should report the same error for this MXML scenario, since
initialView is of type IApplicationView or something like that.


There might arguably be some justification for having an 'mxml version' of
an error, describing things more in mxml terms, particularly for new users
as they come on board and perhaps play with mxml examples first before
learning actionscript, but I will check both the actionscript error in
FlexJS and the mxml error in Flex 4 (assuming there is one)  for this
scenario and report back here for consensus.


  


Is the equivalent of:
var initialView:IApplicationView = new SimpleCSSValuesImpl().



Exactly, and in the fix, I have this currently being described as:
In initializer for 'js:initialView', type
org.apache.flex.core.SimpleCSSValuesImpl
is not assignable to target type 'org.apache.flex.core.IApplicationView'.

I will check the FlexJS actionscript error for this also, but I definitely
pulled that one above as-is from Flex 4 for the same mxml problem (which is
also correctly treated as a compile time error)



On Fri, Mar 3, 2017 at 6:33 PM, Alex Harui <aha...@adobe.com> wrote:

> Hi Greg,
>
> Thanks for digging into this.
>
> Without having dug into it myself, I would like to suggest returning a
> type mismatch error of some sort.  IIRC, the DuplicateChildTagProblem is
> for the following:
>
> 
>   
> 
> 
>   
>
> 
>
> The child tag (js:initialView) is really in there twice.
>
>
> I believe MXML is supposed to treat more than one child in a child tag as
> an array.  And thus, the equivalent AS code for:
>
> 
>   
>   
> 
>
> is:
>
>   initialView = [ new MyInitialView, new MyOtherInitialView];
>
> If you code that in AS, you will get an error (I hope), and I think the
> compiler should report the same error for this MXML scenario, since
> initialView is of type IApplicationView or something like that.
>
> And same for the second scenario:
>
> 
>   
> 
>
> Is the equivalent of:
>
>
>   var initialView:IApplicationView = new SimpleCSSValuesImpl().
>
> My 2 cents,
> -Alex
>
> On 3/2/17, 9:09 PM, "Greg Dove" <gregd...@apache.org> wrote:
>
> >I have been looking into FLEX-35273 [1].
> >
> >This is a compiler bug where it is possible to do things that don't make
> >sense, like:
> >
> >
> >   
> >   
> >
> >
> >or even this :
> >
> >
> >   
> >
> >
> >Neither of the above caused compile time errors.
> >
> >I have a fix for both the above scenarios.
> >
> >For the first one, I used MXMLDuplicateChildTagProblem which seems 'close
> >enough'
> >
> >"Child tag '${childTag}' bound to namespace '${childNamespace}' is
> >already specified for element '${element}'. It will be ignored.";
> >
> >This renders as :
> >Child tag 'MyInitialView' bound to namespace '*' is already specified for
> >element 'js:initialView'. It will be ignored.
> >   
> >^
> >
> >in the first example above. The text does not feel entirely right, but
> >seems close enough. "It will be ignored" sounds more like a warning (as
> >opposed to an error/failure), which I think a) it should not be and b) it
> >is not.
> >
> >For the second one, I could not find any relevant 'Problem' class (I may
> >have missed one perhaps?) So I just made a new one. I don't really know
> >what the rules are here.
> >These Problems seem to include an error code so I am unclear what to do
> >if I add a new one. i.e. it is not clear what new error code I should
> >apply (or even if the error code is important for something).
> >For now I just added an arbitrary errorCode = 1999 on
> >MXMLBadChildTagPropertyAssignmentProblem.
> >
> >The new problem renders out to :
> >In initializer for 'js:initialView', type
> >org.apache.flex.core.SimpleCSSValuesImpl is not assignable to target type
> >'org.apache.flex.core.IApplicationView'.
> >
> >Alex, you may be able to advise here are there any rules I need to
> >follow for the CompilerProblem classes (in particular, when adding a new
> >class).
> >
> >Assuming all is well above, I will commit this fix tomorrow. I was also
> >trying to see if I could figure out how to get checkintests running, but
> >I so far I did not. However the regular build tests are all fine with the
> >changes I made for this.
> >
> >
> >1. https://issues.apache.org/jira/browse/FLEX-35273
>
>

Re: [FlexJS] Any gude to getting checkintests working

[Greg Dove]

That was it. Downgrading firefox worked. Thanks!

I saw the browser launch and quick test from ant  checkintests,

I did not see it from the maven build:
mvn clean install -P build-examples -Drat.skip=true

...then I remembered I had an unrelated issue with using
distributionTargetFolder defined from a locally set environment variable
(this is Windows, might be windows-specific) for maven

so... for posterity, this is the maven version that works for me on windows:

mvn clean install -P build-examples -Drat.skip=true
-Dwebdriver.gecko.driver=%cd%/../testing/selenium/firefox/geckodriver.exe

where 'testing' in

testing/selenium/firefox/geckodriver.exe

is a sibling folder to flex-asjs that I just set up arbitrarily in my local
flexjs related directories

So I now (finally) have the browser tests working. :)





On Sat, Mar 4, 2017 at 7:04 PM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 3/3/17, 9:53 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Thanks, I'm running 51.0.1, I'll see if I can downgrade that. Suffice to
> >say that "If you are using Ant, it should just work" was not quite
> >applicable in my case :).
> >A lof of this is very likely due to me being unfamiliar with the territory
> >here, though.
>
> You're definitely right that it didn't just work.  Thanks for helping see
> where the problems might be.
>
> If you can't downgrade FF, it might be time to try upgrading Selenium.  We
> upgrade Selenium every so often.
>
> Thanks,
> -Alex
>
>

Re: [FlexJS] Any gude to getting checkintests working

[Greg Dove]

Thanks, I'm running 51.0.1, I'll see if I can downgrade that. Suffice to
say that "If you are using Ant, it should just work" was not quite
applicable in my case :).
A lof of this is very likely due to me being unfamiliar with the territory
here, though.



On Sat, Mar 4, 2017 at 6:45 PM, Alex Harui <aha...@adobe.com> wrote:

> What version of Firefox are you using?
>
> We are currently using Selenium 2.53.1.  I think it likes FF 47.0.1.
>
> HTH,
> -Alex
>
> On 3/3/17, 6:48 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Thanks Chris, and Alex,
> >
> >
> >I am still working on getting the browser test support to work via either
> >maven or ant checkintests.
> >
> >Thus far I get a firefox launch when running ant checkintests but nothing
> >displays and I eventually get
> >org.openqa.selenium.firefox.NotConnectedException: Unable to connect to
> >host 127.0.0.1 on port 7055 after 45000 ms.
> >
> >With maven I set the environment variable and also added geckodriver.exe
> >containing directory to the PATH, but I don't see any browser launch from
> >the build-examples.
> >
> >So clearly I have something wrong with my setup for Selenium/Firefox, will
> >try to figure it out.
> >
> >
> >
> >
> >I have not run the selenium
> >
> >On Sat, Mar 4, 2017 at 2:02 AM, Christofer Dutz
> ><christofer.d...@c-ware.de>
> >wrote:
> >
> >> Hi Greg,
> >>
> >> With Maven it should also work.
> >>
> >> For the compiler:
> >> If you do a “mvn clean install” it should run almost all unit-tests and
> >> integration-tests.
> >> If you define an Evironment variable FLASHPLAYER_DEBUGGER (Same as for
> >>the
> >> ANT build) pointing to the flash debug player the integration-tests with
> >> Flash should work.
> >>
> >> For the typedefs:
> >> They don’t have tests (at least in Maven)
> >>
> >> For the framework:
> >> A simple “mvn clean install” compiles just the framework libs, but
> >>doesn’t
> >> build the examples.
> >> If you do a “mvn clean install –P build-examples” it will also build the
> >> examples (Examples will run a small unit test that tests, the build
> >> artifacts are correctly created)
> >> If you do a “mvn clean install –P build-distribution” it will also build
> >> the distribution (but not the examples)
> >> If you do a “mvn clean install –P build-examples,build-distribution” it
> >> will build the libs, examples and distribution.
> >> And If you also define an environment variable “webdriver.gecko.driver”
> >>to
> >> the selenium gecko-driver and run “mvn clean install –P build-examples”
> >>the
> >> build will also run some browser-tests.
> >>
> >> Chris
> >>
> >>
> >>
> >>
> >> Am 03.03.17, 05:59 schrieb "Greg Dove" <gregd...@apache.org>:
> >>
> >> There are a few things I have not yet gotten working so far, and the
> >> ant checkintests is one of them.
> >>
> >> If I understand correctly I should be running this before any
> >>commit?
> >> I tried to make sense of this today, but it is not so easy (for me)
> >>because
> >> I am unfamiliar with this stuff.
> >>
> >> As I have never done this so far, is it ok if I just continue to
> >> commit based on the regular ant and maven builds (with their various
> >>tests)
> >> completing successfully? Otherwise if I need to get this set up, is
> >>there a
> >> guide to doing so somewhere that I can follow?
> >>
> >>
> >>
> >>
> >>
> >>
>
>

Re: [FlexJS] Any gude to getting checkintests working

[Greg Dove]

Thanks Chris, and Alex,


I am still working on getting the browser test support to work via either
maven or ant checkintests.

Thus far I get a firefox launch when running ant checkintests but nothing
displays and I eventually get
org.openqa.selenium.firefox.NotConnectedException: Unable to connect to
host 127.0.0.1 on port 7055 after 45000 ms.

With maven I set the environment variable and also added geckodriver.exe
containing directory to the PATH, but I don't see any browser launch from
the build-examples.

So clearly I have something wrong with my setup for Selenium/Firefox, will
try to figure it out.




I have not run the selenium

On Sat, Mar 4, 2017 at 2:02 AM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> Hi Greg,
>
> With Maven it should also work.
>
> For the compiler:
> If you do a “mvn clean install” it should run almost all unit-tests and
> integration-tests.
> If you define an Evironment variable FLASHPLAYER_DEBUGGER (Same as for the
> ANT build) pointing to the flash debug player the integration-tests with
> Flash should work.
>
> For the typedefs:
> They don’t have tests (at least in Maven)
>
> For the framework:
> A simple “mvn clean install” compiles just the framework libs, but doesn’t
> build the examples.
> If you do a “mvn clean install –P build-examples” it will also build the
> examples (Examples will run a small unit test that tests, the build
> artifacts are correctly created)
> If you do a “mvn clean install –P build-distribution” it will also build
> the distribution (but not the examples)
> If you do a “mvn clean install –P build-examples,build-distribution” it
> will build the libs, examples and distribution.
> And If you also define an environment variable “webdriver.gecko.driver” to
> the selenium gecko-driver and run “mvn clean install –P build-examples” the
> build will also run some browser-tests.
>
> Chris
>
>
>
>
> Am 03.03.17, 05:59 schrieb "Greg Dove" <gregd...@apache.org>:
>
> There are a few things I have not yet gotten working so far, and the
> ant checkintests is one of them.
>
> If I understand correctly I should be running this before any commit?
> I tried to make sense of this today, but it is not so easy (for me) because
> I am unfamiliar with this stuff.
>
> As I have never done this so far, is it ok if I just continue to
> commit based on the regular ant and maven builds (with their various tests)
> completing successfully? Otherwise if I need to get this set up, is there a
> guide to doing so somewhere that I can follow?
>
>
>
>
>
>