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://github.com/isaacs/sax-js <https://github.com/isaacs/sax-js> is a good starting point and something like this https://github.com/nfarina/xmldoc <https://github.com/nfarina/xmldoc> might be useful to either use or modify. Harbs > On May 23, 2019, at 10:18 AM, Greg Dove <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> > 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>) >> 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> 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> >>>> wrote: >>>> >>>>> +1 to renaming the options to the positive. >>>>> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <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> 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%7Ce44a5f9a81b141a8414908d6d2352ee6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636927523209585267&sdata=ZDbgmmsdx4m6D9Bnel839Lxi4sVh8kwNLKK4HS%2F%2ByW8%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%7Ce44a5f9a81b141a8414908d6d2352ee6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636927523209585267&sdata=kvr13pxvGktxjV7QLu0mWdKJZfpr3zk6AHCj%2FM74Ym4%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%7Ce44a5f9a81b141a8414908d6d2352ee6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636927523209585267&sdata=NNJ6cfAOqGHPya5oyADDhwBwkWpNkng%2Fk0%2BvrzZm7aM%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 >> http://about.me/carlosrovira >>
