' I don’t see that in the Ecma spec.'
yeah, it was fun working on this. (irony) . When things were not clear, I
always used swf behavior as the 'spec'.
On Fri, Nov 29, 2019 at 7:25 AM Harbs <harbs.li...@gmail.com> wrote:
> Yeah. I see it’s supposed to wrap the elements. Weird. I don’t see that in
> the Ecma spec.
>
> I see what I messed up. I’ll revert that bit.
>
> > On Nov 28, 2019, at 8:20 PM, Greg Dove <greg.d...@gmail.com> wrote:
> >
> > You mean this (hopefully the xml angle brackets won't be mangled in your
> > view of this)?
> >
> > var xml:XML = <root/>;
> > xml.appendChild("test1");
> > xml.appendChild("test2");
> > xml.appendChild(<element/>);
> > xml.appendChild("test3");
> > xml.appendChild("test4");
> >
> >
> > trace(xml.toXMLString())
> > output in swf:
> > <root>
> > test1
> > test2
> > <element/>
> > <element>test3</element>
> > <element>test4</element>
> > </root>
> >
> >
> >
> > On Fri, Nov 29, 2019 at 7:12 AM Harbs <harbs.li...@gmail.com> wrote:
> >
> >> 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.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
