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