Moonshine 1.5.1 Released

[sankar]

We are pleased to announce that Moonshine 1.5.1 has been released.

Updates:
- Better simulator size for mobile application
- Lots of fixes to Ant build procedures

Let us know if you encounter any issues with the update.

http://moonshine-ide.com



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Moonshine-1-5-1-Released-tp63623.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MAVEN-BUILD] FlexJS Framework (maven) - Build # 1129 - Still Failing

[Alex Harui]

Does it build locally for you?  I can't get TLF to build with Maven, and
it isn't clear that it should.

-Alex

On 7/31/17, 2:42 AM, "piotrz"  wrote:

>I have no idea what is happen. I just changed machine which building
>FlexJS
>and it is still not working. I do not udnerstand why it is failing. :/
>
>Thanks,
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FRe-MAVEN-BUILD-FlexJS-Framework-mave
>n-Build-1129-Still-Failing-tp63607p63613.html=02%7C01%7C%7C86b02f4a24
>60405bb36008d4d7f88556%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636370
>909771287987=sIuTxUxWuowCY%2FFjw91RfeVoibRCbFbJv0%2F%2FRCleOY8%3D
>served=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Debugger statement

[Alex Harui]

I'm still trying to get the ok to use undocumented APIs without violating
the Flash EULA which prohibits reverse-engineering.  Could just make it
JS-only for now.

-Alex

On 7/31/17, 3:01 PM, "Josh Tynjala"  wrote:

>If there are no objections in the next 24 hours, I plan to merge my
>"feature/debugger-statement" branch that adds a "debugger" statement to
>ActionScript similar to the one available in JS.
>
>Use of the debugger statement is completely optional, but it's a useful
>way
>to trigger the debugger from code in a cross-platform way. In other words,
>the following code will just work whether you're running the generated JS
>or SWF:
>
>if(x > 100)
>{
>debugger;
>}
>
>- Josh

Re: Debugger statement

[OmPrakash Muppirala]

+1

I so used to doing this nowadays.  Also, this is very useful when we want
to debug Node.js applications.  There is no good way to setup debug points
the first time with Node.js applications.

Thanks,
Om

On Mon, Jul 31, 2017 at 3:01 PM, Josh Tynjala  wrote:

> If there are no objections in the next 24 hours, I plan to merge my
> "feature/debugger-statement" branch that adds a "debugger" statement to
> ActionScript similar to the one available in JS.
>
> Use of the debugger statement is completely optional, but it's a useful way
> to trigger the debugger from code in a cross-platform way. In other words,
> the following code will just work whether you're running the generated JS
> or SWF:
>
> if(x > 100)
> {
> debugger;
> }
>
> - Josh
>

Re: Debugger statement

[piotrz]

Hi Josh,

+1.

Unfortunately didn't have time to try this one, but it seems to be very
useful and I will definitely make an first attempt of use when I get my
hands back onto framework code. :)

Thank you for this feature!
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Debugger-statement-tp63618p63619.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Debugger statement

[Josh Tynjala]

If there are no objections in the next 24 hours, I plan to merge my
"feature/debugger-statement" branch that adds a "debugger" statement to
ActionScript similar to the one available in JS.

Use of the debugger statement is completely optional, but it's a useful way
to trigger the debugger from code in a cross-platform way. In other words,
the following code will just work whether you're running the generated JS
or SWF:

if(x > 100)
{
debugger;
}

- Josh

RE: XML hasOwnProperty method

[Jim Norris]

Hi-

I installed the Apache FlexJS Nightly using the SDK Installer and adjusted the 
project compiler to the new SDK, but I am still seeing failures with the 
handleOwnProperty method.  I will try to do some additional debugging tomorrow 
to see where the problem is coming from.

In the meantime I used the work around you mentioned and got a component 
working correctly in Firefox.  However, I am getting a syntax error in Internet 
Explorer when creating the XML object (the same function works in Firefox, both 
using the same XML file).  Specifically the issue is at this line in XML.js:

var /** @type {string} */ errorNS = 
org.apache.flex.utils.Language.string(parser.parseFromString('<', 
'application/xml').getElementsByTagName("parsererror")[0].namespaceURI);

In Firefox this line works without issue, but in IE I see a syntax error in the 
debugger.

I did a little research and it seems this may be an issue specific to IE11, 
although it is a little unclear to me how best to fix it.

https://stackoverflow.com/questions/23022956/internet-explorer-11-ie-11-throws-syntax-error-using-parsefromstring-in-dompar
https://stackoverflow.com/questions/31277058/parsefromstring-throws-error-in-ie-but-not-in-chrome?noredirect=1=1

Let me know if I can provide any additional info.




Thanks,

Jim

-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com] 
Sent: Sunday, July 30, 2017 4:37 PM
To: dev@flex.apache.org
Subject: Re: XML hasOwnProperty method

There are quite a few fixes to XML in particular in the nightly, so I would 
recommend that you use the nightly anyway.

If you need help getting the nightly, let us know.

Thanks,
Harbs

> On Jul 30, 2017, at 11:05 PM, Jim Norris  wrote:
> 
> That's great news!  I am using 0.8 right now although I may need to get this 
> update to be able to progress much further.
> 
> 
> 
> Thanks,
> 
> Jim
> 
> -Original Message-
> From: Harbs [mailto:harbs.li...@gmail.com]
> Sent: Sunday, July 30, 2017 3:47 PM
> To: dev@flex.apache.org
> Subject: Re: XML hasOwnProperty method
> 
> I just tried this and I see the problem.
> 
> I should have it fixed soon…
> 
>> On Jul 30, 2017, at 10:38 PM, Harbs  wrote:
>> 
>> Hi Jim,
>> 
>> Do you get some kind of error when you do this? Are you using 0.8.0 or the 
>> nightly?
>> 
>> I don’t think hasOwnProperty is something I personally use, so I wouldn’t be 
>> too surprised if there are issues there.
>> 
>> (FWIW, you should be able to use 
>> if(resourceXML.@collapsible.length())
>> as a workaround.)
>> 
>> Thanks,
>> Harbs
>> 
>>> On Jul 30, 2017, at 9:56 PM, Jim Norris  wrote:
>>> 
>>> This may be for Harbs as I think he did a lot of the work for XML.
>>> 
>>> 
>>> 
>>> I am working on some existing Flex code and trying to convert 
>>> portions of it to FlexJS.  As part of the application it loads a lot 
>>> of XML files and uses E4X to parse them.  I was able to get this 
>>> working quickly in swf format, so that was awesome!
>>> 
>>> 
>>> 
>>> However, I am having a problem with the hasOwnProperty method.  It 
>>> works fine running in swf format, but when I export to HTML/JS the 
>>> Javascript bombs on the hasOwnProperty method calls.  If I remove 
>>> them the code executes as it should.
>>> 
>>> 
>>> 
>>> I checked here
>>> (https://cwiki.apache.org/confluence/display/FLEX/E4X+Observations)
>>> and it seems like they should be working but I wanted to check if I 
>>> am doing something I should not.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Typically these checks look like this in AS:
>>> 
>>> 
>>> 
>>> if (resourceXML.hasOwnProperty("@collapsible") == true){
>>> 
>>> globalCollapsible = toBoolean(resourceXML.@collapsible);
>>> 
>>> }else{
>>> 
>>>_globalCollapsible = false;
>>> 
>>> }
>>> 
>>> 
>>> 
>>> And look like this in the JS (the last alert I message I see is the 
>>> 'checking global property'):
>>> 
>>> 
>>> 
>>> alert('TextViewer checking global property');
>>> 
>>> if (resourceXML.hasOwnProperty("@collapsible") == true) {
>>> 
>>>  alert('TextViewer.init found global property');
>>> 
>>>  this._globalCollapsible =
>>> this.toBoolean(resourceXML.attribute('collapsible'));
>>> 
>>> } else {
>>> 
>>>  alert('TextViewer.init global property not found');
>>> 
>>>  this._globalCollapsible = false;
>>> 
>>> }
>>> 
>>> 
>>> 
>>> 
>>> 
>>> I have a ton of these types of checks in my code so any insight you 
>>> may have into either 1) what is wrong, or 2) what I should do 
>>> instead would be a lot of help.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Thanks,
>>> 
>>> 
>>> 
>>> Jim
>>> 
>> 
> 
> 

Re: FlexJS PAYG and layouts

[Harbs]

I did think of the variable issues. Using instance variables does not generally 
strike me as problematic. (unless there’s a lot of them)

I did find some interesting articles on inlining vs function calling. Here’s 
one.[1]

Too many super calls might be bad because “call” can be expensive.

Yes. A more functional approach might be appropriate. Yishay had an interesting 
idea on maybe using CSS to apply functionality.

I’m going to sit on this one for a while and see if I come up with any 
brainstorms.

Harbs

[1]http://blog.calyptus.eu/seb/2011/01/javascript-call-performance-just-inline-it/
 


> On Jul 31, 2017, at 3:58 PM, Alex Harui  wrote:
> 
> You're welcome to try different approaches to sharing code in the base
> classes.  Often, though, loops over children need to be inlined not only
> for performance reasons (to cut out one function call in the inner loop),
> but also for information sharing reasons (local variables accumulating
> values would now need to be instance variables).  But maybe a more
> functional programming style would work here.
> 
> OneFlexibleLayout probably shouldn't set align-items or any CSS styles at
> all on the JS side.  Those values should be set in CSS.  If the SWF side
> has to run this sort of code, that's the cost of emulating JS in SWF.  Or
> maybe we need a SWF-side layout base that truly tries to emulate browser
> behavior.
> 
> Also, for OneFlexible, there is no promise that it uses flex-box under the
> hood, it just has to solve what I found to be a hard problem in the
> browser (one stretchy thing), so the implementations for JS and SWF can be
> widely divergent.  If on the other hand we had a FlexBoxContainer, it
> would be the job of that code to emulate flex-box on the SWF side and do
> almost nothing on the JS side except set flex-box on the div.
> 
> My 2 cents,
> -Alex
> 
> On 7/31/17, 3:42 AM, "Harbs"  wrote:
> 
>> Here’s a dilema I ran into this morning:
>> 
>> The OneFlexibleLayout beads have some code which look like this:
>> if (!contentView.element.style["align-items"])
>>   contentView.element.style["align-items"] = "center”;
>> 
>> What that does, is check if “align-items” is already set and sets it to
>> center if not. I’m assuming the reason it sets it to center is because
>> the default of flex-box is “stretch” which is not a very good default.
>> 
>> The problem is that center is not necessarily the best default either. I
>> would have probably made flex-start the default. In fact, it looks like
>> it is the default for swf is left. (flex-start is what I needed in my
>> situation.)
>> 
>> I have just committed a change to make the JS consistent with the SWF. It
>> now defaults to “flex-start” due to CSS defined on Container. I had to
>> add a Container typename for all containers for this to work. I hope this
>> is okay. I think it makes sense anyway, because otherwise, there’s no way
>> to set custom CSS for all containers. If the style sets “center”, then
>> that is honored to center it. The default can be overridden using CSS on
>> the JS side, but it will not have an effect on the SWF side.
>> 
>> So far, so good.
>> 
>> Now my question is the follows: It seems kind of random that only
>> alignItems:center does anything. I’d think that it should either support
>> flex-start, flex-end,center and stretch or not do anything. I’d guess the
>> answer is to create OneFlexibleLayoutWithAlignment?
>> 
>> The problem with that is we’d end up writing lots of duplicate code. In
>> fact, I went through the different layout classes and the general pattern
>> is constant across them:
>> 
>> 1. Do something to the parent
>> 2. Loop through the children, and do something to each one of them.
>> 
>> There are exceptions to this rule (such as the swf side of
>> OneFlexibleChild layouts), but the majority of the layouts follow this
>> pattern. I was thinking of the following idea to make it easier to
>> modularize functionality and avoid code repeat:
>> 
>> Change LayoutBase to the following:
>> 
>> public function layout():Boolean
>> {
>>  var contentView:ILayoutView = layoutView;
>>  var n:int = contentView.numElements;
>>  if (n == 0) return false;
>>  if(!layoutParent())
>>  return false
>> 
>>  for(var i:int=0; i < n; i++) {
>>  var child:UIBase = contentView.getElementAt(i) as UIBase;
>>  if(!layoutChild(child))
>>  return false;
>>  }
>> 
>>  return true;
>> }
>> protected function layoutParent():Boolean{
>>   // override in subclass
>>  return false;
>> }
>> protected function layoutChild(child:UIBase):Boolean{
>>   // override in subclass
>>  return false;
>> }
>> 
>> Then in the subclasses, you would only override layout() if it does not
>> follow this pattern. When it does, you would just override layoutParent()
>> and 

