I had removed that line to avoid writing “element”. I just changed it to delete the property to get rid of the “TEXT” on instantiation.
> On Nov 28, 2019, at 8:29 PM, Greg Dove <greg.d...@gmail.com> wrote: > > ' I don’t see that in the Ecma spec.' > > yeah, it was fun working on this. (irony) . When things were not clear, I > always used swf behavior as the 'spec'. > > > > On Fri, Nov 29, 2019 at 7:25 AM Harbs <harbs.li...@gmail.com> wrote: > >> Yeah. I see it’s supposed to wrap the elements. Weird. I don’t see that in >> the Ecma spec. >> >> I see what I messed up. I’ll revert that bit. >> >>> On Nov 28, 2019, at 8:20 PM, Greg Dove <greg.d...@gmail.com> wrote: >>> >>> You mean this (hopefully the xml angle brackets won't be mangled in your >>> view of this)? >>> >>> var xml:XML = <root/>; >>> xml.appendChild("test1"); >>> xml.appendChild("test2"); >>> xml.appendChild(<element/>); >>> xml.appendChild("test3"); >>> xml.appendChild("test4"); >>> >>> >>> trace(xml.toXMLString()) >>> output in swf: >>> <root> >>> test1 >>> test2 >>> <element/> >>> <element>test3</element> >>> <element>test4</element> >>> </root> >>> >>> >>> >>> On Fri, Nov 29, 2019 at 7:12 AM Harbs <harbs.li...@gmail.com> wrote: >>> >>>> I can’t imagine where <element>test3</element> comes from when you >> append >>>> “test3”... >>>> >>>> It should be a text node. No? >>>> >>>>> On Nov 28, 2019, at 8:09 PM, Greg Dove <greg.d...@gmail.com> wrote: >>>>> >>>>> OK, I will check it now. >>>>> >>>>> On Fri, Nov 29, 2019 at 7:08 AM Harbs <harbs.li...@gmail.com> wrote: >>>>> >>>>>> I’m getting two test failures on the XML tests. >>>>>> >>>>>> testXMLNormalize is failing, but the test looks wrong to me. Could you >>>>>> take a look? >>>>>> >>>>>>> On Nov 28, 2019, at 7:32 PM, Greg Dove <greg.d...@gmail.com> wrote: >>>>>>> >>>>>>> Oh - just saw this. Thanks. >>>>>>> Please ignore my comments in the other thread :). >>>>>>> >>>>>>> >>>>>>> On Fri, Nov 29, 2019 at 6:12 AM Harbs <harbs.li...@gmail.com> wrote: >>>>>>> >>>>>>>> I finally got the nerve together to update my local environment. >>>>>>>> >>>>>>>> The changes look pretty good. >>>>>>>> >>>>>>>> I made a couple of small changes. >>>>>>>> >>>>>>>> One fixes hasAttribute which somehow broke with your changes. >>>>>>>> >>>>>>>> The second is a small tweak to the memory optimizations. The memory >>>>>>>> footprint seems to be a bit smaller than what it used to be. >>>>>>>> >>>>>>>> Good work. :-) >>>>>>>> >>>>>>>> Harbs >>>>>>>> >>>>>>>>> On Oct 2, 2019, at 11:29 AM, Greg Dove <greg.d...@gmail.com> >> wrote: >>>>>>>>> >>>>>>>>> @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 <greg.d...@gmail.com> >>>> 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 <harbs.li...@gmail.com> >> 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 <greg.d...@gmail.com> >>>> 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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >>