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