Awesome! :-)
> On Jun 27, 2019, at 12:42 AM, 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
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
