The reason I mentioned my desire to have `int[]` and `MyFoo[]` in addition to Vector was that I thought it might be another solution to this problem.
I personally have never used length checking in Vector. Nor was runtime type checking on Vectors important to me. When I was porting a javascript library for use with Royale, array incompatibility with Vector was a pain point. In short, I want the ability to type check my arrays at compile time and have them completely compatible with generic arrays (something I’m missing currently with Vector). I don’t want or need the extra weight. To me, a good solution would be to have full runtime type checking in Vector and be able to use “typed” arrays (not to be confused with TypedArrays) to avoid the runtime weight. I discussed in the past with Josh the concept of implementing “typed arrays” in addition to Vectors. Maybe now would be a good time to make that happen. I do like the concept of optimizing how certain vectors are output (such as TypedArrays), but that might be something that can happen later. FWIW, most JS engines will automatically use a TypedArray under the hood if you use an array where all the elements are integers, so there’s not usually a practical advantage to writing that optimization explicitly. My $0.02, Harbs > On May 27, 2019, at 9:43 PM, Alex Harui <aha...@adobe.com.INVALID> 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" <greg.d...@gmail.com > <mailto:greg.d...@gmail.com>> 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 <aha...@adobe.com.invalid> > 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" <greg.d...@gmail.com> 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 >> >> <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 >> >> <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 <carlosrov...@apache.org >> <mailto:carlosrov...@apache.org> >>> >> 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 (< >>> piotrzarzyck...@gmail.com <mailto:piotrzarzyck...@gmail.com>>) escribió: >>> >>>> Hi Greg, >>>> >>>> Could you please post the code from this email in the >> paste.apache.org <http://paste.apache.org/> - >>>> right now is unreadable in my Gmail account. >>>> >>>> Thanks, >>>> Piotr >>>> >>>> On Sat, May 25, 2019, 4:51 AM Greg Dove <greg.d...@gmail.com >>>> <mailto:greg.d...@gmail.com>> >> 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 <greg.d...@gmail.com >>>>> <mailto:greg.d...@gmail.com>> >> 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, <harbs.li...@gmail.com >>>>>> <mailto:harbs.li...@gmail.com>> >> 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> >> < >> 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> >> < >>> >> 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 < >> greg.d...@gmail.com <mailto:greg.d...@gmail.com>> >>>> 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 < >>>>> carlosrov...@apache.org <mailto:carlosrov...@apache.org> >>>>>>>> >>>>>>>> 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 (< >>> greg.d...@gmail.com <mailto:greg.d...@gmail.com> >>>>> ) >>>>>>>>> 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 < >> greg.d...@gmail.com <mailto:greg.d...@gmail.com>> >>>>> 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 >>>> <aha...@adobe.com.invalid <mailto:aha...@adobe.com.invalid> >>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> +1 to renaming the options to the positive. >>>>>>>>>>>> >>>>>>>>>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" < >> joshtynj...@apache.org <mailto:joshtynj...@apache.org>> >>>>> 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 < >> greg.d...@gmail.com <mailto:greg.d...@gmail.com>> >>>> 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 >> >> <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 >> >> <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 >> >> <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 >> >> <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 >> >> <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>
