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.
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
