Congrats Josh! yeah! prints use to slow down compilations so great fix! :))
El jue., 27 jun. 2019 a las 16:58, Kenny Lerma (<[email protected]>) escribió: > I had some suspicions about the logs slowing things down. I have 100s of > very large projects and just tried the new build...amazing. > > I went from 80 seconds down to 20 in build time. This is huge for me! > Please keep going! :) > > Kenny > > On Wed, Jun 26, 2019 at 4: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 http://about.me/carlosrovira
