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