Ok Alex, I'll do that as I find again the problem thanks El vie., 28 jun. 2019 a las 23:05, Alex Harui (<[email protected]>) escribió:
> Don't know if it is related. If you get a failed build, copy the bin > folder somewhere. Then when you get a good build, run diff on the two > folders. > > -Alex > > On 6/28/19, 11:30 AM, "Carlos Rovira" <[email protected]> wrote: > > One thing I notice while developing our Real App and with Tour De Flex > was > a situation where ramdomly the app makes a failed compilation. The > results > was all labels are empty, so for example in TDJ all options in the left > menu are blank and icons are missing, since are test too. This use to > happen 1/10 of times (in average), and seems to happen both in Mac and > Windows. I don't remember if I reported this here or not. Was something > really cumbersome and necessary to be fixed some time, but difficult to > expose due to the random behavior that means anyone wanting to see this > will need to take TDJ and compile until he sees the false positive. > > I always think this problem should be something related to a thread > behavior problem. > > Maybe this issue and what Josh describe can be related? > > Thanks > > > > > El vie., 28 jun. 2019 a las 19:05, Alex Harui > (<[email protected]>) > escribió: > > > > > > > On 6/28/19, 8:24 AM, "Josh Tynjala" <[email protected]> > wrote: > > > > Windows and PowerShell. > > > > I've noticed my windows builds (command prompt, not powershell) are > > significantly slower than my Mac, but never investigated further. > Maybe my > > Mac has more or faster cores and memory. But I've often wondered if > the > > many Windows virus checkers are a factor as well, especially those > that > > check on every disk write. > > > > I have not been cleaning bin/js-debug before each build. So my > reported > > times are more like what an app developer would experience most > of the > > time. Writing files after remove circulars still has an impact > in that > > situation. It's not huge, but still enough to be worth the > effort, I > > think. > > > > For some file in a framework swc like UIBase.js, it should not be > written > > to bin/js-debug/ on every compile. The file is pulled from the SWC > on a > > "clean compile" and remove-circulars writes some information about > the > > dependency tree into that file. On subsequent compiles, the > > remove-circulars code should notice that information and read it and > not > > write UIBase.js again. > > > > It may be that some files must be rewritten to re-compute static > > initialization order, but that should be a small fraction of the > total set > > of .js files. > > > > Another thing I've noticed is that the compiler will randomly > decide > > to do > > a release build every now and then, even though I've always > asked for > > debug > > builds. Maybe a threading issue or something while the > configuration > > one of > > being initialized? > > > > I've never seen that. Taking a quick peek at the code, I noticed > that > > MXMLRoyalePublisher is checking configuration.release() which sounds > right, > > but configuration.release() is actually checking an uninitialized > boolean > > (and probably the wrong one (it is checking verbosestacktraces > instead of > > generatedebugtags)). I think in Java an uninitialized Boolean is > false, so > > that should still work correctly. > > > > HTH, > > -Alex > > > > - Josh > > > > On Thu, Jun 27, 2019, 9:35 PM Alex Harui > <[email protected]> > > wrote: > > > > > Good progress! Are these times based on Windows? PowerShell? > Mac? > > I'm > > > just wondering if the Java code outputting strings is slow or > the > > console > > > saving the output or both. > > > > > > Are you only testing from a clean bin/js-debug? I thought > that the > > > compiler did not copy JS files that were already in > bin/js-debug and > > > remove-circulars re-uses those JS files. > > > > > > In theory, those of us modifying framework code have to clean > out > > > bin/js-debug more often than app developers. > > > > > > HTH, > > > -Alex > > > > > > On 6/27/19, 4:00 PM, "Josh Tynjala" <[email protected] > > > > wrote: > > > > > > I made a few smaller optimizations today. It seems to > shave off > > about > > > 0.4 > > > to 0.5 seconds from the time to compile TourDeJewel on my > > computer. > > > Not as > > > dramatic as the last one, but still a measurable > difference! > > > > > > I'd like to find a way to make remove-circulars happen > earlier > > in the > > > process. It takes files that are already written to the > file > > system and > > > then modifies them. The extra re-write to disk is pretty > > expensive. If > > > all > > > JS files were written to disk only once, we'd save another > half > > second > > > or > > > more. > > > > > > -- > > > Josh Tynjala > > > Bowler Hat LLC < > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C3c4c6db7b4354534e6ac08d6fbf6acfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636973434250076206&sdata=lkfMEVDx3rIasYwkapvX8P%2Bd51tplgzoC4o%2BZD1oPXs%3D&reserved=0 > > > > > > > > > > > > > On Wed, Jun 26, 2019 at 2:42 PM Josh Tynjala < > > [email protected]> > > > wrote: > > > > > > > I found some low-hanging fruit! > > > > > > > > I just pushed a commit that removes most of the noisy > console > > output > > > from > > > > the compiler. I know that this output is useful for > debugging > > the > > > compiler > > > > itself, but most developers writing ActionScript and MXML > > don't ever > > > need > > > > to see it. > > > > > > > > If you actually want to see all of that output, you > should now > > > enable the > > > > -verbose compiler option. > > > > > > > > With -verbose=true, TourDeJewel compiles in about 8 > seconds on > > my > > > machine. > > > > With -verbose=false, it compiles in 6 seconds. We're > talking > > about > > > 20-25% > > > > improvement to compile time for that particular project. > I > > tested a > > > smaller > > > > project that is closer to a Hello World. It originally > > compiled in > > > about > > > > 4.3 seconds, and after my change the total time was > reduced to > > about > > > 3.3 > > > > seconds instead. > > > > > > > > If you're modifying the compiler in the future, and you > want > > to add a > > > > System.out.println() call, make sure that it's only > displayed > > in > > > verbose > > > > mode (unless it's related to an error, but then you > might want > > > > System.err.println() instead). You can check the > isVerbose() > > method > > > in the > > > > project's Configuration object. > > > > > > > > - Josh > > > > > > > > On 2019/06/15 06:32:52, Alex Harui > <[email protected]> > > wrote: > > > > > Just off the top of my head in my chat with Harbs last > > night, the > > > two > > > > biggest pieces of fruit are not low hanging, but > honestly, I > > think > > > you'd do > > > > a better job of picking those off than I would. The two > > pieces of > > > fruit > > > > are: > > > > > > > > > > 1) Getting rid of the two tree walks per AS file: JS > output > > > currently > > > > requires both the top-down AST walk > (BlockWalker/Emitters) and > > a > > > bottom-up > > > > AST walk (CmcEmitter/JBurg/BURM). It seems intuitive > that > > walking > > > the tree > > > > once would increase performance. The catch is that > there are > > > currently > > > > no/few semantic checks in the BlockWalker/Emitters walk > so all > > of the > > > > semantic checks from the BURM would have to be stitched > into > > the > > > Emitters > > > > so it probably won't be twice as fast, and I believe > there > > won't be > > > one > > > > place to stitch the BURM's calls into the semantic > checks ino > > the > > > > BlockWalker/Emitters. AIUI, the advantage of the BURM > is it > > can > > > "quickly" > > > > identify patterns at the leaves where it affects the > output. > > The > > > > BlockWalker/Emitters might find that they need to ask the > > semantics > > > of a > > > > pattern near the leaves from several different emitters. > > > > > > > > > > 2) Experimenting with adding context data structures > to the > > > > BlockWalker/Emitters: Try single stepping through some > medium > > > complexity > > > > AS code in the BlockWalker/Emitter part of the > compiler. When > > I do > > > so, I > > > > think I see the same question being asked over and over > again, > > such > > > as > > > > resolving an identifier, or checking if the parent node > is a > > > > MemberAccessExpression and more. I believe that caching > > information > > > in a > > > > data structure passed down through the emitters would > > significantly > > > reduce > > > > the number of questions asked and thus speed things up. > > Naturally, > > > caching > > > > more stuff will introduce caching bugs, but I expect it > would > > > eventually > > > > pay off. I do worry about some issues around > ActionScript and > > > > "late-binding" (which is not the related to > data-binding) and > > that > > > caching > > > > will screw that up. > > > > > > > > > > Smaller, potentially interesting projects include > playing > > around > > > with > > > > subsetting AS. I believe there are parts of AS that > require > > > late-binding > > > > and scopes and other stuff that may not exist on other > > runtimes, and > > > it is > > > > possible that by warning when those parts of AS are used > > (custom > > > > namespaces, for example), then if folks write their code > > without > > > custom > > > > namespaces they could get a significant compiler speed > increase > > > because the > > > > compiler doesn't have to worry about late-binding. The > > interesting > > > result > > > > of doing this may be better options for outputting WASM, > Java, > > C, > > > and other > > > > stricter languages. > > > > > > > > > > There is also a potentially interesting task around > > combining, for > > > > example, Basic.swc and BasicJS.swc into one > multi-platform SWC. > > > That would > > > > save time on compiling the entire framework, but would > require > > > tooling > > > > changes and build script changes. The advantage is that > it > > would > > > only > > > > transpile AS to JS once. Right now, the transpile is > run once > > for > > > > Basic.swc and again for BasicJS.swc. It could be > possible to > > steal > > > the > > > > already transpiled JS from Basic.swc. Or maybe the > copying of > > the > > > JS files > > > > will still be a performance bottleneck. The advantage > is also > > that > > > there > > > > is only one SWC to deploy instead of two which might > simplify > > Maven > > > as well. > > > > > > > > > > HTH, > > > > > -Alex > > > > > > > > > > > > > > > > > > > > > > > > > On 6/14/19, 7:11 PM, "Josh Tynjala" < > [email protected]> > > > wrote: > > > > > > > > > > Understood. I'll switch my focus and see if I can > find > > some low > > > > hanging fruit. > > > > > > > > > > - Josh > > > > > > > > > > On 2019/06/15 01:51:48, Harbs < > [email protected]> > > wrote: > > > > > > I had a long discussion with Alex last night > (sorry you > > > couldn’t > > > > make it!) and he convinced me of the necessity of > caution in > > regard > > > to > > > > adding these language features. Waiting until we get the > input > > of a > > > > language specialist is prudent. > > > > > > > > > > > > I do want those features, but we do need to > figure out > > how > > > they > > > > fit into a bigger picture of generics and the like. I’d > like to > > > brainstorm > > > > on how we can get a language specialist involved enough > to at > > least > > > guide > > > > us here. > > > > > > > > > > > > In discussing with Alex what’s the best avenue > for > > improving > > > the > > > > compiler in the short term, the topic of performance > came up. > > That’s > > > been > > > > somewhat of a pain point and working on that is probably > a > > good idea. > > > > > > > > > > > > Harbs > > > > > > > > > > > > > On Jun 14, 2019, at 2:11 PM, Josh Tynjala < > > > > [email protected]> wrote: > > > > > > > > > > > > > > I asked because I don't understand your > question > > either. > > > > > > > > > > > > > > Harbs wants something similar to a Vector, > with two > > > important > > > > features. > > > > > > > > > > > > > > 1) No runtime type checking. > > > > > > > 2) It should also be able to convert to and > from an > > untyped > > > > Array with some kind of simple cast at compile-time. At > > runtime, it > > > is just > > > > an untyped Array. > > > > > > > > > > > > > > I don't see how Uint8Array can work for this. > As I > > > understand > > > > it, Uint8Array seems to be numeric only and isn't > actually the > > same > > > as an > > > > Array. > > > > > > > > > > > > > > I should probably just leave it to him to > explain, > > though. > > > It's > > > > his vision, and I'm just the guy implementing it for him. > > > > > > > > > > > > > > - Josh > > > > > > > > > > > > > > On 2019/06/14 20:58:34, Alex Harui > > > <[email protected]> > > > > wrote: > > > > > > >> I'm not sure I understand the question. I > suspect > > it > > > would be > > > > up to the implementors of a typed array implementation to > > decide. > > > There > > > > may not be one solution that works for everyone. The > compiler > > could > > > > disallow it, or the implementation could AMF encode the > > instance, or > > > the > > > > implementation could throw an error. > > > > > > >> > > > > > > >> -Alex > > > > > > >> > > > > > > >> On 6/14/19, 1:53 PM, "Josh Tynjala" < > > > [email protected]> > > > > wrote: > > > > > > >> > > > > > > >> How do you store a String, or any random > class, > > in > > > > Uint8Array? > > > > > > >> > > > > > > >> - Josh > > > > > > >> > > > > > > >> On 2019/06/14 20:31:28, Alex Harui > > > <[email protected]> > > > > wrote: > > > > > > >>> IMO, I would not expect the edge cases around > > "abstract" > > > and > > > > "private" to impact future language features as those > are only > > > allowed as > > > > "decorators" on definitions and those features, from a > language > > > standpoint, > > > > allowed new keywords where the grammar already allowed > > keywords. > > > > > > >>> > > > > > > >>> My concern around proposals for TypedArrays > such as > > > > Array.<int> or int[] are that those patterns can show up > in a > > lot > > > more > > > > places and if we don't pick the right syntax, we'll be > sorry > > later > > > when we > > > > try to do typed function signatures or generics or > something > > else. > > > AIUI, > > > > you have to think through where else ".", "<", ">", "[" > and > > "]" are > > > used in > > > > the language and make sure your new use for them won't > cause > > > conflicts now, > > > > or even worse, in the future. And consider the general > > usability and > > > > coercion rules and probably other things that I don't > even > > know to > > > consider > > > > since I am not a language designer. Sure, Vector > already uses > > > ".<>", but > > > > it appears those uses are mapped to a special construct > in the > > > compiler, > > > > and that's why my suggestions for TypedArrays try to > provide > > > directives for > > > > the output of that construct instead of adding a new > construct > > until > > > we are > > > > sure that other future plans won't be compromised by how > we > > support > > > > TypedArrays now. > > > > > > >>> > > > > > > >>> For example, the name Vector implies > one-dimension > > to > > > me. But > > > > I could imagine folks wanting to add support for > > multi-dimensional > > > Arrays. > > > > Or the equivalent of Java Maps. > > > > > > >>> > > > > > > >>> Or, what will be the proposed literal for > Typed > > Arrays > > > if you > > > > use Array.<int>? Will it be the same or different from > Vector > > > literal? > > > > > > >>> > > > > > > >>> For sure, I don't think there is anybody > active in > > the > > > project > > > > who is opposed to supporting new language features like > > generics, > > > typed > > > > functions and typed arrays. I'm just asking questions > to make > > sure > > > we > > > > really need this work done now instead of doing something > > cheaper > > > and make > > > > sure folks who do work on it think through the future > > implications > > > of it. > > > > > > >>> > > > > > > >>> We already use directives to make > "promises". For > > > example, > > > > when you use @royaleignorecoercion, you promise that no > code > > paths > > > will > > > > actually depend on that coercion, you just added the > coercion > > to > > > keep the > > > > compiler from complaining. And if it turns out you > needed it, > > > you'll end > > > > up with a bug. We could do something similar now like > > > > @royaleusetypedarrayforthisvector and if other code ends > up > > turning > > > off the > > > > "fixed" property and push stuff you'll end up with a > bug. I > > think > > > that > > > > would only take someone a week or less. > > > > > > >>> > > > > > > >>> Or as I asked earlier, why can't folks just > use > > > Uint8Array? > > > > > > >>> > > > > > > >>> HTH, > > > > > > >>> -Alex > > > > > > >>> > > > > > > >>> On 6/14/19, 11:08 AM, "Josh Tynjala" < > > > [email protected]> > > > > wrote: > > > > > > >>> > > > > > > >>> I definitely understand your concern about > > potentially > > > > missing edge cases, and having that cause problems in the > > future. > > > That's > > > > why I've been trying to make new language features > disabled by > > > default so > > > > that folks need to knowingly opt in. > > > > > > >>> > > > > > > >>> In my opinion, we should have left > abstract > > classes > > > and > > > > private constructors disabled by default for a while, > until > > more > > > people > > > > could give them a try. These features haven't even been > > included in > > > an > > > > official release yet. While I have a pretty good set of > unit > > tests > > > for each > > > > one, I'm sure that there are still some edge cases that > I'll > > need to > > > > address in the future. > > > > > > >>> > > > > > > >>> - Josh > > > > > > >>> > > > > > > >>> > > > > > > >>> On 2019/06/14 17:39:53, Alex Harui > > > <[email protected]> > > > > wrote: > > > > > > >>>> IMO, it will be a significant amount of > work to > > provide > > > new > > > > syntax around typed collections to ActionScript. I > cannot > > help here > > > > because I am not a language expert. Having interacted > briefly > > with > > > the > > > > ActionScript language team, I am certain I do not have > the > > skills to > > > help > > > > here and am concerned that we'll miss something and be > sorry > > later. > > > > > > >>>> > > > > > > >>>> So, as long as folks are aware of that and > still > > want > > > to go > > > > forward, I'm not going to stand in their way. I am > going to > > suggest > > > easier > > > > ways that might save some time because I think there are > > bigger fish > > > to fry > > > > with the limited folks we have contributing to Royale. > I'd > > rather > > > see a > > > > quick way of allowing folks to use TypedArrays to see how > > > useful/important > > > > it is and then see if we can make Royale successful and > recruit > > > someone > > > > with language design experience. > > > > > > >>>> > > > > > > >>>> IOW, creating the general case > implementation > > starting > > > now > > > > may not be in the best interests of the project. I would > > rather we > > > make > > > > migrating Flex code easier/faster, and those folks may > not > > have time > > > to > > > > consider changing their code to switch to TypedArrays. > > > > > > >>>> > > > > > > >>>> Just from some quick thinking, I would say > that > > getting > > > the > > > > parser to handle some new syntax is only 25% of the work. > > Another > > > 10% is > > > > in getting the output right for JS, but the remaining > 65% is > > handling > > > > semantics, ambiguity, and output to other runtimes. > > > > > > >>>> > > > > > > >>>> Also, since Array is "final", I think it > would be > > more > > > work > > > > to support Array.<int> than TypedArray.<int>. And > probably > > even > > > easier > > > > just to support the exact same classnames and APIs that > > JavaScript > > > supports > > > > today. Is there some reason that Uint8Array doesn't work > > today? > > > > > > >>>> > > > > > > >>>> I'd prefer that we take the time to find an > > expert to > > > help us > > > > really think through how we will implement generics in > general > > in AS > > > > someday, and handle Typed Arrays as an initial > implementation > > on > > > that path > > > > so we don't later go "oh crap, if we hadn't picked this > > particular > > > syntax > > > > for typed arrays, our generics support would be so much > > simpler!". > > > I just > > > > know I cannot help here, but I caution against just > copying > > what > > > Java or > > > > Typescript does. I think there are patterns in > ActionScript > > that are > > > > different from Java and TS that might factor in. > > > > > > >>>> > > > > > > >>>> So, go for it if you want, but please > consider > > future > > > > ramifications. > > > > > > >>>> > > > > > > >>>> -Alex > > > > > > >>>> > > > > > > >>>> On 6/12/19, 5:20 PM, "Greg Dove" < > > [email protected]> > > > wrote: > > > > > > >>>> > > > > > > >>>> Alex, javascript TypeArrays are fixed > length at > > > > construction, so I really > > > > > > >>>> don't think that can work in general > case for > > drop-in > > > > substitution of > > > > > > >>>> numeric Vector without some sort of > wrapper > > class > > > that > > > > supports swapping > > > > > > >>>> things out. > > > > > > >>>> I really think that dedicated 'fast' > numeric > > > collection > > > > types will likely > > > > > > >>>> need their own cross-target classes. > > > > > > >>>> It would work for a Vector that has a > fixed = > > true > > > > constructor arg and then > > > > > > >>>> never changes its 'fixed' status (and > > therefore never > > > > changes its length > > > > > > >>>> also) and also only uses index access and > > > assignments (no > > > > push, pop etc), > > > > > > >>>> but it's a pretty restrictive scenario. > I did > > look > > > at this > > > > already. > > > > > > >>>> It might also be possible to map default > Vector > > > numeric > > > > types to 'faster' > > > > > > >>>> versions for the 3 types, as an opt-in > to the > > default > > > > implementation's > > > > > > >>>> approach. I do plan to work > on/investigate this > > > later this > > > > month, because I > > > > > > >>>> am keen to see performance-oriented > options > > here > > > too. But > > > > I was thinking > > > > > > >>>> they would likely be separate, dedicated > > classes. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> On Thu, Jun 13, 2019 at 11:27 AM Alex > Harui > > > > <[email protected]> > > > > > > >>>> wrote: > > > > > > >>>> > > > > > > >>>>> FWIW, I would expect any syntax changes to > be a > > > significant > > > > amount of work > > > > > > >>>>> especially where the BURM does the semantic > > checks. > > > New > > > > BURM patterns are > > > > > > >>>>> probably required. Or maybe it is time to > get > > the > > > BURM out > > > > of the > > > > > > >>>>> semantic-check business for JS (and maybe > SWF) > > output > > > and > > > > figure out how to > > > > > > >>>>> do the semantic checks from the JS AST > walk. > > > > > > >>>>> > > > > > > >>>>> Did you out finding a way to indicate that > some > > > Vector.<int> > > > > should be > > > > > > >>>>> implemented as a TypedArray? > > > > > > >>>>> > > > > > > >>>>> -Alex > > > > > > >>>>> > > > > > > >>>>> On 6/12/19, 3:18 PM, "Josh Tynjala" < > > > [email protected]> > > > > wrote: > > > > > > >>>>> > > > > > > >>>>> I plan to start out by supporting > Array.<T> > > syntax, > > > > similar to > > > > > > >>>>> Vector.<T>. Like you said, there are > advantages > > to > > > using the > > > > same syntax > > > > > > >>>>> for all typed collections. > > > > > > >>>>> > > > > > > >>>>> Later, I'll see if I can figure out how > to > > add T[] > > > syntax > > > > as an > > > > > > >>>>> alternative, since Harbs seems to like that > > better. > > > > > > >>>>> > > > > > > >>>>> - Josh > > > > > > >>>>> > > > > > > >>>>> On 2019/06/12 20:14:50, Greg Dove < > > > [email protected]> > > > > wrote: > > > > > > >>>>>> Hey Josh, > > > > > > >>>>>> > > > > > > >>>>>> Thanks for looking into that, I figured it > > could be a > > > bit > > > > tricky! > > > > > > >>>>> Good luck > > > > > > >>>>>> with it. > > > > > > >>>>>> I think you and Harbs were maybe leaning > to > > towards > > > > Number[] and > > > > > > >>>>> String[] > > > > > > >>>>>> type declarations. I don't mind either > way, but > > > perhaps the > > > > Array. > > > > > > >>>>> with > > > > > > >>>>>> angle brackets approach that is used for > Vectors > > > could make > > > > it > > > > > > >>>>> easier to > > > > > > >>>>>> swap between typed Array and Vector if > people > > consider > > > > refactoring > > > > > > >>>>> (and > > > > > > >>>>>> whatever IDE they're using won't support > more > > > automated > > > > changes). > > > > > > >>>>> OTOH, the > > > > > > >>>>>> first approach is definitely easier to > type. You > > > probably > > > > already > > > > > > >>>>> thought > > > > > > >>>>>> those things through though, I guess. > > > > > > >>>>>> > > > > > > >>>>>> If you end up with a remote branch for > your > > work on > > > this at > > > > some > > > > > > >>>>> point and > > > > > > >>>>>> want someone to help with testing or > anything > > like > > > that, > > > > I'm in, > > > > > > >>>>> just let > > > > > > >>>>>> me know. > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> On Thu, Jun 13, 2019 at 2:26 AM Josh > Tynjala < > > > > [email protected]> > > > > > > >>>>> wrote: > > > > > > >>>>>> > > > > > > >>>>>>>> I think your other proposal with Josh > for the > > typed > > > > Arrays and > > > > > > >>>>> their > > > > > > >>>>>>> greater compile-time safety will be a > better > > fit for > > > many > > > > cases as > > > > > > >>>>> well, so > > > > > > >>>>>>> I hope that happens. > > > > > > >>>>>>> > > > > > > >>>>>>> I started working on typed arrays this > week. > > It may > > > be a > > > > while > > > > > > >>>>> before I > > > > > > >>>>>>> can merge, though. It's definitely more > > complex than > > > > private > > > > > > >>>>> constructors > > > > > > >>>>>>> and abstract classes. > > > > > > >>>>>>> > > > > > > >>>>>>> - Josh > > > > > > >>>>>>> > > > > > > >>>>>>> On 2019/06/12 04:21:18, Greg Dove < > > > [email protected]> > > > > wrote: > > > > > > >>>>>>>> Hi Harbs - just in reply to your > specific > > questions: > > > > > > >>>>>>>> As I mentioned elsewhere it is easy to > have > > full > > > speed > > > > index > > > > > > >>>>> access and > > > > > > >>>>>>>> also full speed pop() and unshift() > methods > > > > > > >>>>>>>> If you switch off the first 3 settings I > > outlined > > > in the > > > > post > > > > > > >>>>> titled > > > > > > >>>>>>>> 'Language/Reflection improvements > details' > > you will > > > have > > > > that. > > > > > > >>>>> Those > > > > > > >>>>>>>> settings are switchable locally with doc > > directives > > > as > > > > well. I > > > > > > >>>>> will do a > > > > > > >>>>>>>> full write-up this coming weekend for > docs. > > > Hopefully I > > > > can > > > > > > >>>>> harvest a lot > > > > > > >>>>>>>> of what I already wrote elsewhere for > that. > > > > > > >>>>>>>> BTW I switched TLF to use the legacy > > Vector-as-Array > > > > approach by > > > > > > >>>>>>> default, I > > > > > > >>>>>>>> am not sure what you want there, you > could > > undo > > > that if > > > > you > > > > > > >>>>> prefer. > > > > > > >>>>>>>> > > > > > > >>>>>>>> Beyond the above mentioned approaches > for > > (mainly > > > index > > > > level) > > > > > > >>>>>>>> optimization, I have a preference for > two more > > > > approaches, but > > > > > > >>>>> I'd rather > > > > > > >>>>>>>> limit the overall number of options to > be what > > > people > > > > definitely > > > > > > >>>>> need > > > > > > >>>>>>>> instead of adding too many options > (which > > could > > > create > > > > > > >>>>> confusion). I > > > > > > >>>>>>> think > > > > > > >>>>>>>> your other proposal with Josh for the > typed > > Arrays > > > and > > > > their > > > > > > >>>>> greater > > > > > > >>>>>>>> compile-time safety will be a better > fit for > > many > > > cases > > > > as well, > > > > > > >>>>> so I > > > > > > >>>>>>> hope > > > > > > >>>>>>>> that happens. If I have time to help > out in > > any way > > > with > > > > that, I > > > > > > >>>>> would be > > > > > > >>>>>>>> happy to do so as well, because it > sounds like > > > something > > > > I would > > > > > > >>>>> use a > > > > > > >>>>>>> lot. > > > > > > >>>>>>>> Anyhow, I do want to support more > > optimizations > > > with this > > > > > > >>>>> implementation. > > > > > > >>>>>>>> Can you say what your main concerns > would be > > for > > > > optimization? > > > > > > >>>>> Is it > > > > > > >>>>>>> mainly > > > > > > >>>>>>>> for 'push' (and unshift) ? Those would > be > > mine... > > > > > > >>>>>>>> > > > > > > >>>>>>>> I would personally like to see the > following: > > > > > > >>>>>>>> > > > > > > >>>>>>>> 1. A global optimization setting that > affects > > all > > > > instances in > > > > > > >>>>> all code > > > > > > >>>>>>>> including pre-built library code. This > would > > avoid > > > certain > > > > > > >>>>> runtime checks > > > > > > >>>>>>>> and would also result in a lighter > > implementation. > > > This is > > > > > > >>>>> something the > > > > > > >>>>>>>> final application developer decides, not > > anything > > > > dictated by a > > > > > > >>>>> library > > > > > > >>>>>>>> developer (but a library developer could > > advertise > > > their > > > > public > > > > > > >>>>> swc as > > > > > > >>>>>>>> being compatible/safe with this type of > > > optimization). > > > > This > > > > > > >>>>> approach > > > > > > >>>>>>> could > > > > > > >>>>>>>> include perhaps 2 levels: one to remove > any > > code > > > paths > > > > related > > > > > > >>>>> to fixed > > > > > > >>>>>>>> length Vectors (which I think you said > you > > never > > > used) for > > > > > > >>>>> example. Then > > > > > > >>>>>>>> another possibly removing all element > level > > > type-checking > > > > as > > > > > > >>>>> another > > > > > > >>>>>>> level. > > > > > > >>>>>>>> Adding this should not be too difficult > I > > think and > > > would > > > > be > > > > > > >>>>> determined > > > > > > >>>>>>> via > > > > > > >>>>>>>> a goog define (which might be driven by > a > > compiler > > > > setting, I > > > > > > >>>>> did not > > > > > > >>>>>>> look > > > > > > >>>>>>>> at how easy this is yet). The thing I > like > > about > > > this > > > > approach > > > > > > >>>>> is that it > > > > > > >>>>>>>> is not 'baked-in' to any instance and > the > > > application > > > > developer > > > > > > >>>>> makes the > > > > > > >>>>>>>> ultimate decision and owns the > associated > > risk (as > > > > opposed to > > > > > > >>>>> having it > > > > > > >>>>>>>> imposed on them by a library developer, > for > > > example). I > > > > think > > > > > > >>>>> the removal > > > > > > >>>>>>>> of support for 'fixed' Vectors could > probably > > be > > > made to > > > > generate > > > > > > >>>>>>>> (debug-only) errors if there is code > that > > runs that > > > sets > > > > fixed > > > > > > >>>>> to true on > > > > > > >>>>>>>> any Vector instance - to provide some > > reassurance > > > of no > > > > side > > > > > > >>>>> effects > > > > > > >>>>>>> when > > > > > > >>>>>>>> choosing this option. > > > > > > >>>>>>>> > > > > > > >>>>>>>> 2. Compilation scoped optimizations. > > > > > > >>>>>>>> By 'compilation-scoped' I mean > configurable > > in the > > > same > > > > way as > > > > > > >>>>> the > > > > > > >>>>>>>> vector-index-check suppression: An > > over-arching > > > config > > > > setting > > > > > > >>>>> for the > > > > > > >>>>>>>> current compilation that can be > overridden > > locally > > > with > > > > doc > > > > > > >>>>> comment > > > > > > >>>>>>>> directives. This affects code sites (or > all > > current > > > > compilation > > > > > > >>>>> scope if > > > > > > >>>>>>>> set in the config) and not specific > > instances. I > > > would > > > > hope this > > > > > > >>>>> might be > > > > > > >>>>>>>> the only other 'Vector' specific config > > option like > > > this, > > > > simply > > > > > > >>>>> to avoid > > > > > > >>>>>>>> confusion with too many options. > > > > > > >>>>>>>> So I personally think the important > things > > here are > > > the > > > > push and > > > > > > >>>>> unshift > > > > > > >>>>>>>> methods, because they're the ones that > are > > also most > > > > often used > > > > > > >>>>> in loops > > > > > > >>>>>>>> when index level access or assignment > is not > > being > > > used > > > > (in the > > > > > > >>>>> loop). > > > > > > >>>>>>> But > > > > > > >>>>>>>> I'm keen to hear more about what people > want > > in > > > case it's > > > > > > >>>>> different to > > > > > > >>>>>>> how > > > > > > >>>>>>>> I think. And I will add support for > what best > > > represents > > > > the > > > > > > >>>>> needs of the > > > > > > >>>>>>>> community. While index level access is > best > > for > > > large > > > > loops > > > > > > >>>>> (just as it > > > > > > >>>>>>> is > > > > > > >>>>>>>> for 'Array'), push could be preferred in > > small loops > > > > because it > > > > > > >>>>> does not > > > > > > >>>>>>>> require a 'get' for length to establish > the > > upper > > > bound > > > > of the > > > > > > >>>>> loop or > > > > > > >>>>>>> the > > > > > > >>>>>>>> next acceptable index to set (for > non-fixed > > > Vectors). The > > > > > > >>>>> optimization > > > > > > >>>>>>> for > > > > > > >>>>>>>> push in this case would be to bypass > runtime > > > typechecking > > > > and > > > > > > >>>>> just do a > > > > > > >>>>>>>> regular Array.push into the underlying > Vector > > > > representation, > > > > > > >>>>> which is > > > > > > >>>>>>>> still actually an Array in terms of how > > javascript > > > sees > > > > it. > > > > > > >>>>> Adding this > > > > > > >>>>>>>> option is easy also, but rather than > just > > forging > > > ahead > > > > with it, > > > > > > >>>>> I am > > > > > > >>>>>>> keen > > > > > > >>>>>>>> to get input from others first. > > > > > > >>>>>>>> > > > > > > >>>>>>>> I consider that specific instance level > > > optimizations (in > > > > > > >>>>> general) are > > > > > > >>>>>>>> 'dangerous' because even if the code is > > 'safe' when > > > it is > > > > > > >>>>> originally > > > > > > >>>>>>>> written, subsequent changes to the > overall > > codebase > > > > (possibly by > > > > > > >>>>>>> different > > > > > > >>>>>>>> developers) can mean that an instance > ends up > > > elsewhere > > > > in code > > > > > > >>>>> where it > > > > > > >>>>>>>> behaves differently from other > instances of > > the > > > same type. > > > > > > >>>>> Code-site > > > > > > >>>>>>>> optimizations could also create an > unusual > > internal > > > state > > > > for an > > > > > > >>>>>>> instance, > > > > > > >>>>>>>> but most often they should not, because > the > > code > > > site > > > > where the > > > > > > >>>>>>>> optimization is used should be > validated in > > terms > > > of the > > > > > > >>>>> optimization by > > > > > > >>>>>>>> its original developer (e.g. no runtime > type > > > checking at a > > > > > > >>>>> particular > > > > > > >>>>>>> usage > > > > > > >>>>>>>> site because it is never needed in the > > context of > > > that > > > > code, for > > > > > > >>>>> example) > > > > > > >>>>>>>> and the behavior of the same instance > > elsewhere > > > should be > > > > much > > > > > > >>>>> less of a > > > > > > >>>>>>>> risk. > > > > > > >>>>>>>> > > > > > > >>>>>>>> More feedback from you or anyone else is > > definitely > > > > welcome for > > > > > > >>>>> what they > > > > > > >>>>>>>> want to see for optimization options of > the > > > > implementation. I'm > > > > > > >>>>> sure I > > > > > > >>>>>>> can > > > > > > >>>>>>>> still find more ways to improve the > > implementation > > > for > > > > speed as > > > > > > >>>>> it is now > > > > > > >>>>>>>> as well, I can think of a one thing I > want to > > > investigate > > > > > > >>>>> further. > > > > > > >>>>>>>> -Greg > > > > > > >>>>>>>> > > > > > > >>>>>>>> > > > > > > >>>>>>>> > > > > > > >>>>>>>> > > > > > > >>>>>>>> On Wed, Jun 12, 2019 at 1:54 AM Harbs < > > > > [email protected]> > > > > > > >>>>> wrote: > > > > > > >>>>>>>> > > > > > > >>>>>>>>> Practical question for me is: How do we > > disable to > > > Vector > > > > > > >>>>> runtime > > > > > > >>>>>>>>> checking? I was having trouble > following the > > full > > > > discussion. > > > > > > >>>>> My > > > > > > >>>>>>>>> understanding was that there’s a > compiler > > flag, > > > but I’m > > > > not > > > > > > >>>>> sure what > > > > > > >>>>>>> it is. > > > > > > >>>>>>>>> > > > > > > >>>>>>>>>> On Jun 11, 2019, at 7:10 AM, Yishay > Weiss < > > > > > > >>>>> [email protected]> > > > > > > >>>>>>>>> wrote: > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> Language.js:868 [1] is > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> if (elementType.indexOf('Vector.<') > == 0) > > { > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> ________________________________ > > > > > > >>>>>>>>>> From: Yishay Weiss < > [email protected]> > > > > > > >>>>>>>>>> Sent: Tuesday, June 11, 2019 2:07:36 > PM > > > > > > >>>>>>>>>> To: [email protected] > > > > > > >>>>>>>>>> Subject: Problem with Vectors > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> Hi Greg, > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> I just updated Royale and I’m seeing > that > > in our > > > class > > > > > > >>>>> FontLoader > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> private var _fonts:Vector.<Font> = new > > > Vector.<Font>(); > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> gets transpiled to > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> > > this.com_printui_text_engine_FontLoader__fonts = > > > > > > >>>>>>>>> > org.apache.royale.utils.Language.Vector(); > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> Notice how the type isn’t given in > Vector’s > > > > constructor. This > > > > > > >>>>>>> results in > > > > > > >>>>>>>>> a runtime error [1]. Any ideas? > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> [1] > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> TypeError: Cannot read property > 'indexOf' > > of null > > > > > > >>>>>>>>>> Watch > > > > > > >>>>>>>>>> Call Stack > > > > > > >>>>>>>>>> > > > > > > >>>>> > > > > > > org.apache.royale.utils.Language.VectorSupport.vectorElementCoercion > > > > > > >>>>>>>>>> Language.js:868 > > > > > > >>>>>>>>>> > org.apache.royale.utils.Language.synthVector > > > > > > >>>>>>>>>> Language.js:642 > > > > > > >>>>>>>>>> > org.apache.royale.utils.Language.Vector > > > > > > >>>>>>>>>> Language.js:685 > > > > > > >>>>>>>>>> com.printui.text.engine.FontLoader > > > > > > >>>>>>>>>> FontLoader.js:24 > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>> > > > > > > >>>>>>>>> > > > > > > >>>>>>>> > > > > > > >>>>>>> > > > > > > >>>>>> > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3c4c6db7b4354534e6ac08d6fbf6acfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636973434250086201&sdata=0%2Bkpn7v%2BdnBuqyMHGOS%2F18fIPdfHkb9Dpy4bdoHlsx0%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
