Hi Alex, I think there is probably a difference with patchy connections between 'using an app' (content) and 'installing an app' (download) whether its mobile, desktop or web. I suspect that most of the experience you describe is 'using an app' whether it's git or anything else. And I do understand your frustration as a user of anything in the scenario described. I think it is particularly painful if you are doing something that is not loading web app code from a local browser cache. I accept that there is always a need for 'size' optimization in general and there can be specific needs for sure. What you can be sure of is that the problem with the network access is going in one direction, and that is away from the 2KB size problem. I see js apps in gzip sizes now that are not so dissimilar size to flex apps from 10 years ago. The big difference of course is much more mobile vs. desktop focus. As I said earlier in the thread, I believe the growth in bandwidth will continue to outpace the growth in bytesize of web apps. Perhaps not always their assets or other content, but in the apps themselves. Until the next big thing I guess... whatever that is.
But I'm obviously not getting my message through clearly on why I think it is a bad idea to propagate different versions 'of the same thing'. 1. I am definitely in favor of options, including size based options for those who need them. We are different in our thinking about priorities... that's fine and doesn't matter as long as there are options for whoever thinks whatever is more important. 2. I prefer options that do not have risks to Royale and its future ecosystem. The possibility to 'break' language level classes and expose them to others whose view of them remains unbroken is what drives my main concern. The risk is unknowable at this point but it is also avoidable. I'm guessing you either don't consider there are risks or you don't think they are important (relative to other things that you consider more important). Perhaps you think the risk is avoidable in ways I don't understand. If so, I am curious to know what they are. But right now I can't think of them, so... FWIW I think about XML in exactly the same way as Vector here. It's language, not application framework. They are both part of the language layer. As others have said, Vector and XML are like Date, Number etc. The fact that that they are 'emulated' in local code should be something to be aware of, but language is language. It either works as defined or it does not. In the past we downloaded 'language support' in flash player via its frequent updates. For Royale we need to download the selective non-native language pieces we use that deliver that same compatible support along with app itself. As a hypothetical, if javascript did not have a Date implementation and Royale had to (somehow) emulate that as well, I am curious to understand if you think it would be sensible to encourage multiple non-conforming implementations of Date (for whatever reason - better size/performance for example), given that it also is well specified. Perhaps you do think its ok, but I would not, and of course Date is not really a problem in javascript. But that's the same way I think of Vector, and I'm only using it to illustrate that. If we permit non-conforming implementations, we should warn people who make libraries not to do certain things (always keep references of this non-conforming type as 'private' or only use for local vars etc) otherwise they may expose language level features that will not be reliable elsewhere, because the alternate 'emulation' of that language class is baked into the library and can be different to the one used in other libraries or in the main app. I'm talking about public swc libraries, not private ones, but even in large teams it could be important to consider. Providing warnings about these risks itself seems cumbersome and also has negative connotations. "My understanding from the words you've written is that you want everyone to use your Vector implementation and have options on what code paths that implementation actually takes, but I don't understand why from a technical perspective." I don't think of this as 'my' Vector implementation. I do however want people to be able to use 'our' Vector implementation with confidence, which is why I posted so much information in this thread and asked others to try it. Outputting as Array is *not* an implementation of Vector... imo it is a placeholder waiting for one. Because there is nothing to distinguish it from a regular Array, at a very basic level it is a misrepresentation of strong typing. I'm not sure what you mean by 'technical perspective' here. There could be some technical issues if there was a need to be able to resolve two or more conflicting runtime representations of the same type (emulation class 1 in public library 1, emulation class 2 in public library 2 and default Vector implementaion in the main app, all with instances made available to the main app, for example), and I do actually wonder about runtime weight of code that might be required to do that if it was needed, but I am sure any technical issues could be overcome. My main concern is not technical. My main concern is to do with quality and reputation and reliability and dependability as it relates to how others perceive Royale if things like this arose. I imagine a new developer taking over from someone else in a large project team would have to be warned to be careful with something because it does not behave as the language reference says it should in all cases... even though the compiler and the IDE that he or she is using both 'think' it should. Or if they are *not* warned or otherwise informed, for them to be thinking expletive-ridden thoughts about the project or about Royale when things start to get strange for them. I imagine my colleagues on client React projects who might try Royale at my suggestion encountering something like this and I wince at the type of feedback I would get because the published apis for the libraries they use 'sometimes only partially work' and other times fully work when they expose emulation instances or Arrays masquerading as Vectors. Apart from people having bad experiences like that, there is also the possibility of some people writing code that works 'correctly' because of a dependence on something else that doesn't work right (because it is non-conforming) and that code may then subsequently 'not work' if there was later a change to the emulation class in the dependency and it became 'more conformant'. It's not the same things, but I experienced something sort of like this with the AMF code that you originally ported which had errors in the original js source (to be clear:not in your port of the original, but in the original itself, so the errors were ported as-is), errors that I can only assume were reinforced in a closed loop by the companion serverside library that the original js lib was paired with - fixing one and making it correct would break compatibility with the other in that case. If there is the possibility to have multiple representations of the same Vector type via different 'emulations' then I think these risks are real. I don't know how big the risk is. But unless I am missing something, I am pretty sure the risk is not zero. And I know it is possible to make it zero. My earlier comments about 'code paths' (if I have interpreted that correctly) was more about trying to address options for tuning the performance of the implementation in the branch. I have thought through some options for these, but again I am hesitant to do things that add complexity/config options which might never be used, so I would prefer to do it based on need. And I would like to add more alternative options before we settle on the 'needs' for Vector tuning because maybe the needs are better served with alternatives.( note: I mean other classes, not Vector emulation class alternatives) I'll make some quick comments about some of those in the other points you mentioned. Then it's time to stop.... why? because: too much text. "-Vector and XML and any other built-in for SWF that isn't in JS are not free. We have to write some amount of code to get them to work. " Yes that is normal. I like to think of it as little bits of the flash player that are relevant to the app they are blended with in javascript. Other languages/frameworks do exactly the same thing for the language level stuff. "-Vector provides runtime type checking. Not everybody needs runtime type checking in production." Agreed, but runtime checking is what it does by default and some people *will* want it in production. For implicit coercions of non-primitive types on assignment there is already a way to switch that off in the branch. That has local build scope or local method scope via doc comment directive. Note, this feature is not Vector specific. It is off by default in the framework. This would mean that when switched off you can do myThingVec[0] = SomethingThatIsNotAMyThing and it would end up in your Vector instance even though it should not. But you can eliminate those cases with it switched on and then switch it off later. For methods like push and unshift etc there is nothing to dial that back yet, but I could easily add support to bypass the runtime checking and directly call the native Array methods, without any extra byte-weight by simply switching those calls to use Array.prototype.push.call(inst, args). It looks long, but that will compress *extremely* well via gzip based on most of it being repeated and on how gzip favors repeated string sequences. This could also be via call site (containing method) or build level settings. I think it is risky to make this instance based, because the instance could be exposed to external code that requires it to work with type safety in places it is used elsewhere. The presumption is that any library that used the 'unsafe' optimizations made sure they were 'safe' but external code should not have that assumption by default. "-Vector provides length checking. Not everybody needs length checking in production. " This is switchable off already for the index level assignments. It was an obvious one. It can be switched off for all Vectors in the build, although explicit local settings to force it on win if someone wants it on only for specific cases with a build setting off. If you want to avoid length checking in the runtime with the length setter, that is also possible to avoid that now with dynamic access, but I have not explained that anywhere. basically myVec['length'] = 10 should do that now. Setting length explicitly is usually relatively rare compared to doing stuff with the contents. But if it was deemed necessary to add a setting for that to avoid using the above approach, I could do that. I just don't want to add un-needed configuration options for the sake of it. "-We've already proven that by having at least two projects get into production without your implementation of Vector. -The current compiler output for Vector for folks who don't need runtime checking just uses Array." It sounds like Harbs might have used it a lot, but Carlos' app does not use Vectors - only Array and ArrayList. I can't consider the private beads IBead thing is a definitive validation of Array-as-Vector in Carlos' production build. For the TypedArray stuff it really only makes sense as a fixed Vector, not as one with fixed=false. I already made some suggestions about these to Harbs. Harbs thought the benefits might be dubious because of how optimizations work in V8 etc, but I would be surprised if there was not at least some small advantage, so I will check and if yes, I will work on that regardless. I did consider these already in the early stages of the branch implementation and it does not lend itself as a dropin replacement for Vector with the Vector api, which permits toggling of fixed, unless you had wrapper class that can toggle between Array and TypedArray - overall it would be heavier than the implementation in the branch. In terms of size, I probably still will be able to shave a few bytes off, but returns for gzip can be marginal relative to effort when you get close and sometimes you get more gzipped bytes for smaller minified code - because of how gzip compression works best with repeated text (although GCC does know this stuff and tries to do the right thing I think). Hopefully I have outlined what I think are potential risks with Vector-as-Array or emulation alternatives. You either agree with what I explained or you don't. If you have a reason why it will never be a problem because I was thinking about it wrong, then great, I'll be happy to hear that. If the consensus from the team is that there needs to be an Array output option Vector, then let me know. React has a performance option name I really like for something that makes me think of things like this: dangerouslySetInnerHTML. I'd certainly prefer the other options Harbs mentioned with compiletime only typed Arrays - which is what Haxe also does (it limits some of the api though, you can only push one element at a time for example without breaking out into target level code switches). But if majority still wants a Vector as Array option after (possibly) reading everything I wrote then I will add it. You can just reply to this thread or if someone wants to create a voting thread for that, I'm good with the results. But I will never endorse using it myself. If I want Array in javascript, I will make my code honest and make it an Array (or use some new typed array option which gives me the compiletime only support!). Slightly OT, but the only major thing left is a good Dictionary implementation. That has one insurmountable challenge... because although we can use weak keys now, it is impossible to enumerate over weak keys in javascript. But apart from that (which is really something I will miss compared to swf) it should be able to get pretty close i think. I will wait a couple more days to hear back about the Array thing, or in case people get the chance to try this branch and provide specific feedback. Otherwise I will merge it, because I consider it ready to do so. If the Array decision comes in after that, I will do it in develop. On Tue, May 28, 2019 at 6:43 AM Alex Harui <[email protected]> wrote: > Hi Greg, > > I live outside of Seattle. I'm in my house right now, and my cellphone > says I have a 4G connection. Many times a month, I take a ferry boat to > Seattle. There is a point during the ride where the connectivity is poor. > Yesterday, I was trying to get work done on the ferry and was blocked from > doing one step in the release automation because it would not load in > time. Many times, I'm trying to get one thing finished and get stymied by > poor connectivity. I hear this complaint from plenty of other residents > where I live. I want Royale to produce the app that loads when other apps > don't. Forcing everyone to take on another 2000+ bytes is not going to > help. > > The argument of "it is only another 1K" is what eventually caused > UIComponent to grow to 13,000 lines and 128K Hello World. That's history. > I do not want to repeat it. > > I still haven't had time to look at your changes or read and respond to > all of the words you've written. Mostly for others who haven't been > following the discussion, my reasoning is as follows: > > -Vector and XML and any other built-in for SWF that isn't in JS are not > free. We have to write some amount of code to get them to work. > -Vector provides runtime type checking. Not everybody needs runtime type > checking in production. > -Vector provides length checking. Not everybody needs length checking in > production. > -We've already proven that by having at least two projects get into > production without your implementation of Vector. > -The current compiler output for Vector for folks who don't need runtime > checking just uses Array. > -Your implementation adds 2990 bytes. > > For sure, we need an implementation that does runtime type-checking and > length checking. So, as long as folks can choose to save the 2990 bytes > and just use the current compiler output for Array in production, then we > have given folks the right choices. Bonus if we can let folks choose other > Vector implementations just like they can choose other XML > implementations. My understanding from the words you've written is that > you want everyone to use your Vector implementation and have options on > what code paths that implementation actually takes, but I don't understand > why from a technical perspective. > > In fact, I was reading up on Javascript TypedArrays (because that did load > while on the ferry) and it looks like some folks might want Vector.<int> to > map to the appropriate TypedArray. It actually got me wondering if folks > should be able to dictate how any particular instance of a Vector > "optimizes". > > In sum, the download size still matters. I see it quite frequently. > Technically, why shouldn't folks have a choice of implementations? > > -Alex > > On 5/27/19, 2:46 AM, "Greg Dove" <[email protected]> wrote: > > Hi Alex, sorry it can take a while for me to reply at the moment... > some > comments inline below... > > On Sun, May 26, 2019 at 11:10 AM Alex Harui <[email protected]> > wrote: > > > Hi Greg, > > > > Thanks for working through all of this. Better Vector handling is > > definitely a good thing for Royale. > > > > I also believe so. In terms of my motivation for doing this work... I > actually have no imminent need for Vector, but I wanted to do something > concrete which I think is essential for 1.0. > I do have my own libraries and past client work from that use Vector, > so I > see benefit in knowing that it will be easy to port to Royale and work > without any issues if I need to do that at any point (hopefully I > will). I > also got to see how Vector was treated differently/specially when > working > on AMF, and realized that we had no way to support it there correctly > because it is 'special' also in amf, so that was another motivation > (again, > not for anything I actually need at the moment for myself or anyone > else, > but because it is something else that is lacking for 1.0). > > However, IMO, PAYG is more important and 3KB can be a full second or > more > > on busy/slow/poor networks. As such, folks need to have choices. > So as > > long as folks can choose Vector implementations we should be good. > > > > A couple of things here. Firstly, I really did not think I would > need to > be this specific... but iirc it was actually 2990 bytes. > My first reaction to your scenario above would be: that network > connection > speed is really *unusable* for anything on today's internet... and > that is > a problem that should be addressed first, otherwise it does not matter > which development tech you plan to use, it will be a common problem, > royale, react... whatever. > I can't recall something from my last 10 years where 3KB would be > considered a driving force for an intervention that would (presumably) > only > save a portion of that (and introduce future potential maintainability > risks). 3KB was less than a second on dialup over 20 years ago. Things > have > changed dramatically in the last 5 years in particular. We are in a HD > streaming world now, with many countries supporting 4K streaming > connection > speeds. And average speeds continue to grow globally at solid rates > year-on-year. 4G has impressive global coverage, and 5G is on the > horizon. > I did mention this generally my earlier comments about bandwidth growth > outpacing growth in the size of apps. With your example are you > hypothesizing or do you have a real recent example in mind where this > type > of thing was happening? If I was asked to classify the likelihood of > the > scenario you described I would describe it as a few standard deviations > away from the center of the bell curve based on my own experience. > > However I absolutely do agree with you that choice is important, I just > believe that performance most often will be more of a reason for the > decision to choose alternates (and it may mean adding 'size', not > reducing > it). > And I think the choice should be explicit/obvious rather than having > something that is a lesser implementation of what it is actually > supposed > to be. By this, I mean more application framework alternatives, > instead of > supporting variations that represent non-conforming language classes. > If > that approach is used, I think it will result in clearer, better > quality, > more maintainable code. This is also a general approachI have observed > elsewhere. > > Choosing Array is always an option in javascript and provides a zero > byte-weight option. I also plan to introduce some options for the > numeric > types that represent best performance across both targets... but not as > 'Vector' numeric types. The aim here would be to get faster than > 'Vector as > Array' in javascript and it will be just a convenience approach to > avoid > writing your own COMPILE::JS blocks with the native TypedArrays. > > In terms of tweaking this Vector implementation's performance as > further > options, I already explained I am happy to work on that based on actual > feedback for need. But I still think it requires caution and > consideration > in terms of potential risks for people releasing libraries that could > expose non-conforming instances of Vectors (something that can never > happen > in swf). > There are perhaps some possibilities for enhancing [ArrayElementType] > with > a compiletime=true argument to get something more like what Harbs is > after, > but that would only work for class members, not local vars. Perhaps > there > are other simple ways to add 'compiletime' safety without going to full > blown generics support yet. > > > > Flex failed in some major vendors' customer-facing apps because of > > download times. I have spent the past years trying to make sure > Royale > > does not repeat those mistakes. > > > > > I do want you to understand that I'm on the same team. And like you, I > don't want to repeat old mistakes too. But I also would like to see us > avoid possible new ones. > In the last 5 years or so, I have never really had a client spend much > time > focusing on the size. Before that I think I was more aware of it. > Anyhow, > it's not that it was never important at all, it's just that it was > relatively unimportant compared to other aspects. And apart from > remembering the size of flex apps in the past, I've seen the size of > react > apps I worked on recently too. > I actually just looked at one of those. It is 8762KB minified and > compresses to 1293KB gzipped. The app does not compare directly, but > it is > similar to Carlos' app in that it has many complex input rules and > sequences, however in a lot of ways Carlos' app is far more complex > and has > a lot more remote API calls. However the final result from royale with > Carlos's app has a much, much lighter footprint than those numbers for > react. So Alex, I think the work you and others have put into avoiding > unneeded weight in the application framework has paid (and will > continue to > pay) 'dividends' (as a metaphoric expression for anyone unfamiliar with > that). > But I do think of the language layer below the application framework > layer > as 'different' and that it should be treated as if it has existing > specifications that are not free to reshape as we see fit (which it > does, > directly or indirectly). The language is still actionscript, it's not > royalescript or jactionscript or something else. I've also spelt out a > number of the reasons why I have these views earlier. One thing I did > not > mention was that my views also reflect my experience and observations > with > another cross platform language. I have seen some cases, for example, > where > over the course of iterative improvements, the use of native classes > (the > example that springs to mind was for XML parsing) was removed from a > language level library and the whole feature was re-implemented in > local > code because it was more desirable to achieve consistency across > targets > than to have the best performing code on any one target. The IDE > plugin for > that particular sdk has over 120K downloads in the one IDE I use most > often > and it has a number of other IDEs supporting it with their own plugins > etc. > So I have reason to believe it is popular, and I know it is > disciplined at > the language level for a number of these shared target aspects. The > consistency therefore seems to be very important to its user base, > more so > than the prospect of each language level feature 'being the smallest > it can > be'. But beyond the core language it also has lots of scope for > accommodating differences. My exposure to this (and involvment with it > in > the past) has also influenced my thinking. I try to avoid thinking > "that's > them and not us" because that is a poor reason to ignore the learnings > of > others. Much of my own knowledge and skills over the years is the > result of > shared knowledge (royale and yourself included as a boost to that for > which > I am grateful). Anyway, part of the thinking does come from awareness > of > other things elsewhere, but I did pass it through my 'how does it > relate to > royale' filter. > > > I have some comments on finer details, but let's see if we can agree on > > this higher-level issue first. We simply should offer people > choices. > > > > Just repeating: I too am keen to offer choices and also to make it > easy to > choose them. We only have different views over what those choices > should > be. I would prefer them to be safer choices. I believe avoiding the > multiple Vector implementation approach will avoid future pitfalls and > possible developer confusion that could arise from the distribution of > inconsistent or non-conforming language level code. Neither of us can > be > certain if those risks are real. But there is one way to avoid them for > sure (and yet still provide choices). That is essentially the crux of > my > thinking. Do you think that logic is reasonable at the higher-level? > > Beyond that, I did not obviously remove any emulationClass code in the > compiler and would not do so without your agreement, so nothing there > has > changed. > Actually in the branch I think I changed something to pass qualified > name > instead of basename somewhere, because base name would not be correct > in > the general case. For that reason I don't think anybody was using that > feature yet, although I know you added it in response to a request from > Joshua Granick, as a way to address the Array-not-Vector issue. I do > not > think it should be there now that we have something that we can call > our > own, which is why I asked if we could remove it. Anyway, in terms of > that > decision, can we agree to table it for now, merge the branch and maybe > continue this discussion later? I will go ahead and work on the other > 'choices' I have in mind regardless, maybe when you see them you might > change how you think about things (or not, it is the apache way). > > > > Thanks, > > -Alex > > > > On 5/25/19, 2:45 PM, "Greg Dove" <[email protected]> wrote: > > > > Hi Carlos, thanks for your feedback. In terms of PAYG, I just > have a > > sense > > that at the language level, the 'default' should be that it > *works* as > > per > > design. > > If I take the example of Vector... then numeric Vector types > will not > > run > > faster in javascript. Using all the method calls will have a > > substantial > > impact compared to using a normal Array. But code should 'work' > the > > same > > across targets. > > I do have some ideas for application framework classes outside > > 'language'/Vector that would provide target-agnostic fast > regular class > > implementations for numeric typed Arrays, and I hope to work on > that > > soon > > as well, which takes more advantage of the optimized native > options on > > each > > target (Vector in swf, TypedArray in javascript). But to achieve > that > > it > > will likely be 'always fixed length' in this case, I will see if > it > > seems > > worth trying to be able to toggle that, or maybe it can be a > bead or > > opt-in > > support to get that functionality. But that should provide a good > > option > > for developers seeking to get the best performance for numeric > > collections. > > I expect to work on this during June. > > Or developers can of course always choose to implement their own > custom > > performance code in COMPILE::JS / COMPILE::SWF variations, which > is > > always > > an option. > > > > > > Hi Piotr, sorry about that email formatting issue. Thanks for > your > > follow > > up on this. > > Here is a paste of that part, which includes the code. > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=2InnN50ng8lXwYsDKMZXNiEoHCcMDutiw%2BmOAifDqdc%3D&reserved=0 > > > > Also, if you want to see the tests for Vector, you can see them > here: > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fimprovements%2FLanguage%2Fmanualtests%2FUnitTests%2Fsrc%2Fmain%2Froyale%2FflexUnitTests%2Flanguage%2FLanguageTesterTestVector.as&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sp48jNSTgvHikdp9A2d2L%2Bwkq5vcHII%2BBqD%2BiXczSaQ%3D&reserved=0 > > > > > > You should see large parts of that series of tests fail outside > the > > branch, and in some cases there were compiler errors too iirc (or > > maybe I > > am confusing some compiler fixes I did for other things, can't > be sure > > now) > > > > > > > > On Sun, May 26, 2019 at 4:58 AM Carlos Rovira < > [email protected] > > > > > wrote: > > > > > Hi! > > > > > > Read it! :), was long but I think this emails are needed since > it > > brings > > > many thoughts that only the developer knows and otherwise > would end > > never > > > known by the rest of the community. So Great! > > > > > > Greg, first, many thanks for working on this. I think we get > other > > point > > > solved, and I think not only Vector, but many other fixes and > things > > coming > > > in your branch. > > > > > > For my part, as you said, the branch is tested against my real > > project, > > > that I think is a very good way to test against lots of working > > code. So > > > for my is ok to merge, not only cause it does not brake > anything, > > but cause > > > it's a big step forward. > > > > > > Since it brings things we didn't have before like Vector, is > good to > > bring > > > this. Then we can continue iterating to add missed things like > AMF > > support > > > or to evolve to other state or even change internal things if > other > > check > > > and see ways of enhancements. > > > > > > About the Vector implementation. My opinion is that I think as > you > > that > > > Vector is an intrinsic part of AS3, so better to have an > > implementation to > > > complete AS3 in Royale. About having multiple implementations, > I > > think that > > > could be good in the future if things can be done that way, but > > better > > > start from this starting point and see what happens in next > > months-years. > > > IOW, better have a real implementation now that a potentially > one > > that > > > still is not here. We need to see the goal and approach to it > > progressively > > > or we end getting nothing since the goal is a huge one not > easy to > > reach. > > > > > > For me the 3kb is totally normal, and as well a great > achievement of > > your > > > implementation. > > > I must say that my way of thinking in Royale is to be totally > > aligned with > > > concepts like PAYG, but sometimes we need to break rules when > the > > goal > > > demand it, or we can end trying to apply the same principle to > all > > things, > > > when sometimes is not the best. So this is importante, rules > are > > really > > > good, but we need to always put behind a layer of human > thinking > > about what > > > we are trying to accomplish > > > > > > Thanks Greg for reaching another important milestone! Amazing > work! > > :) > > > > > > Carlos > > > > > > PD: Piotr, about gmail cutting the email, I'm using gmail and > get to > > read > > > it completely, maybe could be a problem of gmail in mobile? I'm > > reading on > > > gmail desktop. The only problem I had was reading posted source > > code, but > > > since it was tiny, I could finally read it... > > > > > > > > > > > > > > > > > > El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (< > > > [email protected]>) escribió: > > > > > > > Hi Greg, > > > > > > > > Could you please post the code from this email in the > > paste.apache.org - > > > > right now is unreadable in my Gmail account. > > > > > > > > Thanks, > > > > Piotr > > > > > > > > On Sat, May 25, 2019, 4:51 AM Greg Dove <[email protected] > > > > wrote: > > > > > > > > > OK, At the risk of making what follows even longer... a > warning: > > *this > > > > is a > > > > > long read*. It might veer off topic in one or two places, > but it > > is > > > > mostly > > > > > about why, and how Vector is implemented the way it is in > the > > branch. > > > > > Basically I would like to merge this branch into develop > as soon > > as > > > > > possible, i actually think it is ready as is, but I am > keen to > > get > > > other > > > > > input before I do. > > > > > Read it if you're interested. If you're not interested in > > reading it > > > then > > > > > please try the branch on any 'real' projects that you have > in > > play. > > > > Carlos > > > > > has tested against his, and there are no issues, but it > would be > > good > > > to > > > > > get wider input. > > > > > > > > > > now to the textual onslaught: > > > > > > > > > > > > > > > *Vector* > > > > > > > > > > One of the things I did before I worked on this Vector > > implementation > > > was > > > > > to detach myself from ‘how I use Vector when I code’, to > take a > > step > > > back > > > > > and challenge myself to rethink how I thought about it in > > general. > > > > > > > > > > Vector is *special*. Vector is not *a class* in a typical > sense. > > It is > > > > the > > > > > closest thing that as3 has to generics which, when used at > a > > class > > > > level, I > > > > > like to think of as the ability to generate multiple class > > variations > > > > from > > > > > a single class definition (that is just the way I think of > > them). So, > > > at > > > > > some level Vector could be considered as an infinite set of > > distinct > > > > > classes, based on an infinite set of possible specified > element > > types > > > > > (whatever you see between the angle brackets in code). It > is not > > > actually > > > > > implemented natively in AVM this way iiuc, but that is the > > outward > > > > > appearance, and that is also the behaviour it has when > using type > > > > checking > > > > > in as3. > > > > > > > > > > Aside from the runtime typesafe behaviour, Vector’s strong > > typing means > > > > > there is additional compile time support and, related, the > > possibility > > > of > > > > > extra IDE support, both of which help the developer. > > > > > > > > > > Vector ‘types’ are also final ‘classes’ enforced by the > > compiler, so > > > > cannot > > > > > be extended. > > > > > > > > > > Additionally, on looking closer, there are some other > quirky > > rules for > > > > > runtime typing behaviour. These are related to the > > implementation in > > > AVM. > > > > > The 3 Vector types for Vector.<int>, Vector.<uint>, and > > Vector.<Number> > > > > are > > > > > individual base types, and then there is a 4th base type, > > Vector.<*> > > > > which > > > > > serves as the ‘base class’ of all other Vector > ‘subclasses’. The > > 3 > > > > numeric > > > > > types are faster than Array, and I expect this was the > reason > > for the > > > > > separation, because these are used in a lot of other flash > apis, > > > > > particularly for swapping with byte level data and things > like > > > BitmapData > > > > > etc. The others are more simply for the strong typing > aspects, > > because > > > > > (perhaps less so with Boolean and String at a guess) they > are > > somewhat > > > > > slower than Array in AVM, because of the overhead of > runtime > > > typechecking > > > > > and coercions etc. So the main selling points for choosing > a > > Vector in > > > > > flash were a) compile time and runtime type safety and b) > faster > > > > > performance for the 3 numeric Vector types. > > > > > > > > > > One implication of these ‘rules’ means that to check if > > *something* is > > > a > > > > > Vector of any type in swf, I need to do (mything is > Vector.<int> > > || > > > > myThing > > > > > is Vector.<uint> || myThing is Vector.<Number> || myThing > is > > > Vector.<*>) > > > > or > > > > > use reflection (which is slower). > > > > > > > > > > The above implies that, for language conformance > (considered as > > > > conformance > > > > > with as3 documentation/spec and the behaviour of the > reference > > > > > implementation that we have for any ‘unknowns’) in an > emulation, > > a > > > > regular > > > > > single as3 class implementation would not create a result > that is > > > > > consistent with the spec in terms of its representation of > > typing, and > > > > its > > > > > behaviour when using type checking. > > > > > > > > > > I tried to take all of these things into consideration. > > > > > > > > > > > > > > > > > > > > *How is it implemented in the branch?* > > > > > > > > > > Vector is implemented using the lightweight ‘synthType’ > approach > > I > > > added > > > > > previously to support for int and uint types as ‘classes’. > This > > > provides > > > > a > > > > > light integration for ‘is’ and ‘as’ checks, but in > javascript > > itself a > > > > > Vector instance is simply a tagged native javascript Array > > instance > > > (i.e. > > > > > an Array with something that identifies it as being ‘not a > > regular > > > > Array’). > > > > > The Array methods are enhanced at the instance level to > support > > the > > > type > > > > > coercions that take place in an actionscript Vector. Using > Array > > makes > > > > > sense because Vector instances are essentially typed > Arrays. But > > it is > > > > not > > > > > possible to extend Array in javascript and have things work > > properly > > > (it > > > > is > > > > > possible to use a different approach with es6 Proxy, but > that is > > not > > > > > available in IE11). > > > > > > > > > > This implementation also means that a ‘Vector’ instance > should > > have > > > > > functionality that works mostly as expected if it is passed > > directly to > > > > a 3 > > > > > rd party native javascript library that is expecting an > Array > > instance. > > > > It > > > > > will not support errors when changing the length if the > Vector > > instance > > > > is > > > > > ‘fixed’ length, for example but otherwise it should > function > > much the > > > > same > > > > > as a regular Array in the 3rd party code. > > > > > > > > > > The ‘synthType’ approach can be used because Vector types > are > > final, so > > > > it > > > > > does not need to conform to a regular Royale class > definition > > that can > > > be > > > > > extended and can be much ‘lighter’. As with int and uint > > ‘classes’, no > > > > > Vector constructor exists until the first one is requested. > > There is > > > one > > > > > internal private class in Language that provides most of > the > > > > functionality > > > > > for Vector, and element coercion functions are generated > > specifically > > > for > > > > > each Vector ‘subtype’. Overall, it behaves more like a > subclass > > > ‘factory’ > > > > > with each individual type’s constructor being created on > demand > > and > > > > cached > > > > > for future use. > > > > > > > > > > Reflection and serialization support have not been added > yet, > > but I > > > > > certainly had these in mind also with this approach. I just > > wanted to > > > > reach > > > > > a sensible intermediate point for now, and then add those > in > > later. > > > > > > > > > > In summary, the Vector implementation in the branch > provides the > > > > following: > > > > > > > > > > -distinct types (conforming in terms of type checking) for > each > > Vector > > > > > subtype > > > > > > > > > > -lightweight integration with Language ‘is’ and ‘as’ > support > > > > > > > > > > -each Vector subtype has a unique constructor generated the > > first time > > > it > > > > > is requested, the constructor does not exist prior to that. > > > > > > > > > > -expected to be compatible with 3rd party native > javascript that > > > expects > > > > a > > > > > regular javascript Array > > > > > > > > > > -serialization (amf) and reflection are not yet supported > but > > were > > > > > considered, and that is planned as next steps. > > > > > > > > > > As at the time of writing, the current implementation is > > supported by > > > 300 > > > > > Vector-specific assertions that run side-by-side between > > javascript and > > > > swf > > > > > in the manualtest UnitTests project. Apart from the > differences > > created > > > > by > > > > > explicitly switching off some type safety checks with > > > > > @suppressvectorindexchecking, there is only one verifiable > > difference > > > in > > > > > these tests between swf and javsacript. Probably there are > things > > > outside > > > > > the test coverage that might need addressing still, but I > think > > it’s a > > > > > pretty good start. > > > > > > > > > > These tests should be easily ported to framework level > unit tests > > > > > (RoyaleUnit) as the same approach has been used to add > FlexUnit > > tests > > > in > > > > > the past. Testing/Development is primarily in Chrome on > windows, > > but > > > the > > > > > same tests were subsequently verified on IE11, Edge, Opera > and > > Firefox > > > on > > > > > windows. > > > > > > > > > > *Implementation Info* > > > > > > > > > > *More quirks* > > > > > > > > > > A ‘fixed == true’ Vector cannot have its length changed. > This > > means > > > that > > > > > changes via the length setter and the mutation methods > (push, > > pop, > > > shift, > > > > > unshift etc) all throw errors if used when a Vector is > ‘fixed == > > true’. > > > > > But… splice method also can change length. And in AVM this > works > > even > > > > with > > > > > a fixed length Vector, which might possibly be a bug but > is one > > that is > > > > > matched in the implementation to conform with flash. > > > > > > > > > > *Size impact.* > > > > > > > > > > Alex was concerned with size impact for HelloWorld because > the > > beads > > > were > > > > > using a Vector.<IBead> type in javascript in one of the > > application > > > > > framework base classes. But the requirement was for that to > > simply to > > > be > > > > an > > > > > Array in javascript, the compiler was only achieving that > by > > default > > > > > because there was no real Vector implementation. So I did a > > couple of > > > > > things here. Firstly I changed the application framework > code to > > > reflect > > > > > the different requirement for javascript. Secondly, I > added some > > doc > > > > > comment directives to suppress exporting on public > members. Then > > I > > > added > > > > > this to the Language methods that are for > compiler-generated > > Vector > > > (and > > > > > int and uint) support so that they are eligible for dead > code > > > elimination > > > > > if not used. This effectively means that it is fully PAYG > – it > > is only > > > > > there if you need it, but if you need it there is also no > effort > > to add > > > > it > > > > > in as an optional dependency. If, because of this, there > is a > > potential > > > > for > > > > > issues with modules or something I have not thought of, > that > > will be > > > > > another thing to solve, but if so, I will find a way to > address > > it. > > > > > > > > > > If the main concern with ‘size’ is data transfer, then > looking > > at the > > > > > minified output size in HelloWorld is not really > meaningful (or > > perhaps > > > > it > > > > > is better to say that it is only as meaningful as looking > at the > > size > > > of > > > > an > > > > > uncompressed swf compared to normal deployment of a > compressed > > swf). In > > > > any > > > > > real deployment the javascript should be served as > gzipped. So I > > > compared > > > > > gzipped (‘normal’ compression) versions of HelloWorld.js > between > > those > > > > with > > > > > the unused Language support methods (for int/uint and > Vector) > > and their > > > > > dependencies vs. builds without. The support for all that > > functionality > > > > > comes in at under 3 Kb difference in the gzipped output. I > > personally > > > > don’t > > > > > think that would register as important in most cases. > However, > > it is > > > > pretty > > > > > close to zero impact now if it is not used. In fact the > > HelloWorld > > > > > application is now about 55 bytes smaller than it was > before, so > > I > > > > consider > > > > > it ‘carbon-netural’. And these are at the gzipped levels > (it is > > also > > > > > slightly smaller when not gzipped, although it can > sometimes be > > the > > > case > > > > > that the larger of 2 files compresses better than a > smaller one, > > > > depending > > > > > on the content). > > > > > > > > > > As a general comment about size… in my experience over the > last > > 10 > > > years > > > > or > > > > > so, mostly in relation to Flex apps, size was most often > not > > among the > > > > > highest priority issues. Sure, start-up time often was. > But that > > is not > > > > > size per se. Often ‘size’ issues were first and foremost > ‘asset > > size’ > > > > > issues (embedded or separate). While I know overall that it > > remains > > > > > important, I personally think the growth in bandwidth and > device > > memory > > > > in > > > > > general has outpaced the growth in the size of web apps > even as > > the > > > world > > > > > has turned to mobile. In other words, I think we probably > passed > > a > > > hurdle > > > > > point in the mobile side of things. Admittedly that is just > > > ‘perception’ > > > > > and maybe there is data that shows I am quite wrong or your > > experience > > > on > > > > > specific client projects could be quite different. The > point of > > me > > > > > explaining that was, however, to illustrate why I think > ‘size’ > > sits > > > > where I > > > > > think it does in general in terms of importance: I > consider it > > to be > > > > behind > > > > > stability/reliability first which is followed by > performance in > > > > performance > > > > > critical code. Overriding that general flow (which again, > is > > just my > > > > > opinion), are whatever my client’s specific requirements > are for > > any > > > > > particular project. In other words I am not sure how much > of > > > HelloWorld’s > > > > > size is going to be an important deciding factor for > someone to > > choose > > > to > > > > > use Royale. I think the ‘I got it to work!’ is the real > kicker > > here. > > > This > > > > > paragraph was not to cause any conflict, and I already > addressed > > the > > > > ‘size’ > > > > > impact in the branch, so I’m not saying it wasn’t > necessary to > > do that > > > > > (although I do suspect the same attention was not given to > all > > other > > > > things > > > > > in the past that affected HelloWorld). It’s more to promote > > discussion > > > > and > > > > > thought in general. Trying to be all one aspect (small > size) can > > > > compromise > > > > > other aspects (reliability or stability or compatibility, > for > > example). > > > > And > > > > > trying to accommodate all aspects (reliability, small size, > > exceptional > > > > > performance) somehow very likely increases complexity > because > > there is > > > a > > > > > need to accommodate the explicit decisions for trade-offs > between > > > > competing > > > > > aspects. It would be good to have a guide of priorities > based on > > the > > > > needs > > > > > of the user base (while I might have a strong opinion > about what > > I > > > think > > > > is > > > > > important, I don’t assume that my views necessarily > represent > > wider > > > user > > > > > needs, because I have not done research to support that – > and > > it’s not > > > > > really a twitter poll kind of thing!). Anyhow I got off > track > > there a > > > > bit… > > > > > back to Vector… > > > > > > > > > > > > > > > > > > > > *Performance.* > > > > > > > > > > No-one should expect a non-native Vector implementation to > > perform > > > faster > > > > > than native Array in javascript. Its main benefit is type > > safety, and > > > > that > > > > > is the reason it should be selected for use over Array. > (In swf, > > native > > > > > numeric Vector types *are* selected for performance, but > the > > other > > > Vector > > > > > types are also at least slightly slower than Array, so > selecting > > them > > > is > > > > > based on the need for type safety) > > > > > > > > > > There are, however some ways to get 100% Array performance > with > > this > > > > > implementation, and in a loop, for example it would be > similar to > > > > avoiding > > > > > method calls (like push/pop) and only using index > assignments > > that is > > > > > typical of performance optimization in swf. > > > > > > > > > > So these two methods provide almost Identical performance > in js: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *private function testArrayInt2(iterations:uint):Number{ > var > > > > start:Date > > > > > = new Date(); var inst:Array = new Array(iterations); > > for > > > > (var > > > > > i:uint=0;i<iterations; i++) { inst[i] = i; } > > return new > > > > > Date().valueOf() - start.valueOf(); } /** * * > > > > > @royalesuppressvectorindexcheck true */ private function > > > > > testVectorInt2(iterations:uint):Number{ var start:Date > = new > > > Date(); > > > > > var inst:Vector.<uint> = new Vector.<uint>(iterations); > > for > > > > > (var i:uint=0;i<iterations; i++) { inst[i] = i; > } > > > return > > > > > new Date().valueOf() - start.valueOf(); }* > > > > > > > > > > The doc comment on the 2nd method prevented the compiler > from > > > generating > > > > an > > > > > index check wrapper around the ‘i’ in inst[i] > > > > > > > > > > The above 2 methods take around 5-7 ms for 500,000 > iterations on > > my > > > > machine > > > > > (chrome/windows). This is quite a bit faster than the same > > methods in > > > the > > > > > swf (non-debug) build on my machine. The Vector > constructor is > > also > > > doing > > > > > extra work in this case by setting all the 500,000 slots to > > numeric 0. > > > > But > > > > > on modern browsers it is using a fast native Array.fill > method > > to do > > > > that, > > > > > so it’s probably more noticeable on IE11 which uses a for > loop to > > > > > pre-populate the contents with numeric 0 values. > > > > > > > > > > For reference, the generated code for the second method > above, > > looks > > > like > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > */** * * @royalesuppressvectorindexcheck true * > @private * > > @param > > > > > {number} iterations * @return {number} */ > > > > > > > > > > > > > > > > > > > > flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2 > > > > > = function(iterations) { var /** @type {Date} */ start = > new > > Date(); > > > > > var /** @type {Array.<number>} */ inst = new > > > > > > > (org.apache.royale.utils.Language.synthVector('uint'))(iterations); > > > for > > > > > (var /** @type {number} */ i = 0; i < iterations; i++) { > > inst[i] = > > > i; > > > > > } return new Date().valueOf() - start.valueOf(); };* > > > > > > > > > > The methods with type checking in them, like push, unshift > etc > > will be > > > > > quite a lot slower though. This should not be a surprise. > In > > swf, when > > > > you > > > > > look at something like Vector.<IBead> it can be up to 30% > slower > > than > > > > Array > > > > > for methods like push, iirc at native level. In javascript > it > > will be a > > > > lot > > > > > more. But in both cases it has type safety. And for small > > collection > > > > sizes > > > > > in non-performance sensitive code it is probably not going > to > > make a > > > > > meaningul difference. > > > > > > > > > > Known limitations > > > > > > > > > > 1. myVectorInstance[‘constructor’] can be different > > between js > > > and > > > > > swf > > > > > > > > > > 2. There is some reliance on not obscuring the type > from > > the > > > > compiler > > > > > for things to work correctly. Example: > > > > > > > > > > var myObscuredType:* = new Vector.<String>(20,true) // > creates a > > fixed > > > > > Vector of length 20 > > > > > > > > > > myObscuredType.length = 21; //should throw an error, but > does > > not in > > > > > javascript. > > > > > > > > > > This will work as long as the compiler knows that the type > with > > the > > > > length > > > > > setter is some type of Vector, otherwise not. > > > > > > > > > > > > > > > > > > > > *Performance tuning* > > > > > > > > > > *@royalesuppressvectorindexcheck* > > > > > > > > > > The above doc comment directive avoids checking for > > out-of-valid-range > > > > > index values on assignments. This is extremely desirable > inside > > loops > > > > which > > > > > are usually constrained to the valid range in any case. > There is > > a top > > > > > level compiler configuration setting for this, but local > > settings win > > > > > (turning off or on generally with true/false, or > suppressing > > > specifically > > > > > for individual local variable names) > > > > > > > > > > > > > > > > > > > > Other options. > > > > > > > > > > The above one was obvious to me as an important tuning > option. I > > > started > > > > > with adding another but pulled it out in favor of adding > them > > based on > > > > > actual need. > > > > > > > > > > There are many options: > > > > > > > > > > Instance based: reducing type checking with a compiler-only > > generated > > > > > additional constructor parameter, triggered by some doc > comment > > > > directive. > > > > > This could be in the form of adding in compiler generated > > alternatve > > > > calls > > > > > to things like ‘unsafePush’ and ‘unsafePop’ on instances, > or > > perhaps > > > > > literal calls to Array.prototype.push.call(inst, pushItem), > > triggered > > > by > > > > > some doc comment directive > > > > > > > > > > Global changes:Adding some compiler define value that > (along > > with: > > > > > ||goog.DEBUG) suppresses many runtime checks in the release > > Vector > > > > > implementation. This would allow a blanket approach to > dialing > > runtime > > > > > safety down (or keeping them) in the release build. It > would > > apply > > > across > > > > > all libraries and local project code. > > > > > > > > > > Some combinations of the above that allow sweeping > optimizations > > with > > > > local > > > > > exceptions. > > > > > > > > > > Basically, this branch currently represents what I have > reason to > > > believe > > > > > is a high conformance Vector implementation which should > be the > > default > > > > as > > > > > it is an as3 core type. I think there are many options to > scale > > things > > > > > back, but rather than assume what they should be, I’d > prefer to > > hear > > > from > > > > > users and address *real* needs, so that we only end up with > > > configuration > > > > > options that matter. > > > > > > > > > > > > > > > > > > > > *Advantages of a single Vector implementation – the case > for > > avoiding a > > > > > ‘vector emulation class’* > > > > > > > > > > ‘Language emulation’ is a foundational layer that is not > in the > > same > > > > > category as ‘application framework’ where we can define > things > > how we > > > > want. > > > > > Because the royale sdk includes both aspects inside > ‘framework’ > > (and > > > that > > > > > was obviously not the case for flex sdk in the past) it > may be > > easy to > > > > > overlook that difference. > > > > > > > > > > Vector typing is a core part of AS3 language. Therefore it > should > > > conform > > > > > and be reliable. Having multiple implementations for a core > > language > > > > > feature seems wrong and could easily lead to libraries of > code > > that are > > > > > incompatible. Additionally, as pointed out earlier, Vector > is > > more > > > like a > > > > > subclass factory (‘runtime’ generics) than a single class, > so > > won’t be > > > > well > > > > > represented by a regular class implementation. > > > > > > > > > > Alex, I know you added support for a Vector emulation class > > approach to > > > > > meet the needs of someone asking for improved Vector > support, in > > part > > > > > because we did not have someone who had volunteered to > write our > > own. I > > > > did > > > > > that last part now. I am also suggesting that the > emulation class > > > > approach > > > > > is not a good long term solution because of the above > reasons. > > And the > > > > full > > > > > set of functionality is less than 3Kb in the gzipped > output, so > > I’d > > > > suggest > > > > > that as long as I can add needs-based performance tuning > options > > for > > > > those > > > > > who want them, the benefits of having a single conforming > > > implementation > > > > > which is performance scalable are better than the risks > > associated with > > > > > adding partially non-conforming ones. Therefore I’d like > to ask > > if we > > > can > > > > > remove that functionality now that we have our own > 'Vector' (I > > can do > > > the > > > > > work if you prefer as I know your focus is understandably > on > > other > > > > things). > > > > > > > > > > *Future:* > > > > > > > > > > It will be easily possibly to alter the current > implementation > > to use > > > es6 > > > > > proxy which would likely provide the most reliable way to > get > > full > > > Vector > > > > > conformance indistinguishable from flash. Es6 proxy is > > transparent for > > > > > Array: > > > > > > > > > > var p = new Proxy(new Array(), {}); > > > > > > > > > > Array.isArray(p) // true > > > > > > > > > > This should allow trapping things like the length setter > before > > it gets > > > > to > > > > > the underlying Array target, and doing checking for fixed > == > > true etc. > > > > The > > > > > same is true for numeric index-based assignment of values > etc. > > > > > > > > > > es6 Proxy is kinda cool. At the moment IE11 is the only > > meaningful > > > target > > > > > that does not support this. > > > > > > > > > > I am only mentioning this here because I did think about > this, > > and I > > > > > believe that the current implementation could be upgraded > quite > > easily > > > to > > > > > use this approach if it makes sense (when IE11 is a distant > > memory – > > > > > perhaps sometime next year!). > > > > > > > > > > > > > > > > > > > > Phew, you made it! Well done. > > > > > > > > > > Feel free to share your thoughts or ask any questions you > might > > have. > > > If > > > > > you have neither of those at this time, please still try > to find > > time > > > to > > > > > test any large projects you have in the branch, and provide > > feedback or > > > > > share any concerns you might have after doing that. > > > > > thanks, > > > > > Greg > > > > > > > > > > > > > > > On Thu, May 23, 2019 at 7:55 PM Greg Dove < > [email protected]> > > wrote: > > > > > > > > > > > Re XMLTest manualtest... > > > > > > > > > > > > Yep those were the ones I ported, Harbs. I think I got > them > > all but > > > may > > > > > > have missed some. I added a bunch more as well. Hopefully > > these can > > > be > > > > > > easily migrated to what Josh has been working on. > > > > > > > > > > > > > > > > > > On Thu, 23 May 2019, 19:43 Harbs, <[email protected] > > > > wrote: > > > > > > > > > > > >> As far as XML unit tests go, the starting point should > be > > XMLTest in > > > > > >> manual tests. (Almost) every time I ran into an issue, I > > added it to > > > > > that > > > > > >> project. > > > > > >> > > > > > >> I think I might have been lax on the last few issues I > fixed, > > so we > > > > > >> should probably go through the later XML commits and > make > > sure we > > > have > > > > > >> tests for that. > > > > > >> > > > > > >> As far as Node goes, I think we probably need > conditional Node > > > > > >> compilation to handle Node-specific (and browser > specific) > > code in a > > > > > PAYG > > > > > >> way. > > > > > >> > > > > > >> To technically handle the parsing, something like > > > > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0 > > < > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0 > > > > > > > is > > > > > a > > > > > >> good starting point and something like this > > > > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0 > > < > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0 > > > > > > > > >> might be useful to either use or modify. > > > > > >> > > > > > >> Harbs > > > > > >> > > > > > >> > On May 23, 2019, at 10:18 AM, Greg Dove < > > [email protected]> > > > > wrote: > > > > > >> > > > > > > >> > All, I started porting some adhoc XML tests to > UnitTests and > > > > > eventually > > > > > >> > ended up spending quite a bit of time on addressing > issues > > that > > > > arose > > > > > >> for > > > > > >> > XML before getting back to Vector stuff. > > > > > >> > I think XML probably needs many more unit tests > before we > > get to > > > 1.0 > > > > > >> > because it has an extensive api. I have not used > royale > > with Node > > > > yet, > > > > > >> but > > > > > >> > XML also needs some thought about how to get it > working on > > Node, I > > > > > >> assume. > > > > > >> > Because XML uses the browser's parser and Node does > not > > have one > > > by > > > > > >> > default, then using the same code will need something > to > > take the > > > > > place > > > > > >> of > > > > > >> > the browser's native parser for Node. There is a lib > in npm > > that > > > > might > > > > > >> be > > > > > >> > useful for that, but I don't know how that might work > with > > licence > > > > > etc. > > > > > >> > Anyhow, that is just an observation, I will focus on > Vector > > in > > > this > > > > > >> > thread... I will post here late tomorrow local time > with > > more > > > info, > > > > > and > > > > > >> > discussion points. I am keen to see this merged in, > but > > also keen > > > to > > > > > get > > > > > >> > buy-in first. > > > > > >> > > > > > > >> > > > > > > >> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira < > > > > > [email protected] > > > > > >> > > > > > > >> > wrote: > > > > > >> > > > > > > >> >> Hi Greg, > > > > > >> >> > > > > > >> >> thanks for reporting. I can share here that I was > able to > > test > > > your > > > > > >> branch > > > > > >> >> with our real project and seems all goes well. > > > > > >> >> Could make a intense test, but almost app is working > and > > we found > > > > > just > > > > > >> a > > > > > >> >> few type error coercions that your code was able to > catch > > (so > > > > great! > > > > > >> :)) > > > > > >> >> and must be solved as you merge the branch in. > > > > > >> >> > > > > > >> >> I think that if Vector is something new and others > don't > > have > > > > > >> problems, the > > > > > >> >> branch can be merged and Vector discussions can be > done > > after > > > that, > > > > > >> since > > > > > >> >> it will not break anything since there's no uses of > that > > code > > > since > > > > > is > > > > > >> new, > > > > > >> >> but the other changes can be very beneficial > > > > > >> >> > > > > > >> >> thanks in advance for your progress in all this > stuff :) > > > > > >> >> > > > > > >> >> Carlos > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> El vie., 10 may. 2019 a las 8:44, Greg Dove (< > > > [email protected] > > > > >) > > > > > >> >> escribió: > > > > > >> >> > > > > > >> >>> All, I am really sorry, I keep thinking I will be > able to > > get > > > back > > > > > to > > > > > >> >> this, > > > > > >> >>> but I have some other personal things taking my > spare > > time at > > > the > > > > > >> moment. > > > > > >> >>> These will be done in 2 days, and I then will > update the > > branch > > > > with > > > > > >> some > > > > > >> >>> extra stuff, and continue this discussion with a > focus on > > Vector > > > > > >> >> (bringing > > > > > >> >>> some other relevant discussion on the same topic > from > > Alex as > > > > well) > > > > > at > > > > > >> >> that > > > > > >> >>> time. Sorry to set the wrong expectations earlier. > > > > > >> >>> > > > > > >> >>> > > > > > >> >>> On Tue, May 7, 2019 at 9:01 AM Greg Dove < > > [email protected]> > > > > > wrote: > > > > > >> >>> > > > > > >> >>>> Thanks for the feedback, Josh, Carlos, Alex. > > > > > >> >>>> > > > > > >> >>>> js-complex-implicit-coercions > > > > > >> >>>> js-resolve-uncertain > > > > > >> >>>> js-vector-index-checks > > > > > >> >>>> > > > > > >> >>>> I will make those changes for compiler settings at > some > > point > > > in > > > > > the > > > > > >> >>>> branch later today, invert the config default > values to > > match, > > > > and > > > > > >> swap > > > > > >> >>> all > > > > > >> >>>> 'off' settings in the framework builds (ant and > maven) > > from > > > true > > > > to > > > > > >> >>> false. > > > > > >> >>>> I will also add compiler tests for these settings > > (either today > > > > or > > > > > >> >>>> tomorrow). At the moment I only tested the new > settings > > in the > > > > code > > > > > >> >>> result > > > > > >> >>>> tests in javascript. > > > > > >> >>>> > > > > > >> >>>> In another day or two I will post a call to > discuss the > > Vector > > > > > >> >>>> implementation in more detail. For Vectors, the > > > > > >> js-vector-index-checks > > > > > >> >>> was > > > > > >> >>>> the obvious first candidate for dialing back on the > > impact of > > > > > runtime > > > > > >> >>>> type-checking, but there are a number of options > for > > 'dialing' > > > > > other > > > > > >> >>>> aspects back (or even forward) and choosing the > scope of > > their > > > > > effect > > > > > >> >>>> (local code, local project, or entire codebase code > > including > > > > > >> external > > > > > >> >>>> swcs). I already had stub code for the start of > > something else > > > to > > > > > >> >> remove > > > > > >> >>>> typechecking in mutation methods ('push', 'shift', > 'pop' > > etc) > > > but > > > > > >> >> removed > > > > > >> >>>> it in favour of discussing and reviewing it first. > > Coming up > > > > with > > > > > a > > > > > >> >>>> 'usable' set of options will really benefit from > your > > > collective > > > > > >> input, > > > > > >> >>> so > > > > > >> >>>> I hope you can participate. > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>> On Tue, May 7, 2019 at 4:19 AM Alex Harui > > > > <[email protected] > > > > > > > > > > > >> >>>> wrote: > > > > > >> >>>> > > > > > >> >>>>> +1 to renaming the options to the positive. > > > > > >> >>>>> > > > > > >> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" < > > [email protected]> > > > > > wrote: > > > > > >> >>>>> > > > > > >> >>>>> Hey Greg, > > > > > >> >>>>> > > > > > >> >>>>> I haven't had a chance to look through all of > the > > changes, > > > > but > > > > > >> one > > > > > >> >>>>> thing caught my eye. I find it confusing when a > boolean > > value > > > is > > > > > >> named > > > > > >> >>> with > > > > > >> >>>>> a "negative" phrase. For instance, your new > compiler > > options > > > > have > > > > > >> "no" > > > > > >> >>> in > > > > > >> >>>>> the name: > > > > > >> >>>>> > > > > > >> >>>>> js-no-complex-implicit-coercions > > > > > >> >>>>> js-no-resolve-uncertain > > > > > >> >>>>> js-no-vector-index-checks > > > > > >> >>>>> > > > > > >> >>>>> As they are named, true means no, and so false > means > > yes. > > > > With > > > > > >> >> this > > > > > >> >>>>> kind of naming, I find that I always need to take > a > > moment to > > > > > >> remember > > > > > >> >>>>> which means which. I think it would be better if > true > > means > > > yes > > > > > and > > > > > >> >>> false > > > > > >> >>>>> means no. > > > > > >> >>>>> > > > > > >> >>>>> - Josh > > > > > >> >>>>> > > > > > >> >>>>> On 2019/05/05 08:00:20, Greg Dove < > > [email protected]> > > > > wrote: > > > > > >> >>>>>> So... just an overview of recent work I have > been > > doing. > > > > > >> >> Summery > > > > > >> >>>>> up front, > > > > > >> >>>>>> some extra detail further down... please try > things > > with the > > > > > >> >>> branch > > > > > >> >>>>> if you > > > > > >> >>>>>> have time. > > > > > >> >>>>>> > > > > > >> >>>>>> In the *improvements/Language* branch there are > many > > updates > > > > > >> >>> inside > > > > > >> >>>>>> Language and related updates inside the compiler > to > > address > > > > > >> >> these > > > > > >> >>>>> main > > > > > >> >>>>>> areas: > > > > > >> >>>>>> -Fixes/better support for int and uint types at > runtime > > > > > >> >>>>>> -Fixes for strict equality comparisons when > > instantiated > > > types > > > > > >> >> are > > > > > >> >>>>>> uncertain, or known to be problematic in these > cases > > for > > > > > >> >> specific > > > > > >> >>>>> types > > > > > >> >>>>>> that are known. > > > > > >> >>>>>> -Complex implicit coercions (throws errors if > assigned > > type > > > is > > > > > >> >>>>> incorrect) > > > > > >> >>>>>> -Vectors - test-driven development of a > conforming > > > > > >> >> implementation. > > > > > >> >>>>>> > > > > > >> >>>>>> The new features are supported by almost 350 new > > assertion > > > > tests > > > > > >> >>>>> (in the > > > > > >> >>>>>> UnitTests manualtests project). This was not a > trivial > > amount > > > > of > > > > > >> >>>>> work :) > > > > > >> >>>>>> > > > > > >> >>>>>> I still have a few things to work on in the > branch, > > including > > > > > >> >> some > > > > > >> >>>>> tuning > > > > > >> >>>>>> for the new configuration settings and adding > tests to > > the > > > > > >> >>> compiler > > > > > >> >>>>> for > > > > > >> >>>>>> those, but I would be keen for others to test the > > branch and > > > > try > > > > > >> >>> it > > > > > >> >>>>> with > > > > > >> >>>>>> real projects, and provide feedback. So this is > > > > > >> >>>>> 'improvements/Language' for > > > > > >> >>>>>> both royale-asjs and royale-compiler. > > > > > >> >>>>>> In particular, please take Vector for a spin and > see > > if you > > > can > > > > > >> >>>>> break > > > > > >> >>>>>> anything and let me know! > > > > > >> >>>>>> Note the new configuration settings a bit > further down > > (and > > > see > > > > > >> >>>>> examples > > > > > >> >>>>>> here for how to switch them off globally: > > > > > >> >>>>>> mvn: > > > > > >> >>>>>> > > > > > >> >>>>> > > > > > >> >>> > > > > > >> >> > > > > > >> > > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fimprovements%2FLanguage%2Fframeworks%2Fprojects%2Fpom.xml%23L88&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=vC7Sy%2BfGwJhbS8bR0Eo4wZBTNxsuEGCWXQ6nHceAk18%3D&reserved=0 > > > > > >> >>>>>> ant: > > > > > >> >>>>>> > > > > > >> >>>>> > > > > > >> >>> > > > > > >> >> > > > > > >> > > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fimprovements%2FLanguage%2Fframeworks%2Fjs%2Fprojects%2FBasicJS%2Fsrc%2Fmain%2Fconfig%2Fcompile-js-config.xml%23L106&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=NlTd48QGPtLVuoxX%2Fv4IO0ZZyz3CMgh7Gzllr3D%2BIoA%3D&reserved=0 > > > > > >> >>>>>> ) > > > > > >> >>>>>> > > > > > >> >>>>>> > > > > > >> >>>>>> A couple of examples: > > > > > >> >>>>>> I tried compiling Tour de Jewel with the new > features > > > switched > > > > > >> >> on, > > > > > >> >>>>> it it > > > > > >> >>>>>> immediately highlighted a runtime error where a > 'bead' > > was > > > > being > > > > > >> >>>>> added > > > > > >> >>>>>> which was not actually an IBead. This was > detected in a > > > Vector > > > > > >> >>> push > > > > > >> >>>>>> operation. Although it was not causing problems, > it is > > a good > > > > > >> >>>>> example of > > > > > >> >>>>>> something that would have failed at runtime in > the > > flash > > > > player, > > > > > >> >>>>> making it > > > > > >> >>>>>> much easier to identify and fix. > > > > > >> >>>>>> > > > > > >> >>>>>> I have switched the extra outputs off for all the > > framework > > > > code > > > > > >> >>> in > > > > > >> >>>>> the > > > > > >> >>>>>> branch. But I did try a couple of projects with > them > > on. As > > > an > > > > > >> >>>>> example, > > > > > >> >>>>>> after building XML with them on it throws a > runtime > > error > > > when > > > > > >> >>>>> calling one > > > > > >> >>>>>> of the methods in XML. > > > > > >> >>>>>> The method has the wrong argument type (Element > type > > when it > > > > > >> >>> should > > > > > >> >>>>> -iirc- > > > > > >> >>>>>> be Node). So these can catch errors in your code > that > > are > > > > silent > > > > > >> >>>>> because > > > > > >> >>>>>> there is no strong typechecking at runtime. > > > > > >> >>>>>> The above is the implicit complex coercion in > action. > > it is > > > > like > > > > > >> >>> if > > > > > >> >>>>> you did > > > > > >> >>>>>> in flash player : > > > > > >> >>>>>> var myArray:Array = [new ByteArray()]; > > > > > >> >>>>>> var sprite:Sprite = myArray[0]; //runtime error > here > > > > > >> >>>>>> This does not happen currently in Royale > javascript, > > but is > > > now > > > > > >> >>>>> supported > > > > > >> >>>>>> in the branch (and you can switch it off). This > is an > > > expansion > > > > > >> >> of > > > > > >> >>>>> some of > > > > > >> >>>>>> Josh's great work in the past with implicit > primitive > > > coercions > > > > > >> >>>>> (which > > > > > >> >>>>>> don't throw errors but coerce to the correct > type). > > > > > >> >>>>>> > > > > > >> >>>>>> *New configuration settings* > > > > > >> >>>>>> js-no-complex-implicit-coercions > > > > > >> >>>>>> default: false (i.e. ensures runtime safety when > > assigning an > > > > > >> >>>>> unknown type > > > > > >> >>>>>> to a known type ) > > > > > >> >>>>>> local doc comment directive > > > > > >> >>>>>> switching: @royalesuppresscompleximplicitcoercion > > > > > >> >>>>>> > > > > > >> >>>>>> js-no-resolve-uncertain > > > > > >> >>>>>> default: false (i.e. ensures instances that are > safe in > > > certain > > > > > >> >>>>>> comparisons ) > > > > > >> >>>>>> local doc comment directive switching: > > > > > >> >>>>> @royalesuppressresolveuncertain > > > > > >> >>>>>> > > > > > >> >>>>>> js-no-vector-index-checks > > > > > >> >>>>>> default: false (i.e. vector index checking is on) > > > > > >> >>>>>> local doc comment directive switching: > > > > > >> >>>>> @royalesuppressvectorindexcheck > > > > > >> >>>>>> > > > > > >> >>>>>> *-Fixes problems/provides more general support > for int > > and > > > uint > > > > > >> >>>>> types at > > > > > >> >>>>>> runtime* > > > > > >> >>>>>> Josh's recent assignment implicit coercions made > a big > > > > > >> >> difference > > > > > >> >>>>> for these > > > > > >> >>>>>> (and other primitive types), but runtime support > either > > > caused > > > > > >> >>>>> errors or > > > > > >> >>>>>> bad results. > > > > > >> >>>>>> Things like > > > > > >> >>>>>> var myClass = int; > > > > > >> >>>>>> > > > > > >> >>>>>> var x:* = new myClass(22.5); > > > > > >> >>>>>> trace( x === 22 ) //true > > > > > >> >>>>>> > > > > > >> >>>>>> The above works now in the branch. iirc I think > there > > is more > > > > > >> >> than > > > > > >> >>>>> one > > > > > >> >>>>>> issue with that in develop. > > > > > >> >>>>>> I started with this based on issue #273 which > also now > > is > > > fixed > > > > > >> >> in > > > > > >> >>>>> the > > > > > >> >>>>>> branch. > > > > > >> >>>>>> > > > > > >> >>>>>> int and uint are implemented are not needed like > this > > in most > > > > > >> >>>>> cases, so the > > > > > >> >>>>>> are not real 'classes' but very simple instances > of > > > 'synthetic > > > > > >> >>>>> Types' that > > > > > >> >>>>>> are only 'created' if/when they are requested > for the > > first > > > > > >> >> time. > > > > > >> >>>>> Vectors > > > > > >> >>>>>> (because they are kind of like factory-generated > > classes) use > > > > > >> >> the > > > > > >> >>>>> same > > > > > >> >>>>>> underlying mechanism, but are more complicated > than > > int and > > > > uint > > > > > >> >>> in > > > > > >> >>>>> terms > > > > > >> >>>>>> of their supporting implementation. uint and int > are > > almost > > > > > >> >>> defined > > > > > >> >>>>> in a > > > > > >> >>>>>> single line of code, not so for Vectors. Another > > candidate > > > for > > > > a > > > > > >> >>>>> synthetic > > > > > >> >>>>>> type might be 'Class', but I will see about that. > > > > > >> >>>>>> > > > > > >> >>>>>> *-Fixes for strict equality comparisons in when > > instantiated > > > > > >> >> types > > > > > >> >>>>> are > > > > > >> >>>>>> uncertain, or known to be problematic for types > that > > are > > > > known.* > > > > > >> >>>>>> Certain explicit instantiations of primitive > types are > > > swapped > > > > > >> >> to > > > > > >> >>>>> coercions. > > > > > >> >>>>>> Things like 'new String('test')' are now output > simply > > as > > > > > >> >>>>> String('test'). > > > > > >> >>>>>> Resolution of uncertain instantiations > > > > > >> >>>>>> Where a class is not known, the instantiation of > that > > class > > > is > > > > > >> >>>>> wrapped in a > > > > > >> >>>>>> 'resolveUncertain' method call. This calls the > low > > level > > > native > > > > > >> >>>>> 'valueOf()' > > > > > >> >>>>>> method on the instance, which resolves it to > primitive > > types > > > if > > > > > >> >>>>> possible. > > > > > >> >>>>>> > > > > > >> >>>>>> The above changes provide consistency with AVM > when > > values , > > > > > >> >> even > > > > > >> >>>>> those > > > > > >> >>>>>> with typing obscured, are used in strict equality > > > comparisons. > > > > > >> >>>>> These cases > > > > > >> >>>>>> may not bet mainstream, but that is exactly the > type > > of thing > > > > > >> >> the > > > > > >> >>>>> causes a > > > > > >> >>>>>> lot of headscratching when things don't work. > Note that > > > > > >> >>>>> Array.indexOf also > > > > > >> >>>>>> uses strict equality comparisons, so this is not > just > > fixing > > > > > >> >>>>> results of === > > > > > >> >>>>>> or !== across these edge cases. > > > > > >> >>>>>> > > > > > >> >>>>>> *-Complex implicit coercions* > > > > > >> >>>>>> I expanded on Josh's implicit primitive type > coercions > > to > > > > > >> >> support > > > > > >> >>>>> more > > > > > >> >>>>>> complex coercions > > > > > >> >>>>>> (this is on by default, but explicitly off in the > > framework) > > > > > >> >>>>>> So this works now like flash player: > > > > > >> >>>>>> var myClass:MyClass = someArray[i]; //if the > assigned > > value > > > > from > > > > > >> >>>>>> someArray[i] is not a MyClass type, error is > thrown > > > > > >> >>>>>> This can be switched off at compiler level, or > tuned > > within > > > > > >> >>> methods > > > > > >> >>>>> (on or > > > > > >> >>>>>> off in contrast to compiler level setting) with a > > specific > > > doc > > > > > >> >>>>> comment > > > > > >> >>>>>> directive. (i.e. like royaleignorecoercion) > > > > > >> >>>>>> Output in debug mode shows these implicit > coercions > > prefixed > > > > > >> >> with > > > > > >> >>>>> /* > > > > > >> >>>>>> implicit cast */ so you can easily review the > number of > > > > > >> >> locations > > > > > >> >>>>> this is > > > > > >> >>>>>> affecting by doing 'find in files' and looking > at the > > > locations > > > > > >> >>> and > > > > > >> >>>>> count. > > > > > >> >>>>>> While it will probably be a good thing to switch > off > > in a > > > final > > > > > >> >>>>> release > > > > > >> >>>>>> build, it can help find problems during > development, > > > > > >> >> particularly > > > > > >> >>>>> as more > > > > > >> >>>>>> and more code is not being parallel tested in > the flash > > > player > > > > > >> >>>>> where error > > > > > >> >>>>>> trapping like this is automatic. > > > > > >> >>>>>> I switched this off in framework, but it could > help > > find code > > > > > >> >>>>> errors in the > > > > > >> >>>>>> framework when it is switched on > > > > > >> >>>>>> > > > > > >> >>>>>> > > > > > >> >>>>>> *-Vectors* > > > > > >> >>>>>> Vectors are 'smoke and mirrors' currently in > develop - > > it is > > > > > >> >>>>> basically the > > > > > >> >>>>>> compiler pretending that they are Vectors (they > are > > Arrays). > > > > > >> >> This > > > > > >> >>>>> gives a > > > > > >> >>>>>> small amount of compile time safety, but still > leaves > > large > > > > gaps > > > > > >> >>>>> when > > > > > >> >>>>>> compared with the real thing and many things > that you > > could > > > > > >> >> assume > > > > > >> >>>>> would be > > > > > >> >>>>>> safe will not be. Assuming it worked properly > could be > > even > > > > > >> >>>>> considered a > > > > > >> >>>>>> little 'dangerous'. > > > > > >> >>>>>> > > > > > >> >>>>>> There are 260 new assertion tests for Vectors, > > including some > > > > > >> >> that > > > > > >> >>>>> relate > > > > > >> >>>>>> to a new doc comment directive > > @suppressvectorindexchecking > > > > > >> >> which > > > > > >> >>>>> avoids > > > > > >> >>>>>> (intensive) checking for range errrors (and will > be > > desirable > > > > to > > > > > >> >>>>> switch off > > > > > >> >>>>>> in a lot of cases, such as in length constrained > loops > > etc). > > > > > >> >>>>>> You can see the Vector tests here: > > > > > >> >>>>>> > > > > > >> >>>>> > > > > > >> >>> > > > > > >> >> > > > > > >> > > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fimprovements%2FLanguage%2Fmanualtests%2FUnitTests%2Fsrc%2Fmain%2Froyale%2FflexUnitTests%2Flanguage%2FLanguageTesterTestVector.as%23L65&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=dwgAt0Rz%2Bt575HRIk97kPbtewGN4mSv8FbCQr6Skudg%3D&reserved=0 > > > > > >> >>>>>> > > > > > >> >>>>>> > > > > > >> >>>>>> > > > > > >> >>>>>> *Miscellaneous* > > > > > >> >>>>>> -When addressing some sourcemap related stuff for > > Vectors, I > > > > > >> >> fixed > > > > > >> >>>>> an > > > > > >> >>>>>> unrelated sourcemap issue that was caused by > methods > > which > > > had > > > > > >> >>>>> metadata > > > > > >> >>>>>> attached. The mapping now correctly aligns with > the > > original > > > > > >> >>>>> function > > > > > >> >>>>>> keyword in these cases. > > > > > >> >>>>>> > > > > > >> >>>>> > > > > > >> >>>>> > > > > > >> >>>>> > > > > > >> >>> > > > > > >> >> > > > > > >> >> > > > > > >> >> -- > > > > > >> >> Carlos Rovira > > > > > >> >> > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0 > > > > > >> >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > -- > > > Carlos Rovira > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0 > > > > > > > > > > > >
