Re: [FlexJS] odd license headers on some files

On 5/23/17, 3:17 PM, "Justin Mclean" wrote: >Hi, > >> Agreed. Justin is good at catching licensing issues, and he seems >>willing >> to fix them himself > >Yep I’ll willing to fix this I was just unsure of the reason why the >different headers existed and if there was

Re: [FlexJS] odd license headers on some files

+1 for fixing this and get rid of one licensing issue for the next release. We have enough long threads about licensing stuff - one less issue = one less problem. :) Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context:

Re: [FlexJS] odd license headers on some files

On 5/23/17, 1:03 PM, "Christofer Dutz" wrote: >Hi Alex, > >I disagree … if things like this are found, why do them later instead of >just fixing things and not have to deal with them again? Because we want to demonstrate that releasing is simple and fun, not some

Re: [FlexJS] hard coded event names

Hi, > Like I already said; constants add much more bulk to the JS source code. Try > it and you’ll see… I’ve tried it and they don’t, but perhaps I’m missing something? Looking some AS code like so: var result1:String = "One" + "Two" + "Three"; var result2:String = ONE + TWO + THREE; var

Re: [FlexJS] hard coded event names

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)

Re: [FlexJS] hard coded event names

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: [FlexJS] odd license headers on some files

Hi, > Did RAT catch this? If not, why bother doing anything here? Because RAT is a simple tool and it doesn’t catch everything. It even tells you that when you run it. NOTE: Rat is really little more than a grep ATM Rat is also rather memory hungry ATM Rat is very basic ATM Rat highlights

Re: [FlexJS] odd license headers on some files

Hi, > Agreed. Justin is good at catching licensing issues, and he seems willing > to fix them himself Yep I’ll willing to fix this I was just unsure of the reason why the different headers existed and if there was a reason other than copy / paste issue I also come across this header in [1]

Re: [FlexJS] trace statements in SDK code

Hi, > Interesting topic. Is this something that folks think is important for > this release? Again IMO no need to hold up this release. > I would not want to have a "no trace statements" policy. IMO trace > statements are a useful tool when used appropriately. As long as the tool > chain can

Re: [FlexJS] hard coded event names

Hi, > I don't think this is a release critical issue, but it is an interesting > topic. Agreed not for this release anyway but coming up with a common pattern would be useful. > AFAICT, strings optimize better than constant lookups. Have you done any tests to show this is the case? > The

Re: [FlexJS] Is TLF Branch Building

Yishay, Let’s take this off line. I can give you my build of falcon which should work. > On May 23, 2017, at 3:55 PM, yishayw wrote: > > I'm not sure what to do here. I checked out > 7137de6b19cd11630ee1ef29f7a9164166e35b10 for falcon, built falcon and copied > jars to

Re: [FlexJS] odd license headers on some files

Agreed. Justin is good at catching licensing issues, and he seems willing to fix them himself, so let's not hold him back if he wants to do that. As long as his proposed changes seem correct at a glance, I feel like this should not require any discussion except to say "go for it!" - Josh On Tue,

Re: [FlexJS] Release builds vs debug builds

+1 … I should definitely add a direct config option to the maven mojo instead of having to pass this in using the “additionalCompilerOptions” tag. Chris Am 23.05.17, 21:07 schrieb "piotrz" : Hi Josh, Precious information! Thank you! Piotr

Re: [FlexJS] Is TLF Branch Building

I'm not sure what to do here. I checked out 7137de6b19cd11630ee1ef29f7a9164166e35b10 for falcon, built falcon and copied jars to FLEXJS_HOME/js/lib. Now when building TLF branch everything builds, but not the TLF project. What is the suggested workaround? Our app currently only runs using TLF.

Re: FlexJS MXML ids and classNames

I never said that I wanted to prohibit styling by id … just that you would probably have to use the full id (with the parent path) instead of the local one. Chris Am 23.05.17, 20:45 schrieb "piotrz" : Chris, Thank you for explanation! The idea

Re: [FlexJS] trace statements in SDK code

+1 for that Am 23.05.17, 18:36 schrieb "Alex Harui" : It might be as simple as not setting @export on Language.utils.trace. The optimizer might then figure it out without having to add DEBUG defines. Maybe something to investigate and discuss further after

Re: [FlexJS] odd license headers on some files

Hi Alex, I disagree … if things like this are found, why do them later instead of just fixing things and not have to deal with them again? I would like to resolve things like this as quietly and as swiftly as possible. It’s not keeping you from your work, is it? And it’s not going to

RE: [FlexJS] setDocument()

flexibleChild is a string, which is the id of the flexible child, so using it to reference the object won’t work. Document (which is a model of the MXML document) should be loaded at some point if it’s being used in mxml. I would put a condition to see whether it has been loaded already, and

[FlexJS] setDocument()

