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 > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>> > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> > > > >> > > > >> > > > >> > > > > > > > > > > > > >