Re: FlexJS PAYG and layouts

[Alex Harui]

You're welcome to try different approaches to sharing code in the base
classes.  Often, though, loops over children need to be inlined not only
for performance reasons (to cut out one function call in the inner loop),
but also for information sharing reasons (local variables accumulating
values would now need to be instance variables).  But maybe a more
functional programming style would work here.

OneFlexibleLayout probably shouldn't set align-items or any CSS styles at
all on the JS side.  Those values should be set in CSS.  If the SWF side
has to run this sort of code, that's the cost of emulating JS in SWF.  Or
maybe we need a SWF-side layout base that truly tries to emulate browser
behavior.

Also, for OneFlexible, there is no promise that it uses flex-box under the
hood, it just has to solve what I found to be a hard problem in the
browser (one stretchy thing), so the implementations for JS and SWF can be
widely divergent.  If on the other hand we had a FlexBoxContainer, it
would be the job of that code to emulate flex-box on the SWF side and do
almost nothing on the JS side except set flex-box on the div.

My 2 cents,
-Alex

On 7/31/17, 3:42 AM, "Harbs"  wrote:

>Here’s a dilema I ran into this morning:
>
>The OneFlexibleLayout beads have some code which look like this:
>if (!contentView.element.style["align-items"])
>contentView.element.style["align-items"] = "center”;
>
>What that does, is check if “align-items” is already set and sets it to
>center if not. I’m assuming the reason it sets it to center is because
>the default of flex-box is “stretch” which is not a very good default.
>
>The problem is that center is not necessarily the best default either. I
>would have probably made flex-start the default. In fact, it looks like
>it is the default for swf is left. (flex-start is what I needed in my
>situation.)
>
>I have just committed a change to make the JS consistent with the SWF. It
>now defaults to “flex-start” due to CSS defined on Container. I had to
>add a Container typename for all containers for this to work. I hope this
>is okay. I think it makes sense anyway, because otherwise, there’s no way
>to set custom CSS for all containers. If the style sets “center”, then
>that is honored to center it. The default can be overridden using CSS on
>the JS side, but it will not have an effect on the SWF side.
>
>So far, so good.
>
>Now my question is the follows: It seems kind of random that only
>alignItems:center does anything. I’d think that it should either support
>flex-start, flex-end,center and stretch or not do anything. I’d guess the
>answer is to create OneFlexibleLayoutWithAlignment?
>
>The problem with that is we’d end up writing lots of duplicate code. In
>fact, I went through the different layout classes and the general pattern
>is constant across them:
>
>1. Do something to the parent
>2. Loop through the children, and do something to each one of them.
>
>There are exceptions to this rule (such as the swf side of
>OneFlexibleChild layouts), but the majority of the layouts follow this
>pattern. I was thinking of the following idea to make it easier to
>modularize functionality and avoid code repeat:
>
>Change LayoutBase to the following:
>
>public function layout():Boolean
>{
>   var contentView:ILayoutView = layoutView;
>   var n:int = contentView.numElements;
>   if (n == 0) return false;
>   if(!layoutParent())
>   return false
>
>   for(var i:int=0; i < n; i++) {
>   var child:UIBase = contentView.getElementAt(i) as UIBase;
>   if(!layoutChild(child))
>   return false;
>   }
>
>   return true;
>}
>protected function layoutParent():Boolean{
>// override in subclass
>   return false;
>}
>protected function layoutChild(child:UIBase):Boolean{
>// override in subclass
>   return false;
>}
>
>Then in the subclasses, you would only override layout() if it does not
>follow this pattern. When it does, you would just override layoutParent()
>and layoutChild(). That has the following benefits:
>
>1. You do not need to write the loop in every subclass.
>2. Each subclass can use the pieces of the layout that make sense.
>3. If a subclass is just adding additional functionality (such as setting
>the alignment of the children), it only needs to add code for that
>specific functionality without the need to either rewrite the layout
>function twice or make two loops.
>
>Thoughts?
>Harbs
>

FlexJS PAYG and layouts

[Harbs]

Here’s a dilema I ran into this morning:

The OneFlexibleLayout beads have some code which look like this:
if (!contentView.element.style["align-items"])
contentView.element.style["align-items"] = "center”;

What that does, is check if “align-items” is already set and sets it to center 
if not. I’m assuming the reason it sets it to center is because the default of 
flex-box is “stretch” which is not a very good default.

