Jenkins build is back to normal : royale-asjs_MXTests #224

[apacheroyaleci]

See 

Re: Heads up on XML

[Harbs]

I had removed that line to avoid writing “element”. I just changed it to delete 
the property to get rid of the “TEXT” on instantiation.

> On Nov 28, 2019, at 8:29 PM, Greg Dove  wrote:
> 
> ' I don’t see that in the Ecma spec.'
> 
> yeah, it was fun working on this. (irony) . When things were not clear, I
> always used swf behavior as the 'spec'.
> 
> 
> 
> On Fri, Nov 29, 2019 at 7:25 AM Harbs  wrote:
> 
>> Yeah. I see it’s supposed to wrap the elements. Weird. I don’t see that in
>> the Ecma spec.
>> 
>> I see what I messed up. I’ll revert that bit.
>> 
>>> On Nov 28, 2019, at 8:20 PM, Greg Dove  wrote:
>>> 
>>> You mean this (hopefully the xml angle brackets won't be mangled in your
>>> view of this)?
>>> 
>>> var xml:XML = ;
>>> xml.appendChild("test1");
>>> xml.appendChild("test2");
>>> xml.appendChild();
>>> xml.appendChild("test3");
>>> xml.appendChild("test4");
>>> 
>>> 
>>> trace(xml.toXMLString())
>>> output in swf:
>>> 
>>> test1
>>> test2
>>> 
>>> test3
>>> test4
>>> 
>>> 
>>> 
>>> 
>>> On Fri, Nov 29, 2019 at 7:12 AM Harbs  wrote:
>>> 
 I can’t imagine where test3 comes from when you
>> append
 “test3”...
 
 It should be a text node. No?
 
> On Nov 28, 2019, at 8:09 PM, Greg Dove  wrote:
> 
> OK, I will check it now.
> 
> On Fri, Nov 29, 2019 at 7:08 AM Harbs  wrote:
> 
>> I’m getting two test failures on the XML tests.
>> 
>> testXMLNormalize is failing, but the test looks wrong to me. Could you
>> take a look?
>> 
>>> On Nov 28, 2019, at 7:32 PM, Greg Dove  wrote:
>>> 
>>> Oh - just saw this. Thanks.
>>> Please ignore my comments in the other thread :).
>>> 
>>> 
>>> On Fri, Nov 29, 2019 at 6:12 AM Harbs  wrote:
>>> 
 I finally got the nerve together to update my local environment.
 
 The changes look pretty good.
 
 I made a couple of small changes.
 
 One fixes hasAttribute which somehow broke with your changes.
 
 The second is a small tweak to the memory optimizations. The memory
 footprint seems to be a bit smaller than what it used to be.
 
 Good work. :-)
 
 Harbs
 
> On Oct 2, 2019, at 11:29 AM, Greg Dove 
>> 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 
 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 
>> 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 
 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.

Build failed in Jenkins: royale-asjs_MXTests #223

[apacheroyaleci]

See 


Changes:

[harbs] When testing for attributes the QName needs to be an attribute

[harbs] string literals are not set in the constructor

[harbs] cleanup


