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