The problem is that center is not necessarily the best default either. I would 
have probably made flex-start the default. In fact, it looks like it is the 
default for swf is left. (flex-start is what I needed in my situation.)

I have just committed a change to make the JS consistent with the SWF. It now 
defaults to “flex-start” due to CSS defined on Container. I had to add a 
Container typename for all containers for this to work. I hope this is okay. I 
think it makes sense anyway, because otherwise, there’s no way to set custom 
CSS for all containers. If the style sets “center”, then that is honored to 
center it. The default can be overridden using CSS on the JS side, but it will 
not have an effect on the SWF side.

So far, so good.

Now my question is the follows: It seems kind of random that only 
alignItems:center does anything. I’d think that it should either support 
flex-start, flex-end,center and stretch or not do anything. I’d guess the 
answer is to create OneFlexibleLayoutWithAlignment?

The problem with that is we’d end up writing lots of duplicate code. In fact, I 
went through the different layout classes and the general pattern is constant 
across them:

1. Do something to the parent
2. Loop through the children, and do something to each one of them.

There are exceptions to this rule (such as the swf side of OneFlexibleChild 
layouts), but the majority of the layouts follow this pattern. I was thinking 
of the following idea to make it easier to modularize functionality and avoid 
code repeat:

Change LayoutBase to the following:

public function layout():Boolean
{
var contentView:ILayoutView = layoutView;
var n:int = contentView.numElements;
if (n == 0) return false;
if(!layoutParent())
return false

for(var i:int=0; i < n; i++) {
var child:UIBase = contentView.getElementAt(i) as UIBase;
if(!layoutChild(child))
return false;
}

return true;
}
protected function layoutParent():Boolean{
// override in subclass
return false;
}
protected function layoutChild(child:UIBase):Boolean{
// override in subclass
return false;
}

Then in the subclasses, you would only override layout() if it does not follow 
this pattern. When it does, you would just override layoutParent() and 
layoutChild(). That has the following benefits:

1. You do not need to write the loop in every subclass.
2. Each subclass can use the pieces of the layout that make sense.
3. If a subclass is just adding additional functionality (such as setting the 
alignment of the children), it only needs to add code for that specific 
functionality without the need to either rewrite the layout function twice or 
make two loops.

Thoughts?
Harbs

Re: [MAVEN-BUILD] FlexJS Framework (maven) - Build # 1129 - Still Failing

[piotrz]

Harbs,

I just tried develop pipeline and it's working, so it probably something on
this machine. [1]

[1]
https://builds.apache.org/view/E-G/view/Flex/job/FlexJS%20Pipeline/job/develop/

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Re-MAVEN-BUILD-FlexJS-Framework-maven-Build-1129-Still-Failing-tp63607p63612.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [07/13] git commit: [flex-asjs] [refs/heads/release0.8.0] - give up on trying to use FlexBox for full-screen 3-pane views. FlexBox seems more happy stretching to content size instead of clipping a

[Harbs]

The only example I found was the ASDoc app.

I switched it and it appears to work. (I pushed my changes.)