--
[...truncated 440.84 KB...]
[mxmlc] scanning for overrides: XMLNamespaceTest
[mxmlc] scanning for overrides: XMLQNameTest
[mxmlc] scanning for overrides: XMLTesterStringifyTest
[mxmlc] scanning for overrides: IContainer
[mxmlc] scanning for overrides: IDocument
[mxmlc] scanning for overrides: IMXMLDocument
[mxmlc] scanning for overrides: IRoyaleElement
[mxmlc] scanning for overrides: IHandlesOriginalEvent
[mxmlc] scanning for overrides: MouseEvent
[mxmlc] scanning for overrides: Timer
[mxmlc] scanning for overrides: DefinitionBase
[mxmlc] scanning for overrides: MetaDataArgDefinition
[mxmlc] scanning for overrides: MetaDataDefinition
[mxmlc] scanning for overrides: DefinitionWithMetaData
[mxmlc] scanning for overrides: TypeDefinition
[mxmlc] scanning for overrides: Failure
[mxmlc] scanning for overrides: Result
[mxmlc] scanning for overrides: ResultListener
[mxmlc] scanning for overrides: IAsyncHandler
[mxmlc] scanning for overrides: MetadataRunner
[mxmlc] scanning for overrides: TestInfo
[mxmlc] scanning for overrides: AsyncHandler
[mxmlc] scanning for overrides: SuiteRunner
[mxmlc] scanning for overrides: TestMetadata
[mxmlc] scanning for overrides: AssertionError
[mxmlc] scanning for overrides: XMLNamespaceClassTest
[mxmlc] scanning for overrides: XMLTesterGeneralTest
[mxmlc] scanning for overrides: NamespaceTest
[mxmlc] scanning for overrides: Point
[mxmlc] scanning for overrides: PointUtils
[mxmlc] scanning for overrides: MemberDefinitionBase
[mxmlc] scanning for overrides: VariableDefinition
[mxmlc] scanning for overrides: AccessorDefinition
[mxmlc] scanning for overrides: MethodDefinition
[mxmlc] scanning for overrides: AsyncLocator
[mxmlc] scanning for overrides: Assert
[mxmlc] scanning for overrides: QNameTest
[mxmlc] scanning for overrides: ParameterDefinition
[mxmlc] 
:
 col: 13 Warning: declaration 'atom' will be scoped to the default namespace:  
internal. It will not be visible outside of this package.
[mxmlc] 
[mxmlc] namespace atom = "http://www.w3.org/2005/Atom;
[mxmlc] ^
[mxmlc] 
[mxmlc] 
:
 col: 13 Warning: declaration 'atom' will be scoped to the default namespace:  
internal. It will not be visible outside of this package.
[mxmlc] 
[mxmlc] namespace atom = "http://www.w3.org/2005/Atom;
[mxmlc] ^
[mxmlc] 
[mxmlc] 
:
 col: 13 Warning: declaration 'royale' will be scoped to the default namespace: 
 internal. It will not be visible outside of this package.
[mxmlc] 
[mxmlc] namespace royale = "https://royale.apache.org;
[mxmlc] ^
[mxmlc] 
[mxmlc] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g
[mxmlc] 60412 bytes written to 
C:\jenkins\workspace\royale-asjs_MXTests\frameworks\projects\XML\src\test\royale\FlexUnitRoyaleApplication.swf
 in 2.721 seconds
[mxmlc] 3.6224841 seconds

test:
[mkdir] Created dir: 

