Harbs,
I don't have time to look into it right now, but those last changes break a
couple of royaleunit tests.
The tests could be wrong (but for the most part they do run the same tests
between swf and js).
If you ever want to test these in isolation after you make changes, you can
go into the XML project in console (with all normal env vars set) and just
use:
ant test
On Fri, Nov 29, 2019 at 6:32 AM 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.
>> >>>
>> >>>
>>
>>
