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://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 <[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%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 > >> > >
