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>*
>

Reply via email to