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.

It seems that there is: https://jsperf.com/isnan-performance/2 I did not see much difference between methods in terms of performance. > On Aug 3, 2017, at 4:30 PM, Harbs wrote: > > I wonder if there’s a difference between Flash and JS.

Re: FlexJS Bead dilemma

My ideas on bead lifecycles might help for this. Not sure. I’m not sure there’s a perfect solution to this problem. If I have to weigh a single check for visible vs an entire layout, I’d go for the former. I seem to recall that we did something to prevent non-visible components for going throw

Re: [MAVEN-BUILD] FlexJS Framework (maven) - Build # 1167 - Fixed

Thanks for taking care of this, Piotr! Regards, Om On Thu, Aug 3, 2017 at 11:18 AM, Piotr Zarzycki wrote: > Yes! Finally it's working! > > Chris Lambertus on infra HipChat helped me giving a tip to setup specific > version of Maven in configuration! I setup 3.3.9 (Windows). > > Piotr > > 2017-0

Re: [MAVEN-BUILD] FlexJS Framework (maven) - Build # 1167 - Fixed

Yes! Finally it's working! Chris Lambertus on infra HipChat helped me giving a tip to setup specific version of Maven in configuration! I setup 3.3.9 (Windows). Piotr 2017-08-03 20:15 GMT+02:00 Apache Jenkins Server : > The Apache Jenkins build system has built FlexJS Framework (maven) (build

Re: FlexJS MXML ids and classNames - FLEX-35310

Hi All, This issue started to be real blocker for my client's application. If we could ask anyone from compiler sight to try to work on that it would be awesome and simply help with farther development those app in FlexJS. [1] I think option where we are going with "localID" is ok to me. Alex me

Re: FlexJS Bead dilemma

Yeah, but I also remembered on other thing. The vast majority of components are never made invisible, so adding a check in each layout bead just-in-case they are made invisible isn't very PAYG. So maybe there is some other way that setting visible=false can inject code that handles sharing the CS

Re: FlexJS Bead dilemma

But it it doesn’t set display, we’re going to have to run layout every time the visibility changes. I’ve already made my changes. I’ll commit soon. Ah. I see what you mean. By doing it your way, there’s no reason to actually run layout until (or if) the visibility is set to true. That probably

Re: FlexJS Bead dilemma

Right, so layout code would have to check for display=="none" and not set display and listen for the show event. Maybe as you clean up the setting of display multiple times it will be come clear as to whether listening for "show" is cheaper/cleaner than displayStyleForLayout. -Alex On 8/3/17, 8:

Re: FlexJS Bead dilemma

The problem is that visible is set before the bead exists. BTW, Some of the layout seem to be reading and setting display multiple times. That can cause layout thrashing. That should probably be resolved. > On Aug 3, 2017, at 6:05 PM, Alex Harui wrote: > > FWIW, I'm not sure this is the best p

Re: FlexJS Bead dilemma

FWIW, I'm not sure this is the best pattern. It was what we did to get the examples to run. Another option is that layout beads listen for changes to visible and reset the CSS display style when visible changes. Food for thought, -Alex On 8/3/17, 8:00 AM, "Harbs" wrote: >I’m using a VerticalF

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.

IMO, it matters whether you are strictly/strongly typing or not. I have not spent the time to see what the compiler does for: var foo:String; if (isNaN(foo)) Do you get a compiler error? Or is it allowed and auto-coercion in the Flash runtime will do what JS does? You are correct that if you n

FlexJS Bead dilemma

I’m using a VerticalFlexLayout in a component. Under certain circumstances, I need to set the visibility of the component to false. These two settings are contradictory in JS. visible=false sets display to none VerticalFlexLayout sets the display to flex When setting visible to false, it uses a

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.

It seems dangerous to replace isNaN with someNumber !== someNumber. In that article, they said that isNaN() could return false positives, but I don't actually consider their example to be a false positive at all. I would fully expect isNaN() to return true for a string value. If we replaced that ex

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.

Here's an article about isNaN is JS. http://adripofjavascript.com/blog/drips/the-problem-with-testing-for-nan-in -javascript.html Maybe the transpiler should not output isNaN and instead "someNumber !== someNumber" -Alex On 8/3/17, 6:30 AM, "Harbs" wrote: >Cool. > >I wonder if there’s a diffe

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.

Cool. I wonder if there’s a difference between Flash and JS. The tests seem to indicate that isNaN() is very efficient in JS. It might be an interesting project to compare badly performing cases in Flash to their JS counterparts. BTW, I just ran into a case where booleans behave differently in

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.

Switching away from isNaN() in Feathers improved performance in a measurable way. It wasn't just a guess. - Josh On Aug 2, 2017 11:53 PM, "Harbs" wrote: Ah. Thanks. (I haven’t had my coffee yet) ;-) It would be interesting to know if that really is more efficient. > On Aug 3, 2017, at 9:33 AM

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

Hi Alex, Locally it's now working. :) I've sent message to infra on HipChat. Waiting for the response. 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-S