[royaleunit] Validating task attributes ...
[royaleunit] Generating default values ...
[royaleunit] Using the following settings for the test run:
[royaleunit]ROYALE_HOME: 
[
[royaleunit]haltonfailure: [true]
[royaleunit]headless: [false]
[royaleunit]display: [99]
[royaleunit]localTrusted: [true]
[royaleunit]player: [flash]
[royaleunit]command: [C:\adobe\flash\11.7\flashplayerdebugger.exe]
[royaleunit]port: [1024]
[royaleunit]swf: 
[
[royaleunit]timeout: [9ms]
[royaleunit]toDir: 
[
[royaleunit] Setting up server process ...
[royaleunit] 

Re: Heads up on XML

[Greg Dove]

' I don’t see that in the Ecma spec.'

yeah, it was fun working on this. (irony) . When things were not clear, I
always used swf behavior as the 'spec'.



On Fri, Nov 29, 2019 at 7:25 AM Harbs  wrote:

> Yeah. I see it’s supposed to wrap the elements. Weird. I don’t see that in
> the Ecma spec.
>
> I see what I messed up. I’ll revert that bit.
>
> > On Nov 28, 2019, at 8:20 PM, Greg Dove  wrote:
> >
> > You mean this (hopefully the xml angle brackets won't be mangled in your
> > view of this)?
> >
> > var xml:XML = ;
> > xml.appendChild("test1");
> > xml.appendChild("test2");
> > xml.appendChild();
> > xml.appendChild("test3");
> > xml.appendChild("test4");
> >
> >
> > trace(xml.toXMLString())
> > output in swf:
> > 
> >  test1
> >  test2
> >  
> >  test3
> >  test4
> > 
> >
> >
> >
> > On Fri, Nov 29, 2019 at 7:12 AM Harbs  wrote:
> >
> >> I can’t imagine where test3 comes from when you
> append
> >> “test3”...
> >>
> >> It should be a text node. No?
> >>
> >>> On Nov 28, 2019, at 8:09 PM, Greg Dove  wrote:
> >>>
> >>> OK, I will check it now.
> >>>
> >>> On Fri, Nov 29, 2019 at 7:08 AM Harbs  wrote:
> >>>
>  I’m getting two test failures on the XML tests.
> 
>  testXMLNormalize is failing, but the test looks wrong to me. Could you
>  take a look?
> 
> > On Nov 28, 2019, at 7:32 PM, Greg Dove  wrote:
> >
> > Oh - just saw this. Thanks.
> > Please ignore my comments in the other thread :).
> >
> >
> > On Fri, Nov 29, 2019 at 6:12 AM Harbs  wrote:
> >
> >> I finally got the nerve together to update my local environment.
> >>
> >> The changes look pretty good.
> >>
> >> I made a couple of small changes.
> >>
> >> One fixes hasAttribute which somehow broke with your changes.
> >>
> >> The second is a small tweak to the memory optimizations. The memory
> >> footprint seems to be a bit smaller than what it used to be.
> >>
> >> Good work. :-)
> >>
> >> Harbs
> >>
> >>> On Oct 2, 2019, at 11:29 AM, Greg Dove 
> 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 
> >> 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 
> 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 
> >> 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 

Re: Heads up on XML

[Harbs]

Yeah. I see it’s supposed to wrap the elements. Weird. I don’t see that in the 
Ecma spec.

I see what I messed up. I’ll revert that bit.

> On Nov 28, 2019, at 8:20 PM, Greg Dove  wrote:
> 
> You mean this (hopefully the xml angle brackets won't be mangled in your
> view of this)?
> 
> var xml:XML = ;
> xml.appendChild("test1");
> xml.appendChild("test2");
> xml.appendChild();
> xml.appendChild("test3");
> xml.appendChild("test4");
> 
> 
> trace(xml.toXMLString())
> output in swf:
> 
>  test1
>  test2
>  
>  test3
>  test4
> 
> 
> 
> 
> On Fri, Nov 29, 2019 at 7:12 AM Harbs  wrote:
> 
>> I can’t imagine where test3 comes from when you append
>> “test3”...
>> 
>> It should be a text node. No?
>> 
>>> On Nov 28, 2019, at 8:09 PM, Greg Dove  wrote:
>>> 
>>> OK, I will check it now.
>>> 
>>> On Fri, Nov 29, 2019 at 7:08 AM Harbs  wrote:
>>> 
 I’m getting two test failures on the XML tests.
 
 testXMLNormalize is failing, but the test looks wrong to me. Could you
 take a look?
 
> On Nov 28, 2019, at 7:32 PM, Greg Dove  wrote:
> 
> Oh - just saw this. Thanks.
> Please ignore my comments in the other thread :).
> 
> 
> On Fri, Nov 29, 2019 at 6:12 AM Harbs  wrote:
> 
>> I finally got the nerve together to update my local environment.
>> 
>> The changes look pretty good.
>> 
>> I made a couple of small changes.
>> 
>> One fixes hasAttribute which somehow broke with your changes.
>> 
>> The second is a small tweak to the memory optimizations. The memory
>> footprint seems to be a bit smaller than what it used to be.
>> 
>> Good work. :-)
>> 
>> Harbs
>> 
>>> On Oct 2, 2019, at 11:29 AM, Greg Dove  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 
>> 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  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 
>> 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

Re: Heads up on XML

[Greg Dove]

You mean this (hopefully the xml angle brackets won't be mangled in your
view of this)?

var xml:XML = ;
xml.appendChild("test1");
xml.appendChild("test2");
xml.appendChild();
xml.appendChild("test3");
xml.appendChild("test4");


trace(xml.toXMLString())
output in swf:

  test1
  test2
  
  test3
  test4




On Fri, Nov 29, 2019 at 7:12 AM Harbs  wrote:

> I can’t imagine where test3 comes from when you append
> “test3”...
>
> It should be a text node. No?
>
> > On Nov 28, 2019, at 8:09 PM, Greg Dove  wrote:
> >
> > OK, I will check it now.
> >
> > On Fri, Nov 29, 2019 at 7:08 AM Harbs  wrote:
> >
> >> I’m getting two test failures on the XML tests.
> >>
> >> testXMLNormalize is failing, but the test looks wrong to me. Could you
> >> take a look?
> >>
> >>> On Nov 28, 2019, at 7:32 PM, Greg Dove  wrote:
> >>>
> >>> Oh - just saw this. Thanks.
> >>> Please ignore my comments in the other thread :).
> >>>
> >>>
> >>> On Fri, Nov 29, 2019 at 6:12 AM Harbs  wrote:
> >>>
>  I finally got the nerve together to update my local environment.
> 
>  The changes look pretty good.
> 
>  I made a couple of small changes.
> 
>  One fixes hasAttribute which somehow broke with your changes.
> 
>  The second is a small tweak to the memory optimizations. The memory
>  footprint seems to be a bit smaller than what it used to be.
> 
>  Good work. :-)
> 
>  Harbs
> 
> > On Oct 2, 2019, at 11:29 AM, Greg Dove  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 
> 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  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 
> 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 

Re: Heads up on XML

[Harbs]

I can’t imagine where test3 comes from when you append 
“test3”...

It should be a text node. No?

> On Nov 28, 2019, at 8:09 PM, Greg Dove  wrote:
> 
> OK, I will check it now.
> 
> On Fri, Nov 29, 2019 at 7:08 AM Harbs  wrote:
> 
>> I’m getting two test failures on the XML tests.
>> 
>> testXMLNormalize is failing, but the test looks wrong to me. Could you
>> take a look?
>> 
>>> On Nov 28, 2019, at 7:32 PM, Greg Dove  wrote:
>>> 
>>> Oh - just saw this. Thanks.
>>> Please ignore my comments in the other thread :).
>>> 
>>> 
>>> On Fri, Nov 29, 2019 at 6:12 AM Harbs  wrote:
>>> 
 I finally got the nerve together to update my local environment.
 
 The changes look pretty good.
 
 I made a couple of small changes.
 
 One fixes hasAttribute which somehow broke with your changes.
 
 The second is a small tweak to the memory optimizations. The memory
 footprint seems to be a bit smaller than what it used to be.
 
 Good work. :-)
 
 Harbs
 
> On Oct 2, 2019, at 11:29 AM, Greg Dove  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  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  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  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 = 
 
 Bob
 32
 
 

Re: Heads up on XML

[Greg Dove]

OK, I will check it now.

On Fri, Nov 29, 2019 at 7:08 AM Harbs  wrote:

> I’m getting two test failures on the XML tests.
>
> testXMLNormalize is failing, but the test looks wrong to me. Could you
> take a look?
>
> > On Nov 28, 2019, at 7:32 PM, Greg Dove  wrote:
> >
> > Oh - just saw this. Thanks.
> > Please ignore my comments in the other thread :).
> >
> >
> > On Fri, Nov 29, 2019 at 6:12 AM Harbs  wrote:
> >
> >> I finally got the nerve together to update my local environment.
> >>
> >> The changes look pretty good.
> >>
> >> I made a couple of small changes.
> >>
> >> One fixes hasAttribute which somehow broke with your changes.
> >>
> >> The second is a small tweak to the memory optimizations. The memory
> >> footprint seems to be a bit smaller than what it used to be.
> >>
> >> Good work. :-)
> >>
> >> Harbs
> >>
> >>> On Oct 2, 2019, at 11:29 AM, Greg Dove  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  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  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  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 = 
> >>  
> >>  Bob
> >>  32
> >>  
> >>  
> >>  Joe
> >>  46
> >>  
> >>  ;
> >> var findJoeByAge:Function = function (i:int):Boolean {
> >>  

Re: Heads up on XML

[Harbs]

I’m getting two test failures on the XML tests.

testXMLNormalize is failing, but the test looks wrong to me. Could you take a 
look?

> On Nov 28, 2019, at 7:32 PM, Greg Dove  wrote:
> 
> Oh - just saw this. Thanks.
> Please ignore my comments in the other thread :).
> 
> 
> On Fri, Nov 29, 2019 at 6:12 AM Harbs  wrote:
> 
>> I finally got the nerve together to update my local environment.
>> 
>> The changes look pretty good.
>> 
>> I made a couple of small changes.
>> 
>> One fixes hasAttribute which somehow broke with your changes.
>> 
>> The second is a small tweak to the memory optimizations. The memory
>> footprint seems to be a bit smaller than what it used to be.
>> 
>> Good work. :-)
>> 
>> Harbs
>> 
>>> On Oct 2, 2019, at 11:29 AM, Greg Dove  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  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  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  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 = 
>>  
>>  Bob
>>  32
>>  
>>  
>>  Joe
>>  46
>>  
>>  ;
>> 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.
>> 

Re: Heads up on XML

[Greg Dove]

Harbs,

I don't have time to look into it right now, but those last changes break a
couple of royaleunit tests.
The tests could be wrong (but for the most part they do run the same tests
between swf and js).

If you ever want to test these in isolation after you make changes, you can
go into the XML project in console (with all normal env vars set) and just
use:
ant test



On Fri, Nov 29, 2019 at 6:32 AM Greg Dove  wrote:

>
> Oh - just saw this. Thanks.
> Please ignore my comments in the other thread :).
>
>
> On Fri, Nov 29, 2019 at 6:12 AM Harbs  wrote:
>
>> I finally got the nerve together to update my local environment.
>>
>> The changes look pretty good.
>>
>> I made a couple of small changes.
>>
>> One fixes hasAttribute which somehow broke with your changes.
>>
>> The second is a small tweak to the memory optimizations. The memory
>> footprint seems to be a bit smaller than what it used to be.
>>
>> Good work. :-)
>>
>> Harbs
>>
>> > On Oct 2, 2019, at 11:29 AM, Greg Dove  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  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  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  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 = 
>>    
>>    Bob
>>    32
>>    
>>    
>>    Joe
>>    46
>>    
>>    ;
>>  var findJoeByAge:Function = function (i:int):Boolean {
>>    

Re: Heads up on XML

[Greg Dove]

Oh - just saw this. Thanks.
Please ignore my comments in the other thread :).


On Fri, Nov 29, 2019 at 6:12 AM Harbs  wrote:

> I finally got the nerve together to update my local environment.
>
> The changes look pretty good.
>
> I made a couple of small changes.
>
> One fixes hasAttribute which somehow broke with your changes.
>
> The second is a small tweak to the memory optimizations. The memory
> footprint seems to be a bit smaller than what it used to be.
>
> Good work. :-)
>
> Harbs
>
> > On Oct 2, 2019, at 11:29 AM, Greg Dove  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  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  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  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 = 
>    
>    Bob
>    32
>    
>    
>    Joe
>    46
>    
>    ;
>  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(
>    'http://www.w3.org/2005/Atom;
>  

Re: [royale-asjs] branch develop updated: string literals are not set in the constructor

[Greg Dove]

Harbs, I never did verify that the original change to use string references
instead of literals saved memory - it should have (in theory), but I think
you were going to check. Did it make a difference? Certainly if it does
not, you should remove it (I think it was a single commit isolated from
other changes)



On Fri, Nov 29, 2019 at 6:07 AM Harbs  wrote:

> The older code works, but this code uses less memory.
>
> Greg added an optimization to use String class instances instead of
> literals. That optimization undid an older optimization of not writing the
> default nodeKinds.
>
> Reverting to default literals on the prototype saved a couple of MB of
> memory in my app.
>
> > On Nov 28, 2019, at 7:00 PM, Alex Harui 
> wrote:
> >
> > Is this a temporary workaround? Shouldn't the old code work?
> >
> > Get Outlook for Android
> >
> > 
> > From: ha...@apache.org 
> > Sent: Thursday, November 28, 2019 8:50:10 AM
> > To: comm...@royale.apache.org 
> > Subject: [royale-asjs] branch develop updated: string literals are not
> set in the constructor
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > harbs pushed a commit to branch develop
> > in repository
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.gitdata=02%7C01%7Caharui%40adobe.com%7C5e9143c74afb4b2e0cd308d7742308d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637105566130549447sdata=gvTjl3kQ2I04ghkuwarZ7VBaGLXXdWMbA74WFfptQik%3Dreserved=0
> >
> >
> > The following commit(s) were added to refs/heads/develop by this push:
> > new 265c230  string literals are not set in the constructor
> > 265c230 is described below
> >
> > commit 265c230ac5d555b2643bb9220bb5b69408abd66d
> > Author: Harbs 
> > AuthorDate: Thu Nov 28 18:49:50 2019 +0200
> >
> >string literals are not set in the constructor
> >
> >The string literal will work because the comparison is not strict
> > ---
> > frameworks/projects/XML/src/main/royale/XML.as | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/frameworks/projects/XML/src/main/royale/XML.as
> b/frameworks/projects/XML/src/main/royale/XML.as
> > index 8bdc99e..2ecd067 100644
> > --- a/frameworks/projects/XML/src/main/royale/XML.as
> > +++ b/frameworks/projects/XML/src/main/royale/XML.as
> > @@ -906,7 +906,7 @@ package
> > if (lastChild && lastChild._nodeKind ==
> ELEMENT) {
> >
> > const wrapper:XML = new XML();
> > -   wrapper._nodeKind = ELEMENT;
> > +   // wrapper._nodeKind = ELEMENT;
> > child = new
> XML(child.toString());
> >
>  wrapper.setName(lastChild.name());
> > child.setParent(wrapper);
> > @@ -1169,7 +1169,7 @@ package
> > */
> > var i:int;
> > var xml:XML = new XML();
> > -   xml._nodeKind = _nodeKind;
> > +   xml.setNodeKind(_nodeKind);
> > xml.setName(name());
> > xml.setValue(_value);
> > var len:int;
> > @@ -1872,7 +1872,7 @@ package
> > return declaredNS;
> > }
> >
> > -   private var _nodeKind:String = ELEMENT;
> > +   private var _nodeKind:String = "element";
> > /**
> >  * Specifies the type of node: text, comment,
> processing-instruction, attribute, or element.
> >  * @return
> >
>
>

Re: Heads up on XML

[Harbs]

I finally got the nerve together to update my local environment.

The changes look pretty good.

I made a couple of small changes.

One fixes hasAttribute which somehow broke with your changes.

The second is a small tweak to the memory optimizations. The memory footprint 
seems to be a bit smaller than what it used to be.

Good work. :-)

Harbs

> On Oct 2, 2019, at 11:29 AM, Greg Dove  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  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  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  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 = 
   
   Bob
   32
   
   
   Joe
   46
   
   ;
 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(
   'http://www.w3.org/2005/Atom;
 xmlns:m="nothing">\n' +
   '  >>> href="blah/12321/domain/"/>\n' +
   '\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:
 

Re: [royale-asjs] branch develop updated: string literals are not set in the constructor

[Harbs]

The older code works, but this code uses less memory.

Greg added an optimization to use String class instances instead of literals. 
That optimization undid an older optimization of not writing the default 
nodeKinds.

Reverting to default literals on the prototype saved a couple of MB of memory 
in my app.

> On Nov 28, 2019, at 7:00 PM, Alex Harui  wrote:
> 
> Is this a temporary workaround? Shouldn't the old code work?
> 
> Get Outlook for Android
> 
> 
> From: ha...@apache.org 
> Sent: Thursday, November 28, 2019 8:50:10 AM
> To: comm...@royale.apache.org 
> Subject: [royale-asjs] branch develop updated: string literals are not set in 
> the constructor
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> harbs pushed a commit to branch develop
> in repository 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.gitdata=02%7C01%7Caharui%40adobe.com%7C5e9143c74afb4b2e0cd308d7742308d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637105566130549447sdata=gvTjl3kQ2I04ghkuwarZ7VBaGLXXdWMbA74WFfptQik%3Dreserved=0
> 
> 
> The following commit(s) were added to refs/heads/develop by this push:
> new 265c230  string literals are not set in the constructor
> 265c230 is described below
> 
> commit 265c230ac5d555b2643bb9220bb5b69408abd66d
> Author: Harbs 
> AuthorDate: Thu Nov 28 18:49:50 2019 +0200
> 
>string literals are not set in the constructor
> 
>The string literal will work because the comparison is not strict
> ---
> frameworks/projects/XML/src/main/royale/XML.as | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/frameworks/projects/XML/src/main/royale/XML.as 
> b/frameworks/projects/XML/src/main/royale/XML.as
> index 8bdc99e..2ecd067 100644
> --- a/frameworks/projects/XML/src/main/royale/XML.as
> +++ b/frameworks/projects/XML/src/main/royale/XML.as
> @@ -906,7 +906,7 @@ package
> if (lastChild && lastChild._nodeKind == 
> ELEMENT) {
> 
> const wrapper:XML = new XML();
> -   wrapper._nodeKind = ELEMENT;
> +   // wrapper._nodeKind = ELEMENT;
> child = new XML(child.toString());
> wrapper.setName(lastChild.name());
> child.setParent(wrapper);
> @@ -1169,7 +1169,7 @@ package
> */
> var i:int;
> var xml:XML = new XML();
> -   xml._nodeKind = _nodeKind;
> +   xml.setNodeKind(_nodeKind);
> xml.setName(name());
> xml.setValue(_value);
> var len:int;
> @@ -1872,7 +1872,7 @@ package
> return declaredNS;
> }
> 
> -   private var _nodeKind:String = ELEMENT;
> +   private var _nodeKind:String = "element";
> /**
>  * Specifies the type of node: text, comment, 
> processing-instruction, attribute, or element.
>  * @return
> 

Re: [royale-asjs] branch develop updated: string literals are not set in the constructor

[Alex Harui]

Is this a temporary workaround? Shouldn't the old code work?

Get Outlook for Android


From: ha...@apache.org 
Sent: Thursday, November 28, 2019 8:50:10 AM
To: comm...@royale.apache.org 
Subject: [royale-asjs] branch develop updated: string literals are not set in 
the constructor

This is an automated email from the ASF dual-hosted git repository.

harbs pushed a commit to branch develop
in repository 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.gitdata=02%7C01%7Caharui%40adobe.com%7C5e9143c74afb4b2e0cd308d7742308d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637105566130549447sdata=gvTjl3kQ2I04ghkuwarZ7VBaGLXXdWMbA74WFfptQik%3Dreserved=0


The following commit(s) were added to refs/heads/develop by this push:
 new 265c230  string literals are not set in the constructor
265c230 is described below

commit 265c230ac5d555b2643bb9220bb5b69408abd66d
Author: Harbs 
AuthorDate: Thu Nov 28 18:49:50 2019 +0200

string literals are not set in the constructor

The string literal will work because the comparison is not strict
---
 frameworks/projects/XML/src/main/royale/XML.as | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/frameworks/projects/XML/src/main/royale/XML.as 
b/frameworks/projects/XML/src/main/royale/XML.as
index 8bdc99e..2ecd067 100644
--- a/frameworks/projects/XML/src/main/royale/XML.as
+++ b/frameworks/projects/XML/src/main/royale/XML.as
@@ -906,7 +906,7 @@ package
 if (lastChild && lastChild._nodeKind == 
ELEMENT) {

 const wrapper:XML = new XML();
-   wrapper._nodeKind = ELEMENT;
+   // wrapper._nodeKind = ELEMENT;
 child = new XML(child.toString());
 wrapper.setName(lastChild.name());
 child.setParent(wrapper);
@@ -1169,7 +1169,7 @@ package
 */
 var i:int;
 var xml:XML = new XML();
-   xml._nodeKind = _nodeKind;
+   xml.setNodeKind(_nodeKind);
 xml.setName(name());
 xml.setValue(_value);
 var len:int;
@@ -1872,7 +1872,7 @@ package
 return declaredNS;
 }

-   private var _nodeKind:String = ELEMENT;
+   private var _nodeKind:String = "element";
 /**
  * Specifies the type of node: text, comment, 
processing-instruction, attribute, or element.
  * @return

Re: [royale-compiler] branch develop updated: should we add these generated files? (if not please remove)

[Carlos Rovira]

I was figuring that, but wasn't sure, will remove it

El jue., 28 nov. 2019 a las 17:04, Alex Harui ()
escribió:

> I haven't built the compiler, but in general we do not want to commit
> generated files.  Why would these be an exception?
>
> -Alex
>
> On 11/28/19, 7:17 AM, "carlosrov...@apache.org" 
> wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> carlosrovira pushed a commit to branch develop
> in repository
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-compiler.gitdata=02%7C01%7Caharui%40adobe.com%7Cbe827a0702184edabb1708d774162394%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637105510754711745sdata=sOb8FVjrZzDwZD2wc1iELgaV6z3OhrxHgHYmmJep8BI%3Dreserved=0
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new f48d105  should we add these generated files? (if not please
> remove)
> f48d105 is described below
>
> commit f48d1051cd2524bc133f96081aa67ba55212bab0
> Author: Carlos Rovira 
> AuthorDate: Thu Nov 28 16:17:39 2019 +0100
>
> should we add these generated files? (if not please remove)
> ---
>  compiler-jx/src/assembly/compiler-override-scripts/compc | 0
>  compiler-jx/src/assembly/compiler-override-scripts/mxmlc | 0
>  2 files changed, 0 insertions(+), 0 deletions(-)
>
> diff --git a/compiler-jx/src/assembly/compiler-override-scripts/compc
> b/compiler-jx/src/assembly/compiler-override-scripts/compc
> old mode 100644
> new mode 100755
> diff --git a/compiler-jx/src/assembly/compiler-override-scripts/mxmlc
> b/compiler-jx/src/assembly/compiler-override-scripts/mxmlc
> old mode 100644
> new mode 100755
>
>
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [royale-compiler] branch develop updated: should we add these generated files? (if not please remove)

[Alex Harui]

I haven't built the compiler, but in general we do not want to commit generated 
files.  Why would these be an exception?

-Alex

On 11/28/19, 7:17 AM, "carlosrov...@apache.org"  
wrote:

This is an automated email from the ASF dual-hosted git repository.

carlosrovira pushed a commit to branch develop
in repository 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-compiler.gitdata=02%7C01%7Caharui%40adobe.com%7Cbe827a0702184edabb1708d774162394%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637105510754711745sdata=sOb8FVjrZzDwZD2wc1iELgaV6z3OhrxHgHYmmJep8BI%3Dreserved=0


The following commit(s) were added to refs/heads/develop by this push:
 new f48d105  should we add these generated files? (if not please 
remove)
f48d105 is described below

commit f48d1051cd2524bc133f96081aa67ba55212bab0
Author: Carlos Rovira 
AuthorDate: Thu Nov 28 16:17:39 2019 +0100

should we add these generated files? (if not please remove)
---
 compiler-jx/src/assembly/compiler-override-scripts/compc | 0
 compiler-jx/src/assembly/compiler-override-scripts/mxmlc | 0
 2 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/compiler-jx/src/assembly/compiler-override-scripts/compc 
b/compiler-jx/src/assembly/compiler-override-scripts/compc
old mode 100644
new mode 100755
diff --git a/compiler-jx/src/assembly/compiler-override-scripts/mxmlc 
b/compiler-jx/src/assembly/compiler-override-scripts/mxmlc
old mode 100644
new mode 100755