I have an app which uses OneFlexibleChildVerticalLayout. I have not built the app recently, and I noticed that it’s currently failing. It seems like the error is in layout() from the following code: actualChild = document[flexibleChild]; document is never being set, and I’m not sue what the

Re: [FlexJS] Release builds vs debug builds

Hi Josh, Precious information! Thank you! Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/FlexJS-Release-builds-vs-debug-builds-tp61798p61806.html Sent from the Apache Flex Development mailing list

Re: [ApacheCon/FlexJSSummit] Just registered...

I think it should be posted on our Twitter and Facebook! :) Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/ApacheCon-FlexJSSummit-Just-registered-tp61516p61805.html Sent from the Apache Flex

Re: FlexJS MXML ids and classNames

Alex, Exactly that what is happened. The third party library MDL and some other one complains about that in some project - That's why I've put back this topic to the discussion. Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context:

Re: FlexJS MXML ids and classNames

Chris, Thank you for explanation! The idea where we abandon or even do not allow styling css through the "id" is something which I would definitely not give +1. Styling by "id" it's something so common in HTML world - doesn't matter whether it's bad, people are doing like that, framework are

Re: [ApacheCon/FlexJSSummit] Just registered...

I created a playlist that contains only the talks from the FlexJS Summit: https://www.youtube.com/playlist?list=PL4EsaSA9xpnnraJX7NzpX6eh_P95RO8Pj - Josh On Tue, May 23, 2017 at 6:19 AM, Christofer Dutz wrote: > Seems our talks are online and ready for all to enjoy:

Re: [FlexJS] trace statements in SDK code

It might be as simple as not setting @export on Language.utils.trace. The optimizer might then figure it out without having to add DEBUG defines. Maybe something to investigate and discuss further after we get this release out? -Alex On 5/23/17, 8:03 AM, "Christofer Dutz"

Re: [FlexJS] empty constructors in SDK

Agreed. This shouldn't hold up the current release, but let's make sure that there's a JIRA so that we don't forget to discuss it more after the release. - Josh On Tue, May 23, 2017 at 8:29 AM, piotrz wrote: > Hi Alex, > > From my perspective it is not important for

[FlexJS] Release builds vs debug builds

At the FlexJS Summit, some of those who are working on real world apps mentioned that they eventually run into trouble as their app grows larger. The release builds stop working properly, and it's easier to deploy the debug build than to try to make Closure compiler happy to fix the release build.

Re: [FlexJS] empty constructors in SDK

Hi Alex, >From my perspective it is not important for this release, but I think it would be good to have jira for this task. Let see what other thinks. Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context:

Re: [ApacheCon/FlexJSSummit] Just registered...

Chris, if you could upload my slides, I’d appreciate it. (I couldn’t figure out how to upload them myself.) > On May 23, 2017, at 9:19 AM, Christofer Dutz > wrote: > > Seems our talks are online and ready for all to enjoy: >

Re: [FlexJS] empty constructors in SDK

On 5/23/17, 3:22 AM, "Justin Mclean" wrote: >Hi, > >We seem to have a number of empty constructors in the SDK. Is there any >reason for this as? Performance wise there’s going to be a cost with this. AFAICT the compiler will auto-generate an empty constructor for

Re: [FlexJS] hard coded event names

On 5/23/17, 5:48 AM, "Harbs" wrote: > >The FlexJS style of defining constants are to define them where they are >used rather than creating new Event classes simply for defining the >constants. (i.e. Timer.TIMER rather than TimerEvent.TIMER) This statement is a key

Re: [FlexJS] odd license headers on some files

Did RAT catch this? If not, why bother doing anything here? Might want to check with the RAT folks to see why they permit it and deal with it after the release. Let's spend our energy on making sure there aren't any big bugs out there. Thanks, -Alex On 5/23/17, 7:39 AM, "Josh Tynjala"

Re: [FlexJS] trace statements in SDK code

As far as I understood it, right now debug is the only option as all working on larger applications can’t use the release build. I think trace statements should eventually be wrapped by a “DEBUG” define to allow including them and have them excluded by default. We are talking about efficiency of

Re: FlexJS MXML ids and classNames

Yes, browsers will allow multiple ids without error. I know for sure that document.getElementById() will simply return the first element with the id that it finds in the DOM. I'm not as sure about how duplicate ids in the DOM are treated by CSS, but I wouldn't be surprised if you were right and

Re: FlexJS MXML ids and classNames

Well in that case wherever I run into something like this, the solution is to simply append the row id as an intermediate. containerId:rowId:localItemRendererId Chris Am 23.05.17, 16:34 schrieb "Alex Harui" : On 5/23/17, 12:28 AM, "Christofer Dutz"

Re: [FlexJS] trace statements in SDK code

Interesting topic. Is this something that folks think is important for this release? I would not want to have a "no trace statements" policy. IMO trace statements are a useful tool when used appropriately. As long as the tool chain can remove trace statements in production code, that should be