> On Jul 31, 2017, at 7:35 AM, Alex Harui  wrote:
> 
> It will either work in the examples that use it or it won't.  Try it and
> find out.
> 
> -Alex
> 
> On 7/30/17, 3:04 AM, "Harbs"  wrote:
> 
>> I think I just ran into the same issue.
>> 
>> This layout seems to more-or-less do the job, but it’s kind of heavy.
>> 
>> I did some research into flexbox and it appear that setting flex-basis to
>> 0 does the job. It needs to be set on ONLY the one flexible child.
>> 
>> Here’s a codepen which shows a use case.
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodepen.i
>> o%2Fjpdevries%2Fpen%2FoXxPOP=02%7C01%7C%7C699bbb170b2c4f0bf3ae08d4d73
>> 2638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636370058818766511
>> a=tSTNYANFFiQ4DMGYbAZaz0dJ9qYDYpcwP2ZoSYRIcG8%3D=0
>> > io%2Fjpdevries%2Fpen%2FoXxPOP=02%7C01%7C%7C699bbb170b2c4f0bf3ae08d4d7
>> 32638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636370058818766511
>> ta=tSTNYANFFiQ4DMGYbAZaz0dJ9qYDYpcwP2ZoSYRIcG8%3D=0>
>> 
>> I noticed that the OneFlexibleLayouts have code which set the flex-basis
>> of the children if a percentage value is set. When setting the size of
>> the one flexible child to 0% this causes the flex-basis to be set to 0
>> and then the one flexible child will fit the remaining space even if it
>> might overflow because of its children.
>> 
>> I have wasted quite a bit of time before I discovered this. I’m not sure
>> whether the OneFlexibleLayout classes should be changed, or maybe we need
>> documentation that to fit content that might overflow, the percentage
>> should be set to 0. It could be there are cases where the entire
>> OnFlexibleLayout should be fit when smaller and expand (and not scroll)
>> when bigger. In that case, the current behavior might be correct.
>> 
>> Thoughts?
>> Harbs
>> 
>>> On May 23, 2017, at 10:16 AM, aha...@apache.org wrote:
>>> 
>>> give up on trying to use FlexBox for full-screen 3-pane views.  FlexBox
>>> seems more happy stretching to content size instead of clipping at the
>>> computed flex-ed size.  These custom layouts will do the proper sizing
>>> 
>>> 
>>> Project: 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip-u
>>> s.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Frepo=02%7C01%7C%7C699bbb170
>>> b2c4f0bf3ae08d4d732638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363
>>> 70058818766511=P%2FMkfZAwCYwpQEoCe5UGx8tW0mZaIZsMdDg6VxlaKWA%3D
>>> erved=0
>>> Commit: 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip-u
>>> s.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Fcommit%2Fbdd34d2e=02%7C01%7
>>> C%7C699bbb170b2c4f0bf3ae08d4d732638a%7Cfa7b1b5a7b34438794aed2c178decee1%7
>>> C0%7C0%7C636370058818766511=QosBAau8lE4nCS7c%2F8B6GDc%2Bqa%2BpSkoP5
>>> 5x3oji5FnI%3D=0
>>> Tree: 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip-u
>>> s.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Ftree%2Fbdd34d2e=02%7C01%7C%
>>> 7C699bbb170b2c4f0bf3ae08d4d732638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0
>>> %7C0%7C636370058818766511=T4CCqwtn%2FgFTmAnaI%2BuCXqtX0P75ebpKVZOxf
>>> XOTbIE%3D=0
>>> Diff: 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip-u
>>> s.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Fdiff%2Fbdd34d2e=02%7C01%7C%
>>> 7C699bbb170b2c4f0bf3ae08d4d732638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0
>>> %7C0%7C636370058818766511=f8WVJXc81KrLMuUgRckULYCfglNL7d%2BfdjSbBBU
>>> 0fRo%3D=0
>>> 
>>> Branch: refs/heads/release0.8.0
>>> Commit: bdd34d2ef4d8117fa1b222ac470482a42dbea9eb
>>> Parents: c505d67
>>> Author: Alex Harui 
>>> Authored: Mon May 22 10:12:02 2017 -0700
>>> Committer: Alex Harui 
>>> Committed: Tue May 23 00:15:56 2017 -0700
>>> 
>>> --
>>> ...eFlexibleChildHorizontalLayoutForOverflow.as | 290 ++
>>> ...xibleChildHorizontalLayoutLockChildHeight.as |  91 --
>>> ...OneFlexibleChildVerticalLayoutForOverflow.as | 291
>>> +++
>>> ...FlexibleChildVerticalLayoutLockChildWidth.as |  93 --
>>> .../Basic/src/main/resources/basic-manifest.xml |   4 +-
>>> 5 files changed, 583 insertions(+), 186 deletions(-)
>>> --
>>> 
>>> 
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip-u
>>> s.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Fblob%2Fbdd34d2e%2Fframeworks%2Fp
>>> rojects%2FBasic%2Fsrc%2Fmain%2Fflex%2Forg%2Fapache%2Fflex%2Fhtml%2Fbeads%
>>> 2Flayouts%2FOneFlexibleChildHorizontalLayoutForOverflow.as=02%7C01%7
>>> C%7C699bbb170b2c4f0bf3ae08d4d732638a%7Cfa7b1b5a7b34438794aed2c178decee1%7
>>> C0%7C0%7C636370058818766511=L7BjG%2BM7nTwguX%2BNaE5Op6BIT7XZrEqKFop
>>>