Ok, thanks Alex, I will do that tomorrow.
On Mon, Oct 7, 2019 at 4:02 PM Alex Harui <aha...@adobe.com.invalid> wrote: > Improvements to the Maven builds and Ant builds are always welcome. Just > make sure they work from a truly clean machine (empty the local Maven repo, > build without access to the snapshots repo, etc). > > There are some issues with profile inheritance in Maven, but I don't > understand your proposal enough to know if there is some hole in it. Try > it and find out. > > -Alex > > On 10/6/19, 4:49 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > Hi Piotr, just a quick follow-up to let you know that was all good, I > had > already tested the merge and conflict resolution myself and was ready > to > step in and help with that if that was necessary, but you already did > it > before I got a chance to send my email about that. :) > > I have to say: well done for getting through the release process. I > could > sense your frustration at times, and I know it must have seemed like it > took far too long, but I am sure you have made a huge difference for > the > future in terms of that process. > > > also fyi, I had to use -Dgenerate.swf.swcs=true in my local maven build > today, and I was vaguely aware of discussions about this during release > prep. > But I wonder if this is necessary. Can't we just use the top level > profiles > at the lower levels instead of creating new profiles? There's probably > a > gap in my understanding of why this was necessary, but I would have > expected that we could simply use something like: > > <profile> > <id>generate-swcs-for-swf</id> > <dependencies> > <dependency> > <groupId>org.apache.royale.framework</groupId> > <artifactId>Core</artifactId> > <version>0.9.7-SNAPSHOT</version> > <type>swc</type> > <classifier>swf</classifier> > </dependency> > </dependencies> > </profile> > > in the framework modules, instead of: > > <profile> > <id>swf-dependencies</id> > <activation> > <property> > <name>generate.swf.swcs</name> > </property> > </activation> > <dependencies> > <dependency> > <groupId>org.apache.royale.framework</groupId> > <artifactId>Core</artifactId> > <version>0.9.7-SNAPSHOT</version> > <type>swc</type> > <classifier>swf</classifier> > </dependency> > </dependencies> > </profile> > > (the above approach works locally for me just using the maven profile > itself, if I make the changes to all framework modules, but as I said I > could be missing something in relation to the issue that is being > addressed) > > > On Sun, Oct 6, 2019 at 11:20 PM Greg Dove <greg.d...@gmail.com> wrote: > > > Hi Piotr, I will check that in the morning local time... in about 8 > hours. > > > > On Sun, 6 Oct 2019, 21:54 Piotr Zarzycki, <piotrzarzyck...@gmail.com > > > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fblob%2Fdevelop%2Fcompiler-jx%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Froyale%2Fcompiler%2Finternal%2Fcodegen%2Fjs%2Fjx%2FMemberAccessEmitter.java&data=02%7C01%7Caharui%40adobe.com%7C8e7bf2601258466052f808d74ab7db82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637060025834669854&sdata=AdnP68Opu%2BA8bOMc34%2FsNR2ZXT6gAHRsio9NX758278%3D&reserved=0 > >> > >> Thanks, > >> Piotr > >> > >> śr., 2 paź 2019 o 11:06 Harbs <harbs.li...@gmail.com> 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 <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=" > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&data=02%7C01%7Caharui%40adobe.com%7C8e7bf2601258466052f808d74ab7db82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637060025834679846&sdata=dYx3rwE7iZKrduSn3p7kqYBotYDyCNLnva5u6TbGie8%3D&reserved=0 > " > >> > >>>> xmlns:m="nothing">\n' + > >> > >>>> ' <link rel="no_namespace" > >> > >>>> href="blah/12321/domain/"/>\n' + > >> > >>>> '</feed>\n'); > >> > >>>> var atomSpace:Namespace = new Namespace(' > >> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&data=02%7C01%7Caharui%40adobe.com%7C8e7bf2601258466052f808d74ab7db82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637060025834679846&sdata=dYx3rwE7iZKrduSn3p7kqYBotYDyCNLnva5u6TbGie8%3D&reserved=0 > ' > >> > ); > >> > >>>> > >> > >>>> 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=" > >> > >>>> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&data=02%7C01%7Caharui%40adobe.com%7C8e7bf2601258466052f808d74ab7db82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637060025834679846&sdata=dYx3rwE7iZKrduSn3p7kqYBotYDyCNLnva5u6TbGie8%3D&reserved=0"; > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C8e7bf2601258466052f808d74ab7db82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637060025834679846&sdata=pj7NFkAeVnqv1GUjwcIWISUkHEEmeKhk82jLDpzLnfw%3D&reserved=0 > >> < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C8e7bf2601258466052f808d74ab7db82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637060025834679846&sdata=pj7NFkAeVnqv1GUjwcIWISUkHEEmeKhk82jLDpzLnfw%3D&reserved=0 > >* > >> > > > > >
