Hi Greg, Well I definitely in the very last steps, but if I won't be able to figure out how to upload artifacts I'm not sure whether we will not stuck for the next couple of weeks. :(
Thanks, Piotr On Wed, Aug 14, 2019, 9:50 PM Greg Dove <[email protected]> wrote: > I should have drawn attention to this again before release work started... > I guess it is too late to get rid of that diagnostic output (described > below) from the compiler in the release? > It might be confusing output for some people, or create the wrong > impression, but perhaps it is too late in the process? > > On Wed, Jul 3, 2019 at 8:42 PM Greg Dove <[email protected]> wrote: > > > > > Just a quick followup to Harbs' earlier comment about the compiler noise. > > I'm seeing this a lot also. > > > > It looks like there is some leftover diagnostic logging in > > ControlFlowGraph.traverseGraph. Hopefully it can be removed or dialed > down. > > > > > > > > > > On Mon, Jul 1, 2019 at 7:06 AM Yishay Weiss <[email protected]> > > wrote: > > > >> I was also getting it before. > >> ________________________________ > >> From: Josh Tynjala <[email protected]> > >> Sent: Sunday, June 30, 2019 3:53:56 PM > >> To: [email protected] > >> Subject: Re: Compiler Performance (was Re: Problem with Vectors) > >> > >> Is this GC limit error something new? Or were you getting it before too? > >> > >> - Josh > >> > >> On Sun, Jun 30, 2019, 1:35 AM Yishay Weiss <[email protected]> > >> wrote: > >> > >> > On my windows/powershell env there’s a significant improvement (~34 > >> > seconds instead of ~42) when building our app with verbose switched > off. > >> > I’m getting a ‘GC overhead limit exceeded’ [1] error though quite > often > >> > which brings it up to around a minute and a half. Increasing heap size > >> by > >> > setting ANT_OPTS to -Xmx2g doesn’t seem to make a difference. > >> > > >> > > >> > > >> > [1] https://paste.apache.org/BXf4 > >> > > >> > > >> > > >> > ________________________________ > >> > From: Josh Tynjala <[email protected]> > >> > Sent: Friday, June 28, 2019 6:24:10 PM > >> > To: [email protected] > >> > Subject: Re: Compiler Performance (was Re: Problem with Vectors) > >> > > >> > Windows and PowerShell. > >> > > >> > 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. > >> > > >> > 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? > >> > > >> > - 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%7C3763ea8f30394ff716bd08d6fb534693%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636972732457464401&sdata=SxYcGgMT3qQi2zEaeJAPA0AYm2UnB7Ljm4PvE4b3A4c%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 > >> > > > > > >>>>>>>>>> > >> > > > > > >>>>>>>>> > >> > > > > > >>>>>>>>> > >> > > > > > >>>>>>>> > >> > > > > > >>>>>>> > >> > > > > > >>>>>> > >> > > > > > >>>>> > >> > > > > > >>>>> > >> > > > > > >>>>> > >> > > > > > >>>> > >> > > > > > >>>> > >> > > > > > >>>> > >> > > > > > >>> > >> > > > > > >>> > >> > > > > > >>> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > >
