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