Hi Piotr, I will check that in the morning local time... in about 8 hours. On Sun, 6 Oct 2019, 21:54 Piotr Zarzycki, <[email protected]> wrote:
> Hi Greg, > > I run into merge conflict during merge release branch to develop into file > which you have changed lately. Could you please verify on develop if I > didn't remove anything, if I resolve conflict correctly. [1] > > [1] > > https://github.com/apache/royale-compiler/blob/develop/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java > > Thanks, > Piotr > > śr., 2 paź 2019 o 11:06 Harbs <[email protected]> napisał(a): > > > OK. > > > > I’ll test memory with and without your changes and let you know the > > differences. :-) > > > > Harbs > > > > > On Oct 2, 2019, at 11:29 AM, Greg Dove <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. > > >>> > > >>> > > > > > > -- > > Piotr Zarzycki > > Patreon: *https://www.patreon.com/piotrzarzycki > <https://www.patreon.com/piotrzarzycki>* >
