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 <[email protected]> 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, <[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>*
>>
>
