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