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