Re: FlexJS MXML ids and classNames

On 5/23/17, 7:32 AM, "Josh Tynjala" wrote: >I didn't consider that ids were supported in classic Flex SDK CSS. In that >case, I guess it really was global then. I guess you can think of that as global, but really, there isn't any restriction in regular Flex or FlexJS on

Re: [FlexJS] odd license headers on some files

+1 I'm sure it's just a copy/paste mistake. Let's go ahead and make them consistent. - Josh On Tue, May 23, 2017 at 5:44 AM, Christofer Dutz wrote: > So how about just updating all places where the license is not correct? > I guess this should be as easy as 1,2,3 …

Re: [FlexJS] empty constructors in SDK

I don't think the empty constructors will have a performance impact. The way we create classes in JavaScript, a constructor is required because that's where the prototype is stored, so it will be generated anyway. In SWF, I believe I remember reading that it's similar: bytecode is still generated

Re: FlexJS MXML ids and classNames

On 5/23/17, 12:28 AM, "Christofer Dutz" wrote: >Hi Piotr, > >Well in the old Flex world there was no global id like concept. There >were only local ids, only in rare cases we needed to access stuff “above” >and that’s what the parent was used for. So I guess that in

Re: FlexJS MXML ids and classNames

I didn't consider that ids were supported in classic Flex SDK CSS. In that case, I guess it really was global then. With that in mind, I guess I'm okay with adding the option to use localID instead of id when you want a member variable but not an HTML id. I suppose this change will require

Re: [FlexJS] Compiler doesn't recognize reserved JS words like 'enum'

We've already modified the compiler to support several AS3 reserved words as identifier names. As I mentioned in my previous post, JavaScript started allowing reserved words in places where they couldn't be used before with ES5. Since AS3 is derived from ECMAScript, it's pretty safe for us to do

Re: [ApacheCon/FlexJSSummit] Just registered...

Seems our talks are online and ready for all to enjoy: https://www.youtube.com/playlist?list=PLbzoR-pLrL6pLDCyPxByWQwYTL-JrF5Rp I’ll add a little more later … must do some work now ;-) Chris Am 23.05.17, 14:57 schrieb "Olaf Krueger" : Carlos Rovira wrote > btw, I

Re: [ApacheCon/FlexJSSummit] Just registered...

Carlos Rovira wrote > btw, I want to ask to you about the experience. could you post about it? > how was it? how many people was attending? what was the overal feeling and > thinking for the people coming? > I could not read anything of this, so I think it could be great some words > about it Hi

Re: [FlexJS] odd license headers on some files

My assumption is that we got two different headers by mistake, but let’s wait until more people weigh in before we change anything. If it was a mistake, it should be a simple find/replace to fix it. > On May 23, 2017, at 8:44 AM, Christofer Dutz > wrote: > > So how

Re: [FlexJS] hard coded event names

The current compiler setup makes use of static constants add considerably more bulk to the compiled code than string literals. It might be possible to make the Google Compiler do a better job, but as it stands, we’re better off with string literals than constants. The FlexJS style of defining

Re: [FlexJS] odd license headers on some files

So how about just updating all places where the license is not correct? I guess this should be as easy as 1,2,3 … or are there any problems with this. Then copy & pasting the wrong version should become quite difficult ;-) Chris Am 23.05.17, 13:45 schrieb "Harbs" :

Re: [FlexJS] hard coded event names

So, what was wrong with that practice? I sort of got used to it and it makes maintaining and extending quite easy. I really dislike these constant-graves ;-) Chris Am 23.05.17, 12:56 schrieb "Justin Mclean" : Hi, > Didn’t in the past most Event types

Re: [FlexJS] odd license headers on some files

That file is one I created. I copy-pasted the header from a different file (I don’t remember which one). I did not notice there are two different headers being used, so no clues here… Harbs > On May 23, 2017, at 5:11 AM, Justin Mclean wrote: > > HI, > >> that

Re: [FlexJS] hard coded event names

Hi, > Didn’t in the past most Event types contain the constants inside themselves? Yep in the Flex SDK that’s the case. Thanks, Justin

Re: [FlexJS] empty constructors in SDK

I remember always having warnings reported by the old compiler, if there are no constructors, so I started adding constructor blindly. Eventually that’s a pattern others have been following? Chris Am 23.05.17, 12:22 schrieb "Justin Mclean" : Hi, We seem

Re: [FlexJS] hard coded event names

Hi Justin, Didn’t in the past most Event types contain the constants inside themselves? Chris Am 23.05.17, 12:14 schrieb "Justin Mclean" : Hi, > If you add a bunch of constants to those 2, you end up bloating them. Still seems a higher cost to

[FlexJS] empty constructors in SDK

Hi, We seem to have a number of empty constructors in the SDK. Is there any reason for this as? Performance wise there’s going to be a cost with this. On the other hand we also have a number of constructors that are not light weight. AS doesn’t JIT code in constructors so best practice is to

Re: [FlexJS] hard coded event names

Hi, > If you add a bunch of constants to those 2, you end up bloating them. Still seems a higher cost to have the same thing mentioned dozens of times. Not measured the exact performance impact however. > App developers should get code hinting in mxml via metadata so typos are > mitigated. I

Re: [FlexJS] hard coded event names

I think the idea is to optimize the number of different event classes. Event and ValueEvent should take care of a lot of cases. If you add a bunch of constants to those 2, you end up bloating them. App developers should get code hinting in mxml via metadata so typos are mitigated. -- View this

[FlexJS] hard coded event names

Hi, In the Flex SDK we have a large number of event names hard coded. Is there any reason (performance or otherwise) for coding in this style? Usually I would define them as consts in a single place and refer to that. Are we assuming the compiler will optimise this and that no one will miss

Re: [FlexJS] odd license headers on some files

HI, > that problem is a simple copy-paste I’m thinking that what it probably is but may be a reason I’m unaware of. Thanks, Justin

Re: [FlexJS] odd license headers on some files

Hi Justin, My experience in work with it - that problem is a simple copy-paste, but maybe someone will have other explanation. :) Thanks, Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context:

Re: [FlexJS] trace statements in SDK code

Hi Justin, +1 Agree with you, we should get rid of them. Thanks, Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/FlexJS-trace-statements-in-SDK-code-tp61764p61766.html Sent from the Apache Flex

[FlexJS] odd license headers on some files

Hi, Noticed that a number of files (around 220 from a quick check) don’t have the standard license header text. For instance see [1]. Is there any particular reason for this? Note that the required header text is a little longer [2] and the files above are missing the first two sentances

[FlexJS] trace statements in SDK code

Hi, I’ve noticed in a few places there are some unnecessary trace statements in the SDK. Like for instance here [1]. I’m thinking we probably shouldn’t have trace statements in production code. Sonar cube flags it as an issue. [2] Anyone think otherwise? On the JS side these are only omitted

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

Hi Chris, Good luck with building! :) I did one merge the fixes which we have been working together related to Maven archetypes, but nothing more. I think there still something to push from you. Give it a try! Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in

Re: [FlexJS] Compiler doesn't recognize reserved JS words like 'enum'

>I guess the stream will definitely direct towards more people migrating to JS so I think we shouldn’t >prohibit flash related reserver words in the js world. I'm confused. Do you mean that we should allow using AS3 reserved words if they are allowed in the JS world? Wouldn't that mean that AS3

Re: [FlexJS] Compiler doesn't recognize reserved JS words like 'enum'

Really supporting “enums” would be super-cool anyway ;-) Chris Am 23.05.17, 09:08 schrieb "Olaf Krueger" : Hi, >It sounds like enum may be one of those that JavaScript allows that ActionScript currently doesn't. I've checked it out and it turns

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

Sort of managing to surface the post conference and house-building stuff … have the changes I did during ApacheCon found their way to the Release Branch yet? If not I would try to merge them (Or probably cherry pick/patch them in) Chris Am 23.05.17, 09:18 schrieb "Alex Harui"

Re: FlexJS MXML ids and classNames

Hi Piotr, Well in the old Flex world there was no global id like concept. There were only local ids, only in rare cases we needed to access stuff “above” and that’s what the parent was used for. So I guess that in general the same should apply for new MXML components. The only difference is

Re: [FlexJS] Compiler doesn't recognize reserved JS words like 'enum'

Hi, >It sounds like enum may be one of those that JavaScript allows that ActionScript currently doesn't. I've checked it out and it turns out that for both (AS3 and JS, ECMAScript5) 'enum' is flagged as future reserved keyword [1][2]. Does is makes sense to just add it to as3ReservedWords [3]?

Re: FlexJS MXML ids and classNames

On 5/22/17, 10:34 PM, "piotrz" wrote: >Hi Alex, > >You convinced me more to do not touch "id", and if we won't touch it and >introduce "localId" not translatable to HTML we will achieve those what we >want. However in order to resolve problems with third party

Re: [FlexJS] Compiler doesn't recognize reserved JS words like 'enum'

Hi, Would it be possible to have separate lists of these words and to activate these in the individual compilations? I guess the stream will definitely direct towards more people migrating to JS so I think we shouldn’t prohibit flash related reserver words in the js world. What do you think?

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

I just pushed fixes for the most obvious problems in the examples. Tomorrow I hope to fix some of the minor issues while we see if recent changes have broken anybody else. So maybe Wednesday we will cut an RC if enough folks finish up their checks and give a thumbs up. Thanks, -Alex On 5/21/17,