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

Reply via email to