@harbs FYI in addition to some other stuff, I am close to pushing my updates to XML. This should be in the next hour or so.
I kept the QName caching pretty close to how you had it, with only some minor changes. I tried to do some extra memory optimization, and in theory it should provide better results, but to be honest I don't have a good way to measure this in the browser. I tried the Chrome performance.memory extensions but I don't have much confidence in that given how much it varies between reloads without changing anything else. The extra code changes I made were to make the '_nodeKind' strings into String object references, so they only refer to a single reference to a string instead of multiple copies of primitives. That change is isolated to a single commit so can easily be reversed if there is something not good about it... but all my local tests continue to pass. I will get the new tests into RoyaleUnit in the coming days. On Thu, Sep 5, 2019 at 7:39 AM Greg Dove <[email protected]> wrote: > Yeah, I saw that ;) Don't worry, I am aware of it. > > My first goal is to make sure it works like it should, because that comes > first, and then to optimize. I'll check the memory side of things and make > sure it's at least the same as before. If you can point me to some > publicly accessible large test cases that would be really helpful. I will > work through that before I push anything. > > On Thu, Sep 5, 2019 at 7:26 AM Harbs <[email protected]> wrote: > >> Heads up: >> >> I did some (on first blush) odd things in XML related to QNames. QNames >> are pooled and many XML properties are not initialized by default. The >> reason I did this was it avoided many MB of memory waste for complex XML. >> Please don’t mess that up. >> >> Thanks, >> Harbs >> >> > On Sep 4, 2019, at 1:02 PM, Greg Dove <[email protected]> wrote: >> > >> > This is particularly for Harbs and Yishay, as I think you are both (or >> both >> > have been) using XML quite a bit. I have quite a few fixes coming. All >> > with tests that match on swf and js. >> > >> > I am currently working to demonstrate proof of concept to a prospective >> > client for migration of a Flex app. The app makes extensive use of e4x >> and >> > uses a bunch of features that I expect had not received attention >> > previously, because they were originally either not working with the >> > codebase I am porting, or i think some even caused errors in the >> javascript >> > output. >> > >> > So I have spent the last several days almost full time figuring things >> out >> > and working on fixes, between the compiler and emulation classes. >> > All the previous XML tests continue to pass, but I have many more unit >> > tests and fixes lined up for the following: >> > >> > namespace directives >> > default xml namespace >> > use namespace (multiple) >> > >> > a number of fixes for xml filtering, including: >> > -'this' resolves correctly in filters that include external references >> from >> > the fitler expression to the 'this' scope >> > -handles alternate ordering of comparisons between XML 'getters' and >> > literals >> > e.g. something.(name() = "cat") or something.("cat" = name()) (these >> are >> > the same) >> > -it (will) now handle XML e4x references in nested function calls inside >> > the filter, e.g. things like: >> > e.g. >> > var people:XML = <people> >> > <person> >> > <name>Bob</name> >> > <age>32</age> >> > </person> >> > <person> >> > <name>Joe</name> >> > <age>46</age> >> > </person> >> > </people>; >> > var findJoeByAge:Function = function (i:int):Boolean { >> > return i > 40; >> > }; >> > people.person.(findJoeByAge(parseInt(age))).name >> > >> > >> > I have lots more granular tests in QName, Namespace, and XML with >> tuning to >> > improve reliability. >> > toXMLString XML node output also matches flash more correctly in what I >> > have coming. >> > >> > One thing that I am trying to figure out, which I would appreciate >> input on >> > if someone has an answer: >> > For the example: >> > >> > var feed:XML = new XML( >> > '<feed xmlns:atom="http://www.w3.org/2005/Atom"; >> > xmlns:m="nothing">\n' + >> > ' <link rel="no_namespace" >> > href="blah/12321/domain/"/>\n' + >> > '</feed>\n'); >> > var atomSpace:Namespace = new Namespace('http://www.w3.org/2005/Atom'); >> > >> > Can anyone explain why this (in SWF, as a reference implementation): >> > trace(feed.atomSpace::link.length()) >> > trace(feed.atomSpace::link.toXMLString()) >> > //output: >> > 0 >> > {empty string} >> > is different to: >> > trace(feed.child(new QName(atomSpace,'link')).length()) >> > trace(feed.child(new QName(atomSpace,'link')).toXMLString()) >> > //output: >> > 1 >> > <link rel="no_namespace" href="blah/12321/domain/" xmlns:atom=" >> > http://www.w3.org/2005/Atom"; xmlns:m="nothing"/> >> > >> > I had assumed the above cases would be the same, but the second one is >> > behaving as if it has the default namespace included with the specified >> > namespace in the QName matching (it does correctly match the namespace >> > specifically as well -with e.g. <atom:link nodes where the prefix atom >> is >> > bound to the uri, but also seems to include link nodes with the default >> > namespace, whether or not it is declared). I can accommodate this >> > difference to make them behave the same, I just would like to understand >> > the basis for the actual rules if anyone knows.... >> > >> > I should be in a position to push the updates this coming weekend I >> think. >> >>
