Hi Piotr, quick response below...
> <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>
>
>
How this activates generate.swf.swcs ? What should I do if I wanted to
build only one module ? Doing that in above way how will change main
command which launches maven build ?
For: How this activates generate.swf.swcs ?
Response:
It doesn't - it would use the already defined profile ('
generate-swcs-for-swf') but the same dependency variations that are
currently specified for 'generate.swf.swcs' .
I did not have time to test this yet with a clean maven repo.
Basically instead of : mvn clean install -Pmain,generate-swcs-for-swf
-Dgenerate.swf.swcs=true
It would be (as before) mvn clean install -Pmain,generate-swcs-for-swf
The ' -Dgenerate.swf.swcs=true' is necessary to activate the new profile
defined at lower levels.
but because the
generate-swcs-for-swf
profile is already defined at a higher level and includes the airglobal
dependency (alongside 'generate-swf' which includes playerglobal)
it can also be used in the lower modules to add swf-only dependencies
so we should (usually, I think, in my experience with customer projects)
re-use the top level profile in the lower level maven modules.
But I am not really clear in my understanding of details of the problem
that this original change had to solve, so I might be missing something.
>From an IDE perspective (which was really why I focused on this originally,
because I use maven by default from my IDE and things started to look a lot
more complicated), I have this working now, and I just 'check' (select the
checkbox for) the 'generate-swcs-for-swf' profile and the 'main' profile
in my maven IDE tools, instead of 'checking' two different profiles, then I
can build the combo of js and swf swcs individually for each framework
project from my ide, which is how I do it locally when I make changes.
Hopefully I can check this today... I will try
On Tue, Oct 8, 2019 at 8:33 PM Piotr Zarzycki <[email protected]>
wrote:
> Hi Greg,
>
> Questions inline.
>
> pon., 7 paź 2019 o 01:49 Greg Dove <[email protected]> napisał(a):
>
> > 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>
> >
> >
> How this activates generate.swf.swcs ? What should I do if I wanted to
> build only one module ? Doing that in above way how will change main
> command which launches maven build ?
>
>
> > 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>*
> > >>
> > >
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
