You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Greg Dove <gr...@gmail.com> on 2019/09/04 10:02:35 UTC
Heads up on XML
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.
Re: Heads up on XML
Posted by Alex Harui <ah...@adobe.com.INVALID>.
No worries. I spent today on release stuff as well.
On 9/9/19, 11:01 PM, "Greg Dove" <gr...@gmail.com> wrote:
And... I'm still going. I keep finding things that need addressing. I am in
attributes now.
Anyway, I haven't gotten to the memory testing yet and I need to focus
tomorrow on showing my client progress, so I'm sorry but this code will be
another couple of days.
If you do look into the as2 XMLDocument stuff and find issues with
emulating that in Royale XML, feel free to ask me about anything that might
be changing (to match what swf does). Otherwise it might be easier to wait
and see if you really need some of those fixes. Once again, sorry for the
delay. I prefer to get what I get in 'right' rather than have only some of
it right.
On Mon, Sep 9, 2019 at 5:33 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> No problem. I've spent today trying to fix the build in the Ant source
> package.
>
> -Alex
>
> On 9/8/19, 10:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Not quite there yet with the final changes, I'm afraid. I'm getting
> close... should be tomorrow my time.
>
>
> On Sun, Sep 8, 2019 at 7:32 AM Greg Dove <gr...@gmail.com> wrote:
>
> >
> > Yeah thanks Josh, Alex made a suggestion for that option too, it was
> the
> > one I thought I would try first. I hope to get there later today, so
> I will
> > see if I can figure that out.
> >
> >
> > On Sun, Sep 8, 2019 at 7:20 AM Josh Tynjala <
> joshtynjala@bowlerhat.dev>
> > wrote:
> >
> >> I think the DITA files generated by asdoc are pretty big too, so
> they're
> >> probably really useful for your testing.
> >>
> >> - Josh
> >>
> >> On Friday, September 6, 2019, Greg Dove <gr...@gmail.com>
> wrote:
> >> > 'I think that SWFDump will generate valid XML and there is a way
> to get
> >> > DITA files from Flex ASDoc that are valid XML.'
> >> > Sounds like a good idea for some large xml files. I did not use
> that
> >> yet,
> >> > so will take a look and see if I can figure it out. Thanks!
> >> >
> >> >
> >> > On Sat, Sep 7, 2019 at 12:30 PM Greg Dove <gr...@gmail.com>
> wrote:
> >> >
> >> >>
> >> >> Just to clarify.... I was referring to this stuff here:
> >> >>
> >> >>
> >> >>
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2F8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab%2Fframeworks%2Fprojects%2FMXRoyale%2Fsrc%2Fmain%2Froyale%2Fmx%2Frpc%2Fhttp%2FAbstractOperation.as%23L1038&data=02%7C01%7Caharui%40adobe.com%7C3438477ce0cc42e9154208d735b4515c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036920920719112&sdata=jToiV1bfSAp4usWQWHomy%2Bc%2F1Dj4rSUDXDtoVNeoluI%3D&reserved=0
> >> >>
> >> >>
> >> >> with '//old XML style'
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui
> <ah...@adobe.com.invalid>
> >> >> wrote:
> >> >>
> >> >>> I haven't looked at what XML is used/supported by MX
> HTTPService. It
> >> >>> looks like WebService does use MX HTTPService. I am currently
> >> migrating
> >> >>> other things that WebService needs (XMLEncoder/Decoder,
> >> >>> SOAPEncoder/Decoder). These are new files that aren't in the
> repo
> >> yet,
> >> so
> >> >>> HTTPService couldn't be relying on them or else their use is
> commented
> >> >>> out. The goal is to change as little as possible to get it to
> >> compile
> >> and
> >> >>> then see if it runs. I have no idea yet if the XML
> improvements you
> >> are
> >> >>> working on are going to be impactful on what I'm doing or not.
> >> >>>
> >> >>> BTW, I could be wrong, but I think that SWFDump will generate
> valid
> >> XML
> >> >>> and there is a way to get DITA files from Flex ASDoc that are
> valid
> >> XML.
> >> >>>
> >> >>> Thanks for the heads up,
> >> >>> -Alex
> >> >>>
> >> >>> On 9/6/19, 5:14 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >> >>>
> >> >>> Actually I know you are looking into the WSDL stuff....
> maybe this
> >> is
> >> >>> going
> >> >>> to be important for that (not sure)?
> >> >>> My goal is to get the XML stuff tidied up and ready to push
> by end
> >> of
> >> >>> day
> >> >>> tomorrow, worst case the following morning, local time
> (UTC+12). I
> >> >>> also
> >> >>> need to find some big XML test cases to check the memory
> side of
> >> >>> things.
> >> >>> FYI there is also some XMLDocument stuff missing (commented
> out)
> >> from
> >> >>> some
> >> >>> of the MX HttpService code, which came up in a recent
> issue. I
> >> don't
> >> >>> know
> >> >>> if it shares any of the code from the WSDL stuff you are
> looking
> >> at
> >> or
> >> >>> not...
> >> >>> If it does then I don't want to double up on things, but
> >> otherwise I
> >> >>> will
> >> >>> try to look at that on my Monday.
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <
> greg.dove@gmail.com>
> >> >>> wrote:
> >> >>>
> >> >>> > Thanks for checking that.
> >> >>> >
> >> >>> > child is specified in 13.4.4.6 and essentially calls
> [[Get]]
> >> >>> > (After cycling through this kind of thing a few times, I
> found
> >> the
> >> >>> easiest
> >> >>> > way to find methods is to search in the spec for
> 'e.mehodName'
> >> >>> which gets
> >> >>> > you XML.prototype.methodName)
> >> >>> >
> >> >>> > and [[Get]] is specified in 9.1.1.1
> >> >>> >
> >> >>> > So I assume it is a bug. As discussed I think it is good
> to
> >> match
> >> >>> the
> >> >>> > behavior. If we can verify 100% it is off spec, we could
> add
> >> >>> something as a
> >> >>> > define to avoid the 'fix' for people who want to be
> on-spec.
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui
> >> <aharui@adobe.com.invalid
> >> >>> >
> >> >>> > wrote:
> >> >>> >
> >> >>> >> FWIW, I went and looked at the ABC.
> >> >>> >>
> >> >>> >> The first syntax sets up a getProperty just like any
> other
> >> property
> >> >>> >> fetch. The second (as expected) calls "child()". I've
> looked
> >> at
> >> >>> the E4X
> >> >>> >> spec a couple of times now and cannot see where the
> behavior we
> >> >>> are seeing
> >> >>> >> in child() is specified so I am going to assume it is a
> bug,
> >> and
> >> >>> that we
> >> >>> >> just have to live with it.
> >> >>> >>
> >> >>> >> I expect that getProperty does not call child(). I
> haven't
> >> looked
> >> >>> at the
> >> >>> >> AVM code to see what getProperty does for XML.
> >> >>> >>
> >> >>> >> HTH,
> >> >>> >> -Alex
> >> >>> >>
> >> >>> >> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com>
> wrote:
> >> >>> >>
> >> >>> >> Oh that is a good find! And perfect timing :)
> >> >>> >> Thanks Alex, I am pretty sure that answers the
> question!
> >> (It
> >> >>> quite
> >> >>> >> specifically describes what I was seeing, I don't
> think it
> >> >>> makes a
> >> >>> >> difference whether it is attributes or elements)
> >> >>> >>
> >> >>> >> And yes, I agree it should be the implemented to
> give the
> >> same
> >> >>> >> results as
> >> >>> >> swf.
> >> >>> >> I will add this to the other work I have over the
> weekend
> >> >>> before I
> >> >>> >> get it
> >> >>> >> in. It only seems relevant for when child (or
> descendants,
> >> I
> >> >>> don't
> >> >>> >> expect
> >> >>> >> that will be different) method call is explicit (as
> opposed
> >> to
> >> >>> the
> >> >>> >> compiler-generated method calls from e4x 'member
> access')
> >> with
> >> >>> QName
> >> >>> >> argument only. I think most people won't use this
> approach
> >> with
> >> >>> >> explicit
> >> >>> >> QNames, but it is one of those things that will cause
> >> misery
> >> >>> if you do
> >> >>> >> (when porting legacy code), so it should be the same
> IMO
> >> also.
> >> >>> I will
> >> >>> >> make
> >> >>> >> sure it costs nothing for the more common (other) use
> >> cases.
> >> I
> >> >>> have
> >> >>> >> had to
> >> >>> >> do something similar to support 'use namespace'
> directives
> >> >>> which
> >> >>> >> create a
> >> >>> >> MultiName-like variant of QName in my local change
> that
> >> >>> includes the
> >> >>> >> default namespace and the specified set of other
> >> 'used'/open
> >> >>> >> namespace uris
> >> >>> >> in the current execution scope. (That 'use namespace'
> >> pattern
> >> >>> was
> >> >>> >> being
> >> >>> >> used quite a bit in the codebase I have been working
> on)
> >> >>> >>
> >> >>> >> Thanks again, that will save me investigating it with
> >> bytecode.
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui
> >> >>> <ah...@adobe.com.invalid>
> >> >>> >> wrote:
> >> >>> >>
> >> >>> >> > Out of pure random chance, I was starting the
> migration
> >> of
> >> >>> >> WebService
> >> >>> >> > which had a dependency on XMLUtil which contained
> the
> >> >>> comment:
> >> >>> >> >
> >> >>> >> > //xml.attribute(QName) will also return
> local
> >> >>> no-namespace
> >> >>> >> > attributes
> >> >>> >> > //even if we are looking for a specific
> full
> >> >>> qualified name.
> >> >>> >> >
> >> >>> >> > So, still could be a bug in Flash, but maybe we
> should
> >> just
> >> >>> make our
> >> >>> >> > implementation work the same way to reduce
> migration
> >> effort
> >> >>> in case
> >> >>> >> someone
> >> >>> >> > is relying on this behavior.
> >> >>> >> >
> >> >>> >> > Thoughts?
> >> >>> >> > -Alex
> >> >>> >> >
> >> >>> >> > On 9/4/19, 1:47 PM, "Alex Harui"
> >> <ah...@adobe.com.INVALID>
> >> >>> wrote:
> >> >>> >> >
> >> >>> >> > I read the example incorrectly. So yeah, it
> should
> >> >>> return 0
> >> >>> >> and empty
> >> >>> >> > string in both cases, IMO. There might be some
> subtlety
> >> in
> >> >>> how the
> >> >>> >> > namespaces are specified for a QName or how QName
> works
> >> in
> >> >>> child().
> >> >>> >> >
> >> >>> >> > HTH,
> >> >>> >> > -Alex
> >> >>> >> >
> >> >>> >> > On 9/4/19, 11:33 AM, "Greg Dove" <
> >> greg.dove@gmail.com>
> >> >>> wrote:
> >> >>> >> >
> >> >>> >> > Good idea. I'll check the swf output,
> although
> >> >>> probably
> >> >>> >> tomorrow
> >> >>> >> > as I need
> >> >>> >> > to focus on something else today.
> >> >>> >> > ' I would have expected both to return "1"
> and
> >> the
> >> >>> node. '
> >> >>> >> >
> >> >>> >> > In that example I would expect the opposite
> >> (because
> >> >>> the
> >> >>> >> the link
> >> >>> >> > node
> >> >>> >> > being returned by the second query is not
> in the
> >> >>> specified
> >> >>> >> explicit
> >> >>> >> > namespace of the QName), so I am curious to
> >> >>> understand why
> >> >>> >> you
> >> >>> >> > think
> >> >>> >> > that... maybe it will help me understand.
> >> >>> >> >
> >> >>> >> > When I use feed.atom::link I expect only
> links
> >> that
> >> >>> are
> >> >>> >> bound to
> >> >>> >> > the atom
> >> >>> >> > namespace (uri). Because <link ... /> node
> has no
> >> >>> prefix
> >> >>> >> bound to
> >> >>> >> > the uri
> >> >>> >> > that the atom namespace defines, and it is
> in the
> >> >>> default
> >> >>> >> > namespace, I
> >> >>> >> > would not expect it to be included.
> >> >>> >> > At the moment the atom::link part is
> working the
> >> >>> same as
> >> >>> >> swf, so
> >> >>> >> > I'm happy
> >> >>> >> > with that at least for what I am working
> on. All
> >> the
> >> >>> >> explicit
> >> >>> >> > calls to
> >> >>> >> > child(name) or descendants(name) in the
> app I am
> >> >>> working on
> >> >>> >> use
> >> >>> >> > string args
> >> >>> >> > so these all work correctly as well.
> >> >>> >> > I'm just trying to cover things for the
> future...
> >> >>> while my
> >> >>> >> head is
> >> >>> >> > still in
> >> >>> >> > this stuff.
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
> >> >>> >> <ah...@adobe.com.invalid>
> >> >>> >> > wrote:
> >> >>> >> >
> >> >>> >> > > Speaking of multinames, what is the ABC
> code
> >> >>> generated by
> >> >>> >> the
> >> >>> >> > Flex
> >> >>> >> > > compiler for the two cases? It might
> contain
> >> some
> >> >>> >> clues. I
> >> >>> >> > would have
> >> >>> >> > > expected both to return "1" and the
> node. But
> >> I
> >> >>> did see
> >> >>> >> in the
> >> >>> >> > spec the
> >> >>> >> > > notion of "InScopeNamespaces". I
> generally
> >> hate
> >> >>> reading
> >> >>> >> specs
> >> >>> >> > like these
> >> >>> >> > > so I am not very knowledgeable about
> what the
> >> spec
> >> >>> says.
> >> >>> >> > >
> >> >>> >> > > HTH,
> >> >>> >> > > -Alex
> >> >>> >> > >
> >> >>> >> > > On 9/4/19, 11:05 AM, "Greg Dove" <
> >> >>> greg.dove@gmail.com>
> >> >>> >> wrote:
> >> >>> >> > >
> >> >>> >> > > 'Have you rummaged through the spec?'
> >> >>> >> > > Yes, if anything I probably need to
> step
> >> away
> >> >>> from it
> >> >>> >> and
> >> >>> >> > experience
> >> >>> >> > > the
> >> >>> >> > > world a bit more! I have been
> focused on
> >> each
> >> >>> portion
> >> >>> >> of the
> >> >>> >> > spec as I
> >> >>> >> > > create unit tests and verify things
> between
> >> the
> >> >>> >> player and
> >> >>> >> > the Royale
> >> >>> >> > > implementation.
> >> >>> >> > > I've also glanced a few times in the
> >> avmplus
> >> >>> code,
> >> >>> >> and that
> >> >>> >> > has
> >> >>> >> > > provided
> >> >>> >> > > some clues where things were
> intentionally
> >> >>> implemented
> >> >>> >> > slightly off
> >> >>> >> > > spec,
> >> >>> >> > > but still a few things to figure out.
> >> However
> >> >>> I am
> >> >>> >> making
> >> >>> >> > progress - I
> >> >>> >> > > think I have everything covered for
> the
> >> >>> codebase I am
> >> >>> >> > working on....
> >> >>> >> > > but I
> >> >>> >> > > will keep going beyond that. For that
> >> example
> >> >>> above,
> >> >>> >> I might
> >> >>> >> > be wrong,
> >> >>> >> > > but
> >> >>> >> > > I suspect it is using a multiname
> with
> >> default
> >> >>> >> namespace
> >> >>> >> > included for
> >> >>> >> > > the
> >> >>> >> > > explicit call case in the player,
> but not
> >> for
> >> >>> the
> >> >>> >> implicit
> >> >>> >> > one, but I
> >> >>> >> > > am
> >> >>> >> > > not yet sure why. I will
> double-check the
> >> spec
> >> >>> >> though...
> >> >>> >> > >
> >> >>> >> > >
> >> >>> >> > > On Thu, Sep 5, 2019 at 4:02 AM Alex
> Harui
> >> >>> >> > <ah...@adobe.com.invalid>
> >> >>> >> > > wrote:
> >> >>> >> > >
> >> >>> >> > > > Don't know. Have you rummaged
> through
> >> the
> >> >>> spec?
> >> >>> >> > > >
> >> >>> >> > > >
> >> >>> >> > >
> >> >>> >> >
> >> >>> >>
> >> >>>
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C3438477ce0cc42e9154208d735b4515c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036920920719112&sdata=rO%2BpRB0FbWrY0ALzz7dlxvjxvklA72KBA9srZSE%2BIgw%3D&reserved=0
> >> >>> >> > > >
> >> >>> >> > > > HTH,
> >> >>> >> > > > -Alex
> >> >>> >> > > >
> >> >>> >> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
> >> >>> >> greg.dove@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%7C3438477ce0cc42e9154208d735b4515c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036920920719112&sdata=PawSy2AXqHXTIb00EbLsdOE9YTNFechQKMNsWk6xAww%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%7C3438477ce0cc42e9154208d735b4515c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036920920719112&sdata=PawSy2AXqHXTIb00EbLsdOE9YTNFechQKMNsWk6xAww%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%7C3438477ce0cc42e9154208d735b4515c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036920920729107&sdata=LYFvkFaqzATs%2FkUsU9g9RrTMmUbt948LTEMGR5ZzYv8%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.
> >> >>> >> > > >
> >> >>> >> > > >
> >> >>> >> > > >
> >> >>> >> > >
> >> >>> >> > >
> >> >>> >> > >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>>
> >> >>>
> >> >>>
> >> >
> >>
> >> --
> >> --
> >> Josh Tynjala
> >> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C3438477ce0cc42e9154208d735b4515c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036920920729107&sdata=pIUmsalk9pK%2F0Egn7ZGNFx86IuLLpcmIYr2mx%2BRKFKY%3D&reserved=0
> >
> >>
> >
>
>
>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
And... I'm still going. I keep finding things that need addressing. I am in
attributes now.
Anyway, I haven't gotten to the memory testing yet and I need to focus
tomorrow on showing my client progress, so I'm sorry but this code will be
another couple of days.
If you do look into the as2 XMLDocument stuff and find issues with
emulating that in Royale XML, feel free to ask me about anything that might
be changing (to match what swf does). Otherwise it might be easier to wait
and see if you really need some of those fixes. Once again, sorry for the
delay. I prefer to get what I get in 'right' rather than have only some of
it right.
On Mon, Sep 9, 2019 at 5:33 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> No problem. I've spent today trying to fix the build in the Ant source
> package.
>
> -Alex
>
> On 9/8/19, 10:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Not quite there yet with the final changes, I'm afraid. I'm getting
> close... should be tomorrow my time.
>
>
> On Sun, Sep 8, 2019 at 7:32 AM Greg Dove <gr...@gmail.com> wrote:
>
> >
> > Yeah thanks Josh, Alex made a suggestion for that option too, it was
> the
> > one I thought I would try first. I hope to get there later today, so
> I will
> > see if I can figure that out.
> >
> >
> > On Sun, Sep 8, 2019 at 7:20 AM Josh Tynjala <
> joshtynjala@bowlerhat.dev>
> > wrote:
> >
> >> I think the DITA files generated by asdoc are pretty big too, so
> they're
> >> probably really useful for your testing.
> >>
> >> - Josh
> >>
> >> On Friday, September 6, 2019, Greg Dove <gr...@gmail.com>
> wrote:
> >> > 'I think that SWFDump will generate valid XML and there is a way
> to get
> >> > DITA files from Flex ASDoc that are valid XML.'
> >> > Sounds like a good idea for some large xml files. I did not use
> that
> >> yet,
> >> > so will take a look and see if I can figure it out. Thanks!
> >> >
> >> >
> >> > On Sat, Sep 7, 2019 at 12:30 PM Greg Dove <gr...@gmail.com>
> wrote:
> >> >
> >> >>
> >> >> Just to clarify.... I was referring to this stuff here:
> >> >>
> >> >>
> >> >>
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2F8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab%2Fframeworks%2Fprojects%2FMXRoyale%2Fsrc%2Fmain%2Froyale%2Fmx%2Frpc%2Fhttp%2FAbstractOperation.as%23L1038&data=02%7C01%7Caharui%40adobe.com%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036021948216407&sdata=7V0k6g15%2FwI2JY7v7E32iLjX6lIUSkOs9%2BpRDfhOrGI%3D&reserved=0
> >> >>
> >> >>
> >> >> with '//old XML style'
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui
> <ah...@adobe.com.invalid>
> >> >> wrote:
> >> >>
> >> >>> I haven't looked at what XML is used/supported by MX
> HTTPService. It
> >> >>> looks like WebService does use MX HTTPService. I am currently
> >> migrating
> >> >>> other things that WebService needs (XMLEncoder/Decoder,
> >> >>> SOAPEncoder/Decoder). These are new files that aren't in the
> repo
> >> yet,
> >> so
> >> >>> HTTPService couldn't be relying on them or else their use is
> commented
> >> >>> out. The goal is to change as little as possible to get it to
> >> compile
> >> and
> >> >>> then see if it runs. I have no idea yet if the XML
> improvements you
> >> are
> >> >>> working on are going to be impactful on what I'm doing or not.
> >> >>>
> >> >>> BTW, I could be wrong, but I think that SWFDump will generate
> valid
> >> XML
> >> >>> and there is a way to get DITA files from Flex ASDoc that are
> valid
> >> XML.
> >> >>>
> >> >>> Thanks for the heads up,
> >> >>> -Alex
> >> >>>
> >> >>> On 9/6/19, 5:14 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >> >>>
> >> >>> Actually I know you are looking into the WSDL stuff....
> maybe this
> >> is
> >> >>> going
> >> >>> to be important for that (not sure)?
> >> >>> My goal is to get the XML stuff tidied up and ready to push
> by end
> >> of
> >> >>> day
> >> >>> tomorrow, worst case the following morning, local time
> (UTC+12). I
> >> >>> also
> >> >>> need to find some big XML test cases to check the memory
> side of
> >> >>> things.
> >> >>> FYI there is also some XMLDocument stuff missing (commented
> out)
> >> from
> >> >>> some
> >> >>> of the MX HttpService code, which came up in a recent
> issue. I
> >> don't
> >> >>> know
> >> >>> if it shares any of the code from the WSDL stuff you are
> looking
> >> at
> >> or
> >> >>> not...
> >> >>> If it does then I don't want to double up on things, but
> >> otherwise I
> >> >>> will
> >> >>> try to look at that on my Monday.
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <
> greg.dove@gmail.com>
> >> >>> wrote:
> >> >>>
> >> >>> > Thanks for checking that.
> >> >>> >
> >> >>> > child is specified in 13.4.4.6 and essentially calls
> [[Get]]
> >> >>> > (After cycling through this kind of thing a few times, I
> found
> >> the
> >> >>> easiest
> >> >>> > way to find methods is to search in the spec for
> 'e.mehodName'
> >> >>> which gets
> >> >>> > you XML.prototype.methodName)
> >> >>> >
> >> >>> > and [[Get]] is specified in 9.1.1.1
> >> >>> >
> >> >>> > So I assume it is a bug. As discussed I think it is good
> to
> >> match
> >> >>> the
> >> >>> > behavior. If we can verify 100% it is off spec, we could
> add
> >> >>> something as a
> >> >>> > define to avoid the 'fix' for people who want to be
> on-spec.
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui
> >> <aharui@adobe.com.invalid
> >> >>> >
> >> >>> > wrote:
> >> >>> >
> >> >>> >> FWIW, I went and looked at the ABC.
> >> >>> >>
> >> >>> >> The first syntax sets up a getProperty just like any
> other
> >> property
> >> >>> >> fetch. The second (as expected) calls "child()". I've
> looked
> >> at
> >> >>> the E4X
> >> >>> >> spec a couple of times now and cannot see where the
> behavior we
> >> >>> are seeing
> >> >>> >> in child() is specified so I am going to assume it is a
> bug,
> >> and
> >> >>> that we
> >> >>> >> just have to live with it.
> >> >>> >>
> >> >>> >> I expect that getProperty does not call child(). I
> haven't
> >> looked
> >> >>> at the
> >> >>> >> AVM code to see what getProperty does for XML.
> >> >>> >>
> >> >>> >> HTH,
> >> >>> >> -Alex
> >> >>> >>
> >> >>> >> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com>
> wrote:
> >> >>> >>
> >> >>> >> Oh that is a good find! And perfect timing :)
> >> >>> >> Thanks Alex, I am pretty sure that answers the
> question!
> >> (It
> >> >>> quite
> >> >>> >> specifically describes what I was seeing, I don't
> think it
> >> >>> makes a
> >> >>> >> difference whether it is attributes or elements)
> >> >>> >>
> >> >>> >> And yes, I agree it should be the implemented to
> give the
> >> same
> >> >>> >> results as
> >> >>> >> swf.
> >> >>> >> I will add this to the other work I have over the
> weekend
> >> >>> before I
> >> >>> >> get it
> >> >>> >> in. It only seems relevant for when child (or
> descendants,
> >> I
> >> >>> don't
> >> >>> >> expect
> >> >>> >> that will be different) method call is explicit (as
> opposed
> >> to
> >> >>> the
> >> >>> >> compiler-generated method calls from e4x 'member
> access')
> >> with
> >> >>> QName
> >> >>> >> argument only. I think most people won't use this
> approach
> >> with
> >> >>> >> explicit
> >> >>> >> QNames, but it is one of those things that will cause
> >> misery
> >> >>> if you do
> >> >>> >> (when porting legacy code), so it should be the same
> IMO
> >> also.
> >> >>> I will
> >> >>> >> make
> >> >>> >> sure it costs nothing for the more common (other) use
> >> cases.
> >> I
> >> >>> have
> >> >>> >> had to
> >> >>> >> do something similar to support 'use namespace'
> directives
> >> >>> which
> >> >>> >> create a
> >> >>> >> MultiName-like variant of QName in my local change
> that
> >> >>> includes the
> >> >>> >> default namespace and the specified set of other
> >> 'used'/open
> >> >>> >> namespace uris
> >> >>> >> in the current execution scope. (That 'use namespace'
> >> pattern
> >> >>> was
> >> >>> >> being
> >> >>> >> used quite a bit in the codebase I have been working
> on)
> >> >>> >>
> >> >>> >> Thanks again, that will save me investigating it with
> >> bytecode.
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui
> >> >>> <ah...@adobe.com.invalid>
> >> >>> >> wrote:
> >> >>> >>
> >> >>> >> > Out of pure random chance, I was starting the
> migration
> >> of
> >> >>> >> WebService
> >> >>> >> > which had a dependency on XMLUtil which contained
> the
> >> >>> comment:
> >> >>> >> >
> >> >>> >> > //xml.attribute(QName) will also return
> local
> >> >>> no-namespace
> >> >>> >> > attributes
> >> >>> >> > //even if we are looking for a specific
> full
> >> >>> qualified name.
> >> >>> >> >
> >> >>> >> > So, still could be a bug in Flash, but maybe we
> should
> >> just
> >> >>> make our
> >> >>> >> > implementation work the same way to reduce
> migration
> >> effort
> >> >>> in case
> >> >>> >> someone
> >> >>> >> > is relying on this behavior.
> >> >>> >> >
> >> >>> >> > Thoughts?
> >> >>> >> > -Alex
> >> >>> >> >
> >> >>> >> > On 9/4/19, 1:47 PM, "Alex Harui"
> >> <ah...@adobe.com.INVALID>
> >> >>> wrote:
> >> >>> >> >
> >> >>> >> > I read the example incorrectly. So yeah, it
> should
> >> >>> return 0
> >> >>> >> and empty
> >> >>> >> > string in both cases, IMO. There might be some
> subtlety
> >> in
> >> >>> how the
> >> >>> >> > namespaces are specified for a QName or how QName
> works
> >> in
> >> >>> child().
> >> >>> >> >
> >> >>> >> > HTH,
> >> >>> >> > -Alex
> >> >>> >> >
> >> >>> >> > On 9/4/19, 11:33 AM, "Greg Dove" <
> >> greg.dove@gmail.com>
> >> >>> wrote:
> >> >>> >> >
> >> >>> >> > Good idea. I'll check the swf output,
> although
> >> >>> probably
> >> >>> >> tomorrow
> >> >>> >> > as I need
> >> >>> >> > to focus on something else today.
> >> >>> >> > ' I would have expected both to return "1"
> and
> >> the
> >> >>> node. '
> >> >>> >> >
> >> >>> >> > In that example I would expect the opposite
> >> (because
> >> >>> the
> >> >>> >> the link
> >> >>> >> > node
> >> >>> >> > being returned by the second query is not
> in the
> >> >>> specified
> >> >>> >> explicit
> >> >>> >> > namespace of the QName), so I am curious to
> >> >>> understand why
> >> >>> >> you
> >> >>> >> > think
> >> >>> >> > that... maybe it will help me understand.
> >> >>> >> >
> >> >>> >> > When I use feed.atom::link I expect only
> links
> >> that
> >> >>> are
> >> >>> >> bound to
> >> >>> >> > the atom
> >> >>> >> > namespace (uri). Because <link ... /> node
> has no
> >> >>> prefix
> >> >>> >> bound to
> >> >>> >> > the uri
> >> >>> >> > that the atom namespace defines, and it is
> in the
> >> >>> default
> >> >>> >> > namespace, I
> >> >>> >> > would not expect it to be included.
> >> >>> >> > At the moment the atom::link part is
> working the
> >> >>> same as
> >> >>> >> swf, so
> >> >>> >> > I'm happy
> >> >>> >> > with that at least for what I am working
> on. All
> >> the
> >> >>> >> explicit
> >> >>> >> > calls to
> >> >>> >> > child(name) or descendants(name) in the
> app I am
> >> >>> working on
> >> >>> >> use
> >> >>> >> > string args
> >> >>> >> > so these all work correctly as well.
> >> >>> >> > I'm just trying to cover things for the
> future...
> >> >>> while my
> >> >>> >> head is
> >> >>> >> > still in
> >> >>> >> > this stuff.
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
> >> >>> >> <ah...@adobe.com.invalid>
> >> >>> >> > wrote:
> >> >>> >> >
> >> >>> >> > > Speaking of multinames, what is the ABC
> code
> >> >>> generated by
> >> >>> >> the
> >> >>> >> > Flex
> >> >>> >> > > compiler for the two cases? It might
> contain
> >> some
> >> >>> >> clues. I
> >> >>> >> > would have
> >> >>> >> > > expected both to return "1" and the
> node. But
> >> I
> >> >>> did see
> >> >>> >> in the
> >> >>> >> > spec the
> >> >>> >> > > notion of "InScopeNamespaces". I
> generally
> >> hate
> >> >>> reading
> >> >>> >> specs
> >> >>> >> > like these
> >> >>> >> > > so I am not very knowledgeable about
> what the
> >> spec
> >> >>> says.
> >> >>> >> > >
> >> >>> >> > > HTH,
> >> >>> >> > > -Alex
> >> >>> >> > >
> >> >>> >> > > On 9/4/19, 11:05 AM, "Greg Dove" <
> >> >>> greg.dove@gmail.com>
> >> >>> >> wrote:
> >> >>> >> > >
> >> >>> >> > > 'Have you rummaged through the spec?'
> >> >>> >> > > Yes, if anything I probably need to
> step
> >> away
> >> >>> from it
> >> >>> >> and
> >> >>> >> > experience
> >> >>> >> > > the
> >> >>> >> > > world a bit more! I have been
> focused on
> >> each
> >> >>> portion
> >> >>> >> of the
> >> >>> >> > spec as I
> >> >>> >> > > create unit tests and verify things
> between
> >> the
> >> >>> >> player and
> >> >>> >> > the Royale
> >> >>> >> > > implementation.
> >> >>> >> > > I've also glanced a few times in the
> >> avmplus
> >> >>> code,
> >> >>> >> and that
> >> >>> >> > has
> >> >>> >> > > provided
> >> >>> >> > > some clues where things were
> intentionally
> >> >>> implemented
> >> >>> >> > slightly off
> >> >>> >> > > spec,
> >> >>> >> > > but still a few things to figure out.
> >> However
> >> >>> I am
> >> >>> >> making
> >> >>> >> > progress - I
> >> >>> >> > > think I have everything covered for
> the
> >> >>> codebase I am
> >> >>> >> > working on....
> >> >>> >> > > but I
> >> >>> >> > > will keep going beyond that. For that
> >> example
> >> >>> above,
> >> >>> >> I might
> >> >>> >> > be wrong,
> >> >>> >> > > but
> >> >>> >> > > I suspect it is using a multiname
> with
> >> default
> >> >>> >> namespace
> >> >>> >> > included for
> >> >>> >> > > the
> >> >>> >> > > explicit call case in the player,
> but not
> >> for
> >> >>> the
> >> >>> >> implicit
> >> >>> >> > one, but I
> >> >>> >> > > am
> >> >>> >> > > not yet sure why. I will
> double-check the
> >> spec
> >> >>> >> though...
> >> >>> >> > >
> >> >>> >> > >
> >> >>> >> > > On Thu, Sep 5, 2019 at 4:02 AM Alex
> Harui
> >> >>> >> > <ah...@adobe.com.invalid>
> >> >>> >> > > wrote:
> >> >>> >> > >
> >> >>> >> > > > Don't know. Have you rummaged
> through
> >> the
> >> >>> spec?
> >> >>> >> > > >
> >> >>> >> > > >
> >> >>> >> > >
> >> >>> >> >
> >> >>> >>
> >> >>>
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036021948216407&sdata=QYzb6f7nFoHlcmBuhWdsCW0PQY1JjEPAQAYZ%2FidI5Ys%3D&reserved=0
> >> >>> >> > > >
> >> >>> >> > > > HTH,
> >> >>> >> > > > -Alex
> >> >>> >> > > >
> >> >>> >> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
> >> >>> >> greg.dove@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%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036021948216407&sdata=X9r%2BkLD01gmHLU0sud1HN2IkHM8HZFLYFuIM5L%2FBDow%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%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036021948216407&sdata=X9r%2BkLD01gmHLU0sud1HN2IkHM8HZFLYFuIM5L%2FBDow%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%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036021948216407&sdata=X9r%2BkLD01gmHLU0sud1HN2IkHM8HZFLYFuIM5L%2FBDow%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.
> >> >>> >> > > >
> >> >>> >> > > >
> >> >>> >> > > >
> >> >>> >> > >
> >> >>> >> > >
> >> >>> >> > >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>>
> >> >>>
> >> >>>
> >> >
> >>
> >> --
> >> --
> >> Josh Tynjala
> >> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036021948216407&sdata=HJFY93gHQ4aSQP6%2BPL5ZlX4icGqdKngx7bLA1cTp9zI%3D&reserved=0
> >
> >>
> >
>
>
>
Re: Heads up on XML
Posted by Alex Harui <ah...@adobe.com.INVALID>.
No problem. I've spent today trying to fix the build in the Ant source package.
-Alex
On 9/8/19, 10:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
Not quite there yet with the final changes, I'm afraid. I'm getting
close... should be tomorrow my time.
On Sun, Sep 8, 2019 at 7:32 AM Greg Dove <gr...@gmail.com> wrote:
>
> Yeah thanks Josh, Alex made a suggestion for that option too, it was the
> one I thought I would try first. I hope to get there later today, so I will
> see if I can figure that out.
>
>
> On Sun, Sep 8, 2019 at 7:20 AM Josh Tynjala <jo...@bowlerhat.dev>
> wrote:
>
>> I think the DITA files generated by asdoc are pretty big too, so they're
>> probably really useful for your testing.
>>
>> - Josh
>>
>> On Friday, September 6, 2019, Greg Dove <gr...@gmail.com> wrote:
>> > 'I think that SWFDump will generate valid XML and there is a way to get
>> > DITA files from Flex ASDoc that are valid XML.'
>> > Sounds like a good idea for some large xml files. I did not use that
>> yet,
>> > so will take a look and see if I can figure it out. Thanks!
>> >
>> >
>> > On Sat, Sep 7, 2019 at 12:30 PM Greg Dove <gr...@gmail.com> wrote:
>> >
>> >>
>> >> Just to clarify.... I was referring to this stuff here:
>> >>
>> >>
>> >>
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2F8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab%2Fframeworks%2Fprojects%2FMXRoyale%2Fsrc%2Fmain%2Froyale%2Fmx%2Frpc%2Fhttp%2FAbstractOperation.as%23L1038&data=02%7C01%7Caharui%40adobe.com%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036021948216407&sdata=7V0k6g15%2FwI2JY7v7E32iLjX6lIUSkOs9%2BpRDfhOrGI%3D&reserved=0
>> >>
>> >>
>> >> with '//old XML style'
>> >>
>> >>
>> >>
>> >>
>> >> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui <ah...@adobe.com.invalid>
>> >> wrote:
>> >>
>> >>> I haven't looked at what XML is used/supported by MX HTTPService. It
>> >>> looks like WebService does use MX HTTPService. I am currently
>> migrating
>> >>> other things that WebService needs (XMLEncoder/Decoder,
>> >>> SOAPEncoder/Decoder). These are new files that aren't in the repo
>> yet,
>> so
>> >>> HTTPService couldn't be relying on them or else their use is commented
>> >>> out. The goal is to change as little as possible to get it to
>> compile
>> and
>> >>> then see if it runs. I have no idea yet if the XML improvements you
>> are
>> >>> working on are going to be impactful on what I'm doing or not.
>> >>>
>> >>> BTW, I could be wrong, but I think that SWFDump will generate valid
>> XML
>> >>> and there is a way to get DITA files from Flex ASDoc that are valid
>> XML.
>> >>>
>> >>> Thanks for the heads up,
>> >>> -Alex
>> >>>
>> >>> On 9/6/19, 5:14 PM, "Greg Dove" <gr...@gmail.com> wrote:
>> >>>
>> >>> Actually I know you are looking into the WSDL stuff.... maybe this
>> is
>> >>> going
>> >>> to be important for that (not sure)?
>> >>> My goal is to get the XML stuff tidied up and ready to push by end
>> of
>> >>> day
>> >>> tomorrow, worst case the following morning, local time (UTC+12). I
>> >>> also
>> >>> need to find some big XML test cases to check the memory side of
>> >>> things.
>> >>> FYI there is also some XMLDocument stuff missing (commented out)
>> from
>> >>> some
>> >>> of the MX HttpService code, which came up in a recent issue. I
>> don't
>> >>> know
>> >>> if it shares any of the code from the WSDL stuff you are looking
>> at
>> or
>> >>> not...
>> >>> If it does then I don't want to double up on things, but
>> otherwise I
>> >>> will
>> >>> try to look at that on my Monday.
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <gr...@gmail.com>
>> >>> wrote:
>> >>>
>> >>> > Thanks for checking that.
>> >>> >
>> >>> > child is specified in 13.4.4.6 and essentially calls [[Get]]
>> >>> > (After cycling through this kind of thing a few times, I found
>> the
>> >>> easiest
>> >>> > way to find methods is to search in the spec for 'e.mehodName'
>> >>> which gets
>> >>> > you XML.prototype.methodName)
>> >>> >
>> >>> > and [[Get]] is specified in 9.1.1.1
>> >>> >
>> >>> > So I assume it is a bug. As discussed I think it is good to
>> match
>> >>> the
>> >>> > behavior. If we can verify 100% it is off spec, we could add
>> >>> something as a
>> >>> > define to avoid the 'fix' for people who want to be on-spec.
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui
>> <aharui@adobe.com.invalid
>> >>> >
>> >>> > wrote:
>> >>> >
>> >>> >> FWIW, I went and looked at the ABC.
>> >>> >>
>> >>> >> The first syntax sets up a getProperty just like any other
>> property
>> >>> >> fetch. The second (as expected) calls "child()". I've looked
>> at
>> >>> the E4X
>> >>> >> spec a couple of times now and cannot see where the behavior we
>> >>> are seeing
>> >>> >> in child() is specified so I am going to assume it is a bug,
>> and
>> >>> that we
>> >>> >> just have to live with it.
>> >>> >>
>> >>> >> I expect that getProperty does not call child(). I haven't
>> looked
>> >>> at the
>> >>> >> AVM code to see what getProperty does for XML.
>> >>> >>
>> >>> >> HTH,
>> >>> >> -Alex
>> >>> >>
>> >>> >> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
>> >>> >>
>> >>> >> Oh that is a good find! And perfect timing :)
>> >>> >> Thanks Alex, I am pretty sure that answers the question!
>> (It
>> >>> quite
>> >>> >> specifically describes what I was seeing, I don't think it
>> >>> makes a
>> >>> >> difference whether it is attributes or elements)
>> >>> >>
>> >>> >> And yes, I agree it should be the implemented to give the
>> same
>> >>> >> results as
>> >>> >> swf.
>> >>> >> I will add this to the other work I have over the weekend
>> >>> before I
>> >>> >> get it
>> >>> >> in. It only seems relevant for when child (or descendants,
>> I
>> >>> don't
>> >>> >> expect
>> >>> >> that will be different) method call is explicit (as opposed
>> to
>> >>> the
>> >>> >> compiler-generated method calls from e4x 'member access')
>> with
>> >>> QName
>> >>> >> argument only. I think most people won't use this approach
>> with
>> >>> >> explicit
>> >>> >> QNames, but it is one of those things that will cause
>> misery
>> >>> if you do
>> >>> >> (when porting legacy code), so it should be the same IMO
>> also.
>> >>> I will
>> >>> >> make
>> >>> >> sure it costs nothing for the more common (other) use
>> cases.
>> I
>> >>> have
>> >>> >> had to
>> >>> >> do something similar to support 'use namespace' directives
>> >>> which
>> >>> >> create a
>> >>> >> MultiName-like variant of QName in my local change that
>> >>> includes the
>> >>> >> default namespace and the specified set of other
>> 'used'/open
>> >>> >> namespace uris
>> >>> >> in the current execution scope. (That 'use namespace'
>> pattern
>> >>> was
>> >>> >> being
>> >>> >> used quite a bit in the codebase I have been working on)
>> >>> >>
>> >>> >> Thanks again, that will save me investigating it with
>> bytecode.
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui
>> >>> <ah...@adobe.com.invalid>
>> >>> >> wrote:
>> >>> >>
>> >>> >> > Out of pure random chance, I was starting the migration
>> of
>> >>> >> WebService
>> >>> >> > which had a dependency on XMLUtil which contained the
>> >>> comment:
>> >>> >> >
>> >>> >> > //xml.attribute(QName) will also return local
>> >>> no-namespace
>> >>> >> > attributes
>> >>> >> > //even if we are looking for a specific full
>> >>> qualified name.
>> >>> >> >
>> >>> >> > So, still could be a bug in Flash, but maybe we should
>> just
>> >>> make our
>> >>> >> > implementation work the same way to reduce migration
>> effort
>> >>> in case
>> >>> >> someone
>> >>> >> > is relying on this behavior.
>> >>> >> >
>> >>> >> > Thoughts?
>> >>> >> > -Alex
>> >>> >> >
>> >>> >> > On 9/4/19, 1:47 PM, "Alex Harui"
>> <ah...@adobe.com.INVALID>
>> >>> wrote:
>> >>> >> >
>> >>> >> > I read the example incorrectly. So yeah, it should
>> >>> return 0
>> >>> >> and empty
>> >>> >> > string in both cases, IMO. There might be some subtlety
>> in
>> >>> how the
>> >>> >> > namespaces are specified for a QName or how QName works
>> in
>> >>> child().
>> >>> >> >
>> >>> >> > HTH,
>> >>> >> > -Alex
>> >>> >> >
>> >>> >> > On 9/4/19, 11:33 AM, "Greg Dove" <
>> greg.dove@gmail.com>
>> >>> wrote:
>> >>> >> >
>> >>> >> > Good idea. I'll check the swf output, although
>> >>> probably
>> >>> >> tomorrow
>> >>> >> > as I need
>> >>> >> > to focus on something else today.
>> >>> >> > ' I would have expected both to return "1" and
>> the
>> >>> node. '
>> >>> >> >
>> >>> >> > In that example I would expect the opposite
>> (because
>> >>> the
>> >>> >> the link
>> >>> >> > node
>> >>> >> > being returned by the second query is not in the
>> >>> specified
>> >>> >> explicit
>> >>> >> > namespace of the QName), so I am curious to
>> >>> understand why
>> >>> >> you
>> >>> >> > think
>> >>> >> > that... maybe it will help me understand.
>> >>> >> >
>> >>> >> > When I use feed.atom::link I expect only links
>> that
>> >>> are
>> >>> >> bound to
>> >>> >> > the atom
>> >>> >> > namespace (uri). Because <link ... /> node has no
>> >>> prefix
>> >>> >> bound to
>> >>> >> > the uri
>> >>> >> > that the atom namespace defines, and it is in the
>> >>> default
>> >>> >> > namespace, I
>> >>> >> > would not expect it to be included.
>> >>> >> > At the moment the atom::link part is working the
>> >>> same as
>> >>> >> swf, so
>> >>> >> > I'm happy
>> >>> >> > with that at least for what I am working on. All
>> the
>> >>> >> explicit
>> >>> >> > calls to
>> >>> >> > child(name) or descendants(name) in the app I am
>> >>> working on
>> >>> >> use
>> >>> >> > string args
>> >>> >> > so these all work correctly as well.
>> >>> >> > I'm just trying to cover things for the future...
>> >>> while my
>> >>> >> head is
>> >>> >> > still in
>> >>> >> > this stuff.
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
>> >>> >> <ah...@adobe.com.invalid>
>> >>> >> > wrote:
>> >>> >> >
>> >>> >> > > Speaking of multinames, what is the ABC code
>> >>> generated by
>> >>> >> the
>> >>> >> > Flex
>> >>> >> > > compiler for the two cases? It might contain
>> some
>> >>> >> clues. I
>> >>> >> > would have
>> >>> >> > > expected both to return "1" and the node. But
>> I
>> >>> did see
>> >>> >> in the
>> >>> >> > spec the
>> >>> >> > > notion of "InScopeNamespaces". I generally
>> hate
>> >>> reading
>> >>> >> specs
>> >>> >> > like these
>> >>> >> > > so I am not very knowledgeable about what the
>> spec
>> >>> says.
>> >>> >> > >
>> >>> >> > > HTH,
>> >>> >> > > -Alex
>> >>> >> > >
>> >>> >> > > On 9/4/19, 11:05 AM, "Greg Dove" <
>> >>> greg.dove@gmail.com>
>> >>> >> wrote:
>> >>> >> > >
>> >>> >> > > 'Have you rummaged through the spec?'
>> >>> >> > > Yes, if anything I probably need to step
>> away
>> >>> from it
>> >>> >> and
>> >>> >> > experience
>> >>> >> > > the
>> >>> >> > > world a bit more! I have been focused on
>> each
>> >>> portion
>> >>> >> of the
>> >>> >> > spec as I
>> >>> >> > > create unit tests and verify things between
>> the
>> >>> >> player and
>> >>> >> > the Royale
>> >>> >> > > implementation.
>> >>> >> > > I've also glanced a few times in the
>> avmplus
>> >>> code,
>> >>> >> and that
>> >>> >> > has
>> >>> >> > > provided
>> >>> >> > > some clues where things were intentionally
>> >>> implemented
>> >>> >> > slightly off
>> >>> >> > > spec,
>> >>> >> > > but still a few things to figure out.
>> However
>> >>> I am
>> >>> >> making
>> >>> >> > progress - I
>> >>> >> > > think I have everything covered for the
>> >>> codebase I am
>> >>> >> > working on....
>> >>> >> > > but I
>> >>> >> > > will keep going beyond that. For that
>> example
>> >>> above,
>> >>> >> I might
>> >>> >> > be wrong,
>> >>> >> > > but
>> >>> >> > > I suspect it is using a multiname with
>> default
>> >>> >> namespace
>> >>> >> > included for
>> >>> >> > > the
>> >>> >> > > explicit call case in the player, but not
>> for
>> >>> the
>> >>> >> implicit
>> >>> >> > one, but I
>> >>> >> > > am
>> >>> >> > > not yet sure why. I will double-check the
>> spec
>> >>> >> though...
>> >>> >> > >
>> >>> >> > >
>> >>> >> > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
>> >>> >> > <ah...@adobe.com.invalid>
>> >>> >> > > wrote:
>> >>> >> > >
>> >>> >> > > > Don't know. Have you rummaged through
>> the
>> >>> spec?
>> >>> >> > > >
>> >>> >> > > >
>> >>> >> > >
>> >>> >> >
>> >>> >>
>> >>>
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036021948216407&sdata=QYzb6f7nFoHlcmBuhWdsCW0PQY1JjEPAQAYZ%2FidI5Ys%3D&reserved=0
>> >>> >> > > >
>> >>> >> > > > HTH,
>> >>> >> > > > -Alex
>> >>> >> > > >
>> >>> >> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
>> >>> >> greg.dove@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%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036021948216407&sdata=X9r%2BkLD01gmHLU0sud1HN2IkHM8HZFLYFuIM5L%2FBDow%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%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036021948216407&sdata=X9r%2BkLD01gmHLU0sud1HN2IkHM8HZFLYFuIM5L%2FBDow%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%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036021948216407&sdata=X9r%2BkLD01gmHLU0sud1HN2IkHM8HZFLYFuIM5L%2FBDow%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.
>> >>> >> > > >
>> >>> >> > > >
>> >>> >> > > >
>> >>> >> > >
>> >>> >> > >
>> >>> >> > >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >>
>> >>>
>> >>>
>> >>>
>> >
>>
>> --
>> --
>> Josh Tynjala
>> Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036021948216407&sdata=HJFY93gHQ4aSQP6%2BPL5ZlX4icGqdKngx7bLA1cTp9zI%3D&reserved=0>
>>
>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
Not quite there yet with the final changes, I'm afraid. I'm getting
close... should be tomorrow my time.
On Sun, Sep 8, 2019 at 7:32 AM Greg Dove <gr...@gmail.com> wrote:
>
> Yeah thanks Josh, Alex made a suggestion for that option too, it was the
> one I thought I would try first. I hope to get there later today, so I will
> see if I can figure that out.
>
>
> On Sun, Sep 8, 2019 at 7:20 AM Josh Tynjala <jo...@bowlerhat.dev>
> wrote:
>
>> I think the DITA files generated by asdoc are pretty big too, so they're
>> probably really useful for your testing.
>>
>> - Josh
>>
>> On Friday, September 6, 2019, Greg Dove <gr...@gmail.com> wrote:
>> > 'I think that SWFDump will generate valid XML and there is a way to get
>> > DITA files from Flex ASDoc that are valid XML.'
>> > Sounds like a good idea for some large xml files. I did not use that
>> yet,
>> > so will take a look and see if I can figure it out. Thanks!
>> >
>> >
>> > On Sat, Sep 7, 2019 at 12:30 PM Greg Dove <gr...@gmail.com> wrote:
>> >
>> >>
>> >> Just to clarify.... I was referring to this stuff here:
>> >>
>> >>
>> >>
>>
>> https://github.com/apache/royale-asjs/blob/8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab/frameworks/projects/MXRoyale/src/main/royale/mx/rpc/http/AbstractOperation.as#L1038
>> >>
>> >>
>> >> with '//old XML style'
>> >>
>> >>
>> >>
>> >>
>> >> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui <ah...@adobe.com.invalid>
>> >> wrote:
>> >>
>> >>> I haven't looked at what XML is used/supported by MX HTTPService. It
>> >>> looks like WebService does use MX HTTPService. I am currently
>> migrating
>> >>> other things that WebService needs (XMLEncoder/Decoder,
>> >>> SOAPEncoder/Decoder). These are new files that aren't in the repo
>> yet,
>> so
>> >>> HTTPService couldn't be relying on them or else their use is commented
>> >>> out. The goal is to change as little as possible to get it to
>> compile
>> and
>> >>> then see if it runs. I have no idea yet if the XML improvements you
>> are
>> >>> working on are going to be impactful on what I'm doing or not.
>> >>>
>> >>> BTW, I could be wrong, but I think that SWFDump will generate valid
>> XML
>> >>> and there is a way to get DITA files from Flex ASDoc that are valid
>> XML.
>> >>>
>> >>> Thanks for the heads up,
>> >>> -Alex
>> >>>
>> >>> On 9/6/19, 5:14 PM, "Greg Dove" <gr...@gmail.com> wrote:
>> >>>
>> >>> Actually I know you are looking into the WSDL stuff.... maybe this
>> is
>> >>> going
>> >>> to be important for that (not sure)?
>> >>> My goal is to get the XML stuff tidied up and ready to push by end
>> of
>> >>> day
>> >>> tomorrow, worst case the following morning, local time (UTC+12). I
>> >>> also
>> >>> need to find some big XML test cases to check the memory side of
>> >>> things.
>> >>> FYI there is also some XMLDocument stuff missing (commented out)
>> from
>> >>> some
>> >>> of the MX HttpService code, which came up in a recent issue. I
>> don't
>> >>> know
>> >>> if it shares any of the code from the WSDL stuff you are looking
>> at
>> or
>> >>> not...
>> >>> If it does then I don't want to double up on things, but
>> otherwise I
>> >>> will
>> >>> try to look at that on my Monday.
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <gr...@gmail.com>
>> >>> wrote:
>> >>>
>> >>> > Thanks for checking that.
>> >>> >
>> >>> > child is specified in 13.4.4.6 and essentially calls [[Get]]
>> >>> > (After cycling through this kind of thing a few times, I found
>> the
>> >>> easiest
>> >>> > way to find methods is to search in the spec for 'e.mehodName'
>> >>> which gets
>> >>> > you XML.prototype.methodName)
>> >>> >
>> >>> > and [[Get]] is specified in 9.1.1.1
>> >>> >
>> >>> > So I assume it is a bug. As discussed I think it is good to
>> match
>> >>> the
>> >>> > behavior. If we can verify 100% it is off spec, we could add
>> >>> something as a
>> >>> > define to avoid the 'fix' for people who want to be on-spec.
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui
>> <aharui@adobe.com.invalid
>> >>> >
>> >>> > wrote:
>> >>> >
>> >>> >> FWIW, I went and looked at the ABC.
>> >>> >>
>> >>> >> The first syntax sets up a getProperty just like any other
>> property
>> >>> >> fetch. The second (as expected) calls "child()". I've looked
>> at
>> >>> the E4X
>> >>> >> spec a couple of times now and cannot see where the behavior we
>> >>> are seeing
>> >>> >> in child() is specified so I am going to assume it is a bug,
>> and
>> >>> that we
>> >>> >> just have to live with it.
>> >>> >>
>> >>> >> I expect that getProperty does not call child(). I haven't
>> looked
>> >>> at the
>> >>> >> AVM code to see what getProperty does for XML.
>> >>> >>
>> >>> >> HTH,
>> >>> >> -Alex
>> >>> >>
>> >>> >> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
>> >>> >>
>> >>> >> Oh that is a good find! And perfect timing :)
>> >>> >> Thanks Alex, I am pretty sure that answers the question!
>> (It
>> >>> quite
>> >>> >> specifically describes what I was seeing, I don't think it
>> >>> makes a
>> >>> >> difference whether it is attributes or elements)
>> >>> >>
>> >>> >> And yes, I agree it should be the implemented to give the
>> same
>> >>> >> results as
>> >>> >> swf.
>> >>> >> I will add this to the other work I have over the weekend
>> >>> before I
>> >>> >> get it
>> >>> >> in. It only seems relevant for when child (or descendants,
>> I
>> >>> don't
>> >>> >> expect
>> >>> >> that will be different) method call is explicit (as opposed
>> to
>> >>> the
>> >>> >> compiler-generated method calls from e4x 'member access')
>> with
>> >>> QName
>> >>> >> argument only. I think most people won't use this approach
>> with
>> >>> >> explicit
>> >>> >> QNames, but it is one of those things that will cause
>> misery
>> >>> if you do
>> >>> >> (when porting legacy code), so it should be the same IMO
>> also.
>> >>> I will
>> >>> >> make
>> >>> >> sure it costs nothing for the more common (other) use
>> cases.
>> I
>> >>> have
>> >>> >> had to
>> >>> >> do something similar to support 'use namespace' directives
>> >>> which
>> >>> >> create a
>> >>> >> MultiName-like variant of QName in my local change that
>> >>> includes the
>> >>> >> default namespace and the specified set of other
>> 'used'/open
>> >>> >> namespace uris
>> >>> >> in the current execution scope. (That 'use namespace'
>> pattern
>> >>> was
>> >>> >> being
>> >>> >> used quite a bit in the codebase I have been working on)
>> >>> >>
>> >>> >> Thanks again, that will save me investigating it with
>> bytecode.
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui
>> >>> <ah...@adobe.com.invalid>
>> >>> >> wrote:
>> >>> >>
>> >>> >> > Out of pure random chance, I was starting the migration
>> of
>> >>> >> WebService
>> >>> >> > which had a dependency on XMLUtil which contained the
>> >>> comment:
>> >>> >> >
>> >>> >> > //xml.attribute(QName) will also return local
>> >>> no-namespace
>> >>> >> > attributes
>> >>> >> > //even if we are looking for a specific full
>> >>> qualified name.
>> >>> >> >
>> >>> >> > So, still could be a bug in Flash, but maybe we should
>> just
>> >>> make our
>> >>> >> > implementation work the same way to reduce migration
>> effort
>> >>> in case
>> >>> >> someone
>> >>> >> > is relying on this behavior.
>> >>> >> >
>> >>> >> > Thoughts?
>> >>> >> > -Alex
>> >>> >> >
>> >>> >> > On 9/4/19, 1:47 PM, "Alex Harui"
>> <ah...@adobe.com.INVALID>
>> >>> wrote:
>> >>> >> >
>> >>> >> > I read the example incorrectly. So yeah, it should
>> >>> return 0
>> >>> >> and empty
>> >>> >> > string in both cases, IMO. There might be some subtlety
>> in
>> >>> how the
>> >>> >> > namespaces are specified for a QName or how QName works
>> in
>> >>> child().
>> >>> >> >
>> >>> >> > HTH,
>> >>> >> > -Alex
>> >>> >> >
>> >>> >> > On 9/4/19, 11:33 AM, "Greg Dove" <
>> greg.dove@gmail.com>
>> >>> wrote:
>> >>> >> >
>> >>> >> > Good idea. I'll check the swf output, although
>> >>> probably
>> >>> >> tomorrow
>> >>> >> > as I need
>> >>> >> > to focus on something else today.
>> >>> >> > ' I would have expected both to return "1" and
>> the
>> >>> node. '
>> >>> >> >
>> >>> >> > In that example I would expect the opposite
>> (because
>> >>> the
>> >>> >> the link
>> >>> >> > node
>> >>> >> > being returned by the second query is not in the
>> >>> specified
>> >>> >> explicit
>> >>> >> > namespace of the QName), so I am curious to
>> >>> understand why
>> >>> >> you
>> >>> >> > think
>> >>> >> > that... maybe it will help me understand.
>> >>> >> >
>> >>> >> > When I use feed.atom::link I expect only links
>> that
>> >>> are
>> >>> >> bound to
>> >>> >> > the atom
>> >>> >> > namespace (uri). Because <link ... /> node has no
>> >>> prefix
>> >>> >> bound to
>> >>> >> > the uri
>> >>> >> > that the atom namespace defines, and it is in the
>> >>> default
>> >>> >> > namespace, I
>> >>> >> > would not expect it to be included.
>> >>> >> > At the moment the atom::link part is working the
>> >>> same as
>> >>> >> swf, so
>> >>> >> > I'm happy
>> >>> >> > with that at least for what I am working on. All
>> the
>> >>> >> explicit
>> >>> >> > calls to
>> >>> >> > child(name) or descendants(name) in the app I am
>> >>> working on
>> >>> >> use
>> >>> >> > string args
>> >>> >> > so these all work correctly as well.
>> >>> >> > I'm just trying to cover things for the future...
>> >>> while my
>> >>> >> head is
>> >>> >> > still in
>> >>> >> > this stuff.
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
>> >>> >> <ah...@adobe.com.invalid>
>> >>> >> > wrote:
>> >>> >> >
>> >>> >> > > Speaking of multinames, what is the ABC code
>> >>> generated by
>> >>> >> the
>> >>> >> > Flex
>> >>> >> > > compiler for the two cases? It might contain
>> some
>> >>> >> clues. I
>> >>> >> > would have
>> >>> >> > > expected both to return "1" and the node. But
>> I
>> >>> did see
>> >>> >> in the
>> >>> >> > spec the
>> >>> >> > > notion of "InScopeNamespaces". I generally
>> hate
>> >>> reading
>> >>> >> specs
>> >>> >> > like these
>> >>> >> > > so I am not very knowledgeable about what the
>> spec
>> >>> says.
>> >>> >> > >
>> >>> >> > > HTH,
>> >>> >> > > -Alex
>> >>> >> > >
>> >>> >> > > On 9/4/19, 11:05 AM, "Greg Dove" <
>> >>> greg.dove@gmail.com>
>> >>> >> wrote:
>> >>> >> > >
>> >>> >> > > 'Have you rummaged through the spec?'
>> >>> >> > > Yes, if anything I probably need to step
>> away
>> >>> from it
>> >>> >> and
>> >>> >> > experience
>> >>> >> > > the
>> >>> >> > > world a bit more! I have been focused on
>> each
>> >>> portion
>> >>> >> of the
>> >>> >> > spec as I
>> >>> >> > > create unit tests and verify things between
>> the
>> >>> >> player and
>> >>> >> > the Royale
>> >>> >> > > implementation.
>> >>> >> > > I've also glanced a few times in the
>> avmplus
>> >>> code,
>> >>> >> and that
>> >>> >> > has
>> >>> >> > > provided
>> >>> >> > > some clues where things were intentionally
>> >>> implemented
>> >>> >> > slightly off
>> >>> >> > > spec,
>> >>> >> > > but still a few things to figure out.
>> However
>> >>> I am
>> >>> >> making
>> >>> >> > progress - I
>> >>> >> > > think I have everything covered for the
>> >>> codebase I am
>> >>> >> > working on....
>> >>> >> > > but I
>> >>> >> > > will keep going beyond that. For that
>> example
>> >>> above,
>> >>> >> I might
>> >>> >> > be wrong,
>> >>> >> > > but
>> >>> >> > > I suspect it is using a multiname with
>> default
>> >>> >> namespace
>> >>> >> > included for
>> >>> >> > > the
>> >>> >> > > explicit call case in the player, but not
>> for
>> >>> the
>> >>> >> implicit
>> >>> >> > one, but I
>> >>> >> > > am
>> >>> >> > > not yet sure why. I will double-check the
>> spec
>> >>> >> though...
>> >>> >> > >
>> >>> >> > >
>> >>> >> > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
>> >>> >> > <ah...@adobe.com.invalid>
>> >>> >> > > wrote:
>> >>> >> > >
>> >>> >> > > > Don't know. Have you rummaged through
>> the
>> >>> spec?
>> >>> >> > > >
>> >>> >> > > >
>> >>> >> > >
>> >>> >> >
>> >>> >>
>> >>>
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034120784048005&sdata=hDhwbA6IQCFHQ3FQkNoVyaUcdZcxrzQS6ZWpiKrYr38%3D&reserved=0
>> >>> >> > > >
>> >>> >> > > > HTH,
>> >>> >> > > > -Alex
>> >>> >> > > >
>> >>> >> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
>> >>> >> greg.dove@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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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.
>> >>> >> > > >
>> >>> >> > > >
>> >>> >> > > >
>> >>> >> > >
>> >>> >> > >
>> >>> >> > >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >>
>> >>>
>> >>>
>> >>>
>> >
>>
>> --
>> --
>> Josh Tynjala
>> Bowler Hat LLC <https://bowlerhat.dev>
>>
>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
Yeah thanks Josh, Alex made a suggestion for that option too, it was the
one I thought I would try first. I hope to get there later today, so I will
see if I can figure that out.
On Sun, Sep 8, 2019 at 7:20 AM Josh Tynjala <jo...@bowlerhat.dev>
wrote:
> I think the DITA files generated by asdoc are pretty big too, so they're
> probably really useful for your testing.
>
> - Josh
>
> On Friday, September 6, 2019, Greg Dove <gr...@gmail.com> wrote:
> > 'I think that SWFDump will generate valid XML and there is a way to get
> > DITA files from Flex ASDoc that are valid XML.'
> > Sounds like a good idea for some large xml files. I did not use that yet,
> > so will take a look and see if I can figure it out. Thanks!
> >
> >
> > On Sat, Sep 7, 2019 at 12:30 PM Greg Dove <gr...@gmail.com> wrote:
> >
> >>
> >> Just to clarify.... I was referring to this stuff here:
> >>
> >>
> >>
>
> https://github.com/apache/royale-asjs/blob/8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab/frameworks/projects/MXRoyale/src/main/royale/mx/rpc/http/AbstractOperation.as#L1038
> >>
> >>
> >> with '//old XML style'
> >>
> >>
> >>
> >>
> >> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui <ah...@adobe.com.invalid>
> >> wrote:
> >>
> >>> I haven't looked at what XML is used/supported by MX HTTPService. It
> >>> looks like WebService does use MX HTTPService. I am currently
> migrating
> >>> other things that WebService needs (XMLEncoder/Decoder,
> >>> SOAPEncoder/Decoder). These are new files that aren't in the repo yet,
> so
> >>> HTTPService couldn't be relying on them or else their use is commented
> >>> out. The goal is to change as little as possible to get it to compile
> and
> >>> then see if it runs. I have no idea yet if the XML improvements you
> are
> >>> working on are going to be impactful on what I'm doing or not.
> >>>
> >>> BTW, I could be wrong, but I think that SWFDump will generate valid XML
> >>> and there is a way to get DITA files from Flex ASDoc that are valid
> XML.
> >>>
> >>> Thanks for the heads up,
> >>> -Alex
> >>>
> >>> On 9/6/19, 5:14 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >>>
> >>> Actually I know you are looking into the WSDL stuff.... maybe this
> is
> >>> going
> >>> to be important for that (not sure)?
> >>> My goal is to get the XML stuff tidied up and ready to push by end
> of
> >>> day
> >>> tomorrow, worst case the following morning, local time (UTC+12). I
> >>> also
> >>> need to find some big XML test cases to check the memory side of
> >>> things.
> >>> FYI there is also some XMLDocument stuff missing (commented out)
> from
> >>> some
> >>> of the MX HttpService code, which came up in a recent issue. I
> don't
> >>> know
> >>> if it shares any of the code from the WSDL stuff you are looking at
> or
> >>> not...
> >>> If it does then I don't want to double up on things, but otherwise
> I
> >>> will
> >>> try to look at that on my Monday.
> >>>
> >>>
> >>>
> >>> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <gr...@gmail.com>
> >>> wrote:
> >>>
> >>> > Thanks for checking that.
> >>> >
> >>> > child is specified in 13.4.4.6 and essentially calls [[Get]]
> >>> > (After cycling through this kind of thing a few times, I found
> the
> >>> easiest
> >>> > way to find methods is to search in the spec for 'e.mehodName'
> >>> which gets
> >>> > you XML.prototype.methodName)
> >>> >
> >>> > and [[Get]] is specified in 9.1.1.1
> >>> >
> >>> > So I assume it is a bug. As discussed I think it is good to match
> >>> the
> >>> > behavior. If we can verify 100% it is off spec, we could add
> >>> something as a
> >>> > define to avoid the 'fix' for people who want to be on-spec.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui
> <aharui@adobe.com.invalid
> >>> >
> >>> > wrote:
> >>> >
> >>> >> FWIW, I went and looked at the ABC.
> >>> >>
> >>> >> The first syntax sets up a getProperty just like any other
> property
> >>> >> fetch. The second (as expected) calls "child()". I've looked
> at
> >>> the E4X
> >>> >> spec a couple of times now and cannot see where the behavior we
> >>> are seeing
> >>> >> in child() is specified so I am going to assume it is a bug, and
> >>> that we
> >>> >> just have to live with it.
> >>> >>
> >>> >> I expect that getProperty does not call child(). I haven't
> looked
> >>> at the
> >>> >> AVM code to see what getProperty does for XML.
> >>> >>
> >>> >> HTH,
> >>> >> -Alex
> >>> >>
> >>> >> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >>> >>
> >>> >> Oh that is a good find! And perfect timing :)
> >>> >> Thanks Alex, I am pretty sure that answers the question! (It
> >>> quite
> >>> >> specifically describes what I was seeing, I don't think it
> >>> makes a
> >>> >> difference whether it is attributes or elements)
> >>> >>
> >>> >> And yes, I agree it should be the implemented to give the
> same
> >>> >> results as
> >>> >> swf.
> >>> >> I will add this to the other work I have over the weekend
> >>> before I
> >>> >> get it
> >>> >> in. It only seems relevant for when child (or descendants, I
> >>> don't
> >>> >> expect
> >>> >> that will be different) method call is explicit (as opposed
> to
> >>> the
> >>> >> compiler-generated method calls from e4x 'member access')
> with
> >>> QName
> >>> >> argument only. I think most people won't use this approach
> with
> >>> >> explicit
> >>> >> QNames, but it is one of those things that will cause misery
> >>> if you do
> >>> >> (when porting legacy code), so it should be the same IMO
> also.
> >>> I will
> >>> >> make
> >>> >> sure it costs nothing for the more common (other) use cases.
> I
> >>> have
> >>> >> had to
> >>> >> do something similar to support 'use namespace' directives
> >>> which
> >>> >> create a
> >>> >> MultiName-like variant of QName in my local change that
> >>> includes the
> >>> >> default namespace and the specified set of other 'used'/open
> >>> >> namespace uris
> >>> >> in the current execution scope. (That 'use namespace'
> pattern
> >>> was
> >>> >> being
> >>> >> used quite a bit in the codebase I have been working on)
> >>> >>
> >>> >> Thanks again, that will save me investigating it with
> bytecode.
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui
> >>> <ah...@adobe.com.invalid>
> >>> >> wrote:
> >>> >>
> >>> >> > Out of pure random chance, I was starting the migration of
> >>> >> WebService
> >>> >> > which had a dependency on XMLUtil which contained the
> >>> comment:
> >>> >> >
> >>> >> > //xml.attribute(QName) will also return local
> >>> no-namespace
> >>> >> > attributes
> >>> >> > //even if we are looking for a specific full
> >>> qualified name.
> >>> >> >
> >>> >> > So, still could be a bug in Flash, but maybe we should
> just
> >>> make our
> >>> >> > implementation work the same way to reduce migration
> effort
> >>> in case
> >>> >> someone
> >>> >> > is relying on this behavior.
> >>> >> >
> >>> >> > Thoughts?
> >>> >> > -Alex
> >>> >> >
> >>> >> > On 9/4/19, 1:47 PM, "Alex Harui" <aharui@adobe.com.INVALID
> >
> >>> wrote:
> >>> >> >
> >>> >> > I read the example incorrectly. So yeah, it should
> >>> return 0
> >>> >> and empty
> >>> >> > string in both cases, IMO. There might be some subtlety
> in
> >>> how the
> >>> >> > namespaces are specified for a QName or how QName works in
> >>> child().
> >>> >> >
> >>> >> > HTH,
> >>> >> > -Alex
> >>> >> >
> >>> >> > On 9/4/19, 11:33 AM, "Greg Dove" <greg.dove@gmail.com
> >
> >>> wrote:
> >>> >> >
> >>> >> > Good idea. I'll check the swf output, although
> >>> probably
> >>> >> tomorrow
> >>> >> > as I need
> >>> >> > to focus on something else today.
> >>> >> > ' I would have expected both to return "1" and the
> >>> node. '
> >>> >> >
> >>> >> > In that example I would expect the opposite
> (because
> >>> the
> >>> >> the link
> >>> >> > node
> >>> >> > being returned by the second query is not in the
> >>> specified
> >>> >> explicit
> >>> >> > namespace of the QName), so I am curious to
> >>> understand why
> >>> >> you
> >>> >> > think
> >>> >> > that... maybe it will help me understand.
> >>> >> >
> >>> >> > When I use feed.atom::link I expect only links
> that
> >>> are
> >>> >> bound to
> >>> >> > the atom
> >>> >> > namespace (uri). Because <link ... /> node has no
> >>> prefix
> >>> >> bound to
> >>> >> > the uri
> >>> >> > that the atom namespace defines, and it is in the
> >>> default
> >>> >> > namespace, I
> >>> >> > would not expect it to be included.
> >>> >> > At the moment the atom::link part is working the
> >>> same as
> >>> >> swf, so
> >>> >> > I'm happy
> >>> >> > with that at least for what I am working on. All
> the
> >>> >> explicit
> >>> >> > calls to
> >>> >> > child(name) or descendants(name) in the app I am
> >>> working on
> >>> >> use
> >>> >> > string args
> >>> >> > so these all work correctly as well.
> >>> >> > I'm just trying to cover things for the future...
> >>> while my
> >>> >> head is
> >>> >> > still in
> >>> >> > this stuff.
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
> >>> >> <ah...@adobe.com.invalid>
> >>> >> > wrote:
> >>> >> >
> >>> >> > > Speaking of multinames, what is the ABC code
> >>> generated by
> >>> >> the
> >>> >> > Flex
> >>> >> > > compiler for the two cases? It might contain
> some
> >>> >> clues. I
> >>> >> > would have
> >>> >> > > expected both to return "1" and the node. But I
> >>> did see
> >>> >> in the
> >>> >> > spec the
> >>> >> > > notion of "InScopeNamespaces". I generally hate
> >>> reading
> >>> >> specs
> >>> >> > like these
> >>> >> > > so I am not very knowledgeable about what the
> spec
> >>> says.
> >>> >> > >
> >>> >> > > HTH,
> >>> >> > > -Alex
> >>> >> > >
> >>> >> > > On 9/4/19, 11:05 AM, "Greg Dove" <
> >>> greg.dove@gmail.com>
> >>> >> wrote:
> >>> >> > >
> >>> >> > > 'Have you rummaged through the spec?'
> >>> >> > > Yes, if anything I probably need to step
> away
> >>> from it
> >>> >> and
> >>> >> > experience
> >>> >> > > the
> >>> >> > > world a bit more! I have been focused on
> each
> >>> portion
> >>> >> of the
> >>> >> > spec as I
> >>> >> > > create unit tests and verify things between
> the
> >>> >> player and
> >>> >> > the Royale
> >>> >> > > implementation.
> >>> >> > > I've also glanced a few times in the avmplus
> >>> code,
> >>> >> and that
> >>> >> > has
> >>> >> > > provided
> >>> >> > > some clues where things were intentionally
> >>> implemented
> >>> >> > slightly off
> >>> >> > > spec,
> >>> >> > > but still a few things to figure out.
> However
> >>> I am
> >>> >> making
> >>> >> > progress - I
> >>> >> > > think I have everything covered for the
> >>> codebase I am
> >>> >> > working on....
> >>> >> > > but I
> >>> >> > > will keep going beyond that. For that
> example
> >>> above,
> >>> >> I might
> >>> >> > be wrong,
> >>> >> > > but
> >>> >> > > I suspect it is using a multiname with
> default
> >>> >> namespace
> >>> >> > included for
> >>> >> > > the
> >>> >> > > explicit call case in the player, but not
> for
> >>> the
> >>> >> implicit
> >>> >> > one, but I
> >>> >> > > am
> >>> >> > > not yet sure why. I will double-check the
> spec
> >>> >> though...
> >>> >> > >
> >>> >> > >
> >>> >> > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
> >>> >> > <ah...@adobe.com.invalid>
> >>> >> > > wrote:
> >>> >> > >
> >>> >> > > > Don't know. Have you rummaged through the
> >>> spec?
> >>> >> > > >
> >>> >> > > >
> >>> >> > >
> >>> >> >
> >>> >>
> >>>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034120784048005&sdata=hDhwbA6IQCFHQ3FQkNoVyaUcdZcxrzQS6ZWpiKrYr38%3D&reserved=0
> >>> >> > > >
> >>> >> > > > HTH,
> >>> >> > > > -Alex
> >>> >> > > >
> >>> >> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
> >>> >> greg.dove@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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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.
> >>> >> > > >
> >>> >> > > >
> >>> >> > > >
> >>> >> > >
> >>> >> > >
> >>> >> > >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >>
> >>> >>
> >>> >>
> >>>
> >>>
> >>>
> >
>
> --
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
Re: Heads up on XML
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
I think the DITA files generated by asdoc are pretty big too, so they're
probably really useful for your testing.
- Josh
On Friday, September 6, 2019, Greg Dove <gr...@gmail.com> wrote:
> 'I think that SWFDump will generate valid XML and there is a way to get
> DITA files from Flex ASDoc that are valid XML.'
> Sounds like a good idea for some large xml files. I did not use that yet,
> so will take a look and see if I can figure it out. Thanks!
>
>
> On Sat, Sep 7, 2019 at 12:30 PM Greg Dove <gr...@gmail.com> wrote:
>
>>
>> Just to clarify.... I was referring to this stuff here:
>>
>>
>>
https://github.com/apache/royale-asjs/blob/8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab/frameworks/projects/MXRoyale/src/main/royale/mx/rpc/http/AbstractOperation.as#L1038
>>
>>
>> with '//old XML style'
>>
>>
>>
>>
>> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui <ah...@adobe.com.invalid>
>> wrote:
>>
>>> I haven't looked at what XML is used/supported by MX HTTPService. It
>>> looks like WebService does use MX HTTPService. I am currently migrating
>>> other things that WebService needs (XMLEncoder/Decoder,
>>> SOAPEncoder/Decoder). These are new files that aren't in the repo yet,
so
>>> HTTPService couldn't be relying on them or else their use is commented
>>> out. The goal is to change as little as possible to get it to compile
and
>>> then see if it runs. I have no idea yet if the XML improvements you are
>>> working on are going to be impactful on what I'm doing or not.
>>>
>>> BTW, I could be wrong, but I think that SWFDump will generate valid XML
>>> and there is a way to get DITA files from Flex ASDoc that are valid XML.
>>>
>>> Thanks for the heads up,
>>> -Alex
>>>
>>> On 9/6/19, 5:14 PM, "Greg Dove" <gr...@gmail.com> wrote:
>>>
>>> Actually I know you are looking into the WSDL stuff.... maybe this
is
>>> going
>>> to be important for that (not sure)?
>>> My goal is to get the XML stuff tidied up and ready to push by end
of
>>> day
>>> tomorrow, worst case the following morning, local time (UTC+12). I
>>> also
>>> need to find some big XML test cases to check the memory side of
>>> things.
>>> FYI there is also some XMLDocument stuff missing (commented out)
from
>>> some
>>> of the MX HttpService code, which came up in a recent issue. I don't
>>> know
>>> if it shares any of the code from the WSDL stuff you are looking at
or
>>> not...
>>> If it does then I don't want to double up on things, but otherwise I
>>> will
>>> try to look at that on my Monday.
>>>
>>>
>>>
>>> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <gr...@gmail.com>
>>> wrote:
>>>
>>> > Thanks for checking that.
>>> >
>>> > child is specified in 13.4.4.6 and essentially calls [[Get]]
>>> > (After cycling through this kind of thing a few times, I found the
>>> easiest
>>> > way to find methods is to search in the spec for 'e.mehodName'
>>> which gets
>>> > you XML.prototype.methodName)
>>> >
>>> > and [[Get]] is specified in 9.1.1.1
>>> >
>>> > So I assume it is a bug. As discussed I think it is good to match
>>> the
>>> > behavior. If we can verify 100% it is off spec, we could add
>>> something as a
>>> > define to avoid the 'fix' for people who want to be on-spec.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui
<aharui@adobe.com.invalid
>>> >
>>> > wrote:
>>> >
>>> >> FWIW, I went and looked at the ABC.
>>> >>
>>> >> The first syntax sets up a getProperty just like any other
property
>>> >> fetch. The second (as expected) calls "child()". I've looked at
>>> the E4X
>>> >> spec a couple of times now and cannot see where the behavior we
>>> are seeing
>>> >> in child() is specified so I am going to assume it is a bug, and
>>> that we
>>> >> just have to live with it.
>>> >>
>>> >> I expect that getProperty does not call child(). I haven't
looked
>>> at the
>>> >> AVM code to see what getProperty does for XML.
>>> >>
>>> >> HTH,
>>> >> -Alex
>>> >>
>>> >> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
>>> >>
>>> >> Oh that is a good find! And perfect timing :)
>>> >> Thanks Alex, I am pretty sure that answers the question! (It
>>> quite
>>> >> specifically describes what I was seeing, I don't think it
>>> makes a
>>> >> difference whether it is attributes or elements)
>>> >>
>>> >> And yes, I agree it should be the implemented to give the
same
>>> >> results as
>>> >> swf.
>>> >> I will add this to the other work I have over the weekend
>>> before I
>>> >> get it
>>> >> in. It only seems relevant for when child (or descendants, I
>>> don't
>>> >> expect
>>> >> that will be different) method call is explicit (as opposed
to
>>> the
>>> >> compiler-generated method calls from e4x 'member access')
with
>>> QName
>>> >> argument only. I think most people won't use this approach
with
>>> >> explicit
>>> >> QNames, but it is one of those things that will cause misery
>>> if you do
>>> >> (when porting legacy code), so it should be the same IMO
also.
>>> I will
>>> >> make
>>> >> sure it costs nothing for the more common (other) use cases.
I
>>> have
>>> >> had to
>>> >> do something similar to support 'use namespace' directives
>>> which
>>> >> create a
>>> >> MultiName-like variant of QName in my local change that
>>> includes the
>>> >> default namespace and the specified set of other 'used'/open
>>> >> namespace uris
>>> >> in the current execution scope. (That 'use namespace' pattern
>>> was
>>> >> being
>>> >> used quite a bit in the codebase I have been working on)
>>> >>
>>> >> Thanks again, that will save me investigating it with
bytecode.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui
>>> <ah...@adobe.com.invalid>
>>> >> wrote:
>>> >>
>>> >> > Out of pure random chance, I was starting the migration of
>>> >> WebService
>>> >> > which had a dependency on XMLUtil which contained the
>>> comment:
>>> >> >
>>> >> > //xml.attribute(QName) will also return local
>>> no-namespace
>>> >> > attributes
>>> >> > //even if we are looking for a specific full
>>> qualified name.
>>> >> >
>>> >> > So, still could be a bug in Flash, but maybe we should just
>>> make our
>>> >> > implementation work the same way to reduce migration effort
>>> in case
>>> >> someone
>>> >> > is relying on this behavior.
>>> >> >
>>> >> > Thoughts?
>>> >> > -Alex
>>> >> >
>>> >> > On 9/4/19, 1:47 PM, "Alex Harui" <ah...@adobe.com.INVALID>
>>> wrote:
>>> >> >
>>> >> > I read the example incorrectly. So yeah, it should
>>> return 0
>>> >> and empty
>>> >> > string in both cases, IMO. There might be some subtlety in
>>> how the
>>> >> > namespaces are specified for a QName or how QName works in
>>> child().
>>> >> >
>>> >> > HTH,
>>> >> > -Alex
>>> >> >
>>> >> > On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com>
>>> wrote:
>>> >> >
>>> >> > Good idea. I'll check the swf output, although
>>> probably
>>> >> tomorrow
>>> >> > as I need
>>> >> > to focus on something else today.
>>> >> > ' I would have expected both to return "1" and the
>>> node. '
>>> >> >
>>> >> > In that example I would expect the opposite
(because
>>> the
>>> >> the link
>>> >> > node
>>> >> > being returned by the second query is not in the
>>> specified
>>> >> explicit
>>> >> > namespace of the QName), so I am curious to
>>> understand why
>>> >> you
>>> >> > think
>>> >> > that... maybe it will help me understand.
>>> >> >
>>> >> > When I use feed.atom::link I expect only links that
>>> are
>>> >> bound to
>>> >> > the atom
>>> >> > namespace (uri). Because <link ... /> node has no
>>> prefix
>>> >> bound to
>>> >> > the uri
>>> >> > that the atom namespace defines, and it is in the
>>> default
>>> >> > namespace, I
>>> >> > would not expect it to be included.
>>> >> > At the moment the atom::link part is working the
>>> same as
>>> >> swf, so
>>> >> > I'm happy
>>> >> > with that at least for what I am working on. All
the
>>> >> explicit
>>> >> > calls to
>>> >> > child(name) or descendants(name) in the app I am
>>> working on
>>> >> use
>>> >> > string args
>>> >> > so these all work correctly as well.
>>> >> > I'm just trying to cover things for the future...
>>> while my
>>> >> head is
>>> >> > still in
>>> >> > this stuff.
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
>>> >> <ah...@adobe.com.invalid>
>>> >> > wrote:
>>> >> >
>>> >> > > Speaking of multinames, what is the ABC code
>>> generated by
>>> >> the
>>> >> > Flex
>>> >> > > compiler for the two cases? It might contain
some
>>> >> clues. I
>>> >> > would have
>>> >> > > expected both to return "1" and the node. But I
>>> did see
>>> >> in the
>>> >> > spec the
>>> >> > > notion of "InScopeNamespaces". I generally hate
>>> reading
>>> >> specs
>>> >> > like these
>>> >> > > so I am not very knowledgeable about what the
spec
>>> says.
>>> >> > >
>>> >> > > HTH,
>>> >> > > -Alex
>>> >> > >
>>> >> > > On 9/4/19, 11:05 AM, "Greg Dove" <
>>> greg.dove@gmail.com>
>>> >> wrote:
>>> >> > >
>>> >> > > 'Have you rummaged through the spec?'
>>> >> > > Yes, if anything I probably need to step away
>>> from it
>>> >> and
>>> >> > experience
>>> >> > > the
>>> >> > > world a bit more! I have been focused on each
>>> portion
>>> >> of the
>>> >> > spec as I
>>> >> > > create unit tests and verify things between
the
>>> >> player and
>>> >> > the Royale
>>> >> > > implementation.
>>> >> > > I've also glanced a few times in the avmplus
>>> code,
>>> >> and that
>>> >> > has
>>> >> > > provided
>>> >> > > some clues where things were intentionally
>>> implemented
>>> >> > slightly off
>>> >> > > spec,
>>> >> > > but still a few things to figure out. However
>>> I am
>>> >> making
>>> >> > progress - I
>>> >> > > think I have everything covered for the
>>> codebase I am
>>> >> > working on....
>>> >> > > but I
>>> >> > > will keep going beyond that. For that example
>>> above,
>>> >> I might
>>> >> > be wrong,
>>> >> > > but
>>> >> > > I suspect it is using a multiname with
default
>>> >> namespace
>>> >> > included for
>>> >> > > the
>>> >> > > explicit call case in the player, but not for
>>> the
>>> >> implicit
>>> >> > one, but I
>>> >> > > am
>>> >> > > not yet sure why. I will double-check the
spec
>>> >> though...
>>> >> > >
>>> >> > >
>>> >> > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
>>> >> > <ah...@adobe.com.invalid>
>>> >> > > wrote:
>>> >> > >
>>> >> > > > Don't know. Have you rummaged through the
>>> spec?
>>> >> > > >
>>> >> > > >
>>> >> > >
>>> >> >
>>> >>
>>>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034120784048005&sdata=hDhwbA6IQCFHQ3FQkNoVyaUcdZcxrzQS6ZWpiKrYr38%3D&reserved=0
>>> >> > > >
>>> >> > > > HTH,
>>> >> > > > -Alex
>>> >> > > >
>>> >> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
>>> >> greg.dove@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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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.
>>> >> > > >
>>> >> > > >
>>> >> > > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>>
>>>
>>>
>
--
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
'I think that SWFDump will generate valid XML and there is a way to get
DITA files from Flex ASDoc that are valid XML.'
Sounds like a good idea for some large xml files. I did not use that yet,
so will take a look and see if I can figure it out. Thanks!
On Sat, Sep 7, 2019 at 12:30 PM Greg Dove <gr...@gmail.com> wrote:
>
> Just to clarify.... I was referring to this stuff here:
>
>
> https://github.com/apache/royale-asjs/blob/8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab/frameworks/projects/MXRoyale/src/main/royale/mx/rpc/http/AbstractOperation.as#L1038
>
>
> with '//old XML style'
>
>
>
>
> On Sat, Sep 7, 2019 at 12:24 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
>> I haven't looked at what XML is used/supported by MX HTTPService. It
>> looks like WebService does use MX HTTPService. I am currently migrating
>> other things that WebService needs (XMLEncoder/Decoder,
>> SOAPEncoder/Decoder). These are new files that aren't in the repo yet, so
>> HTTPService couldn't be relying on them or else their use is commented
>> out. The goal is to change as little as possible to get it to compile and
>> then see if it runs. I have no idea yet if the XML improvements you are
>> working on are going to be impactful on what I'm doing or not.
>>
>> BTW, I could be wrong, but I think that SWFDump will generate valid XML
>> and there is a way to get DITA files from Flex ASDoc that are valid XML.
>>
>> Thanks for the heads up,
>> -Alex
>>
>> On 9/6/19, 5:14 PM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>> Actually I know you are looking into the WSDL stuff.... maybe this is
>> going
>> to be important for that (not sure)?
>> My goal is to get the XML stuff tidied up and ready to push by end of
>> day
>> tomorrow, worst case the following morning, local time (UTC+12). I
>> also
>> need to find some big XML test cases to check the memory side of
>> things.
>> FYI there is also some XMLDocument stuff missing (commented out) from
>> some
>> of the MX HttpService code, which came up in a recent issue. I don't
>> know
>> if it shares any of the code from the WSDL stuff you are looking at or
>> not...
>> If it does then I don't want to double up on things, but otherwise I
>> will
>> try to look at that on my Monday.
>>
>>
>>
>> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <gr...@gmail.com>
>> wrote:
>>
>> > Thanks for checking that.
>> >
>> > child is specified in 13.4.4.6 and essentially calls [[Get]]
>> > (After cycling through this kind of thing a few times, I found the
>> easiest
>> > way to find methods is to search in the spec for 'e.mehodName'
>> which gets
>> > you XML.prototype.methodName)
>> >
>> > and [[Get]] is specified in 9.1.1.1
>> >
>> > So I assume it is a bug. As discussed I think it is good to match
>> the
>> > behavior. If we can verify 100% it is off spec, we could add
>> something as a
>> > define to avoid the 'fix' for people who want to be on-spec.
>> >
>> >
>> >
>> >
>> >
>> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui <aharui@adobe.com.invalid
>> >
>> > wrote:
>> >
>> >> FWIW, I went and looked at the ABC.
>> >>
>> >> The first syntax sets up a getProperty just like any other property
>> >> fetch. The second (as expected) calls "child()". I've looked at
>> the E4X
>> >> spec a couple of times now and cannot see where the behavior we
>> are seeing
>> >> in child() is specified so I am going to assume it is a bug, and
>> that we
>> >> just have to live with it.
>> >>
>> >> I expect that getProperty does not call child(). I haven't looked
>> at the
>> >> AVM code to see what getProperty does for XML.
>> >>
>> >> HTH,
>> >> -Alex
>> >>
>> >> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
>> >>
>> >> Oh that is a good find! And perfect timing :)
>> >> Thanks Alex, I am pretty sure that answers the question! (It
>> quite
>> >> specifically describes what I was seeing, I don't think it
>> makes a
>> >> difference whether it is attributes or elements)
>> >>
>> >> And yes, I agree it should be the implemented to give the same
>> >> results as
>> >> swf.
>> >> I will add this to the other work I have over the weekend
>> before I
>> >> get it
>> >> in. It only seems relevant for when child (or descendants, I
>> don't
>> >> expect
>> >> that will be different) method call is explicit (as opposed to
>> the
>> >> compiler-generated method calls from e4x 'member access') with
>> QName
>> >> argument only. I think most people won't use this approach with
>> >> explicit
>> >> QNames, but it is one of those things that will cause misery
>> if you do
>> >> (when porting legacy code), so it should be the same IMO also.
>> I will
>> >> make
>> >> sure it costs nothing for the more common (other) use cases. I
>> have
>> >> had to
>> >> do something similar to support 'use namespace' directives
>> which
>> >> create a
>> >> MultiName-like variant of QName in my local change that
>> includes the
>> >> default namespace and the specified set of other 'used'/open
>> >> namespace uris
>> >> in the current execution scope. (That 'use namespace' pattern
>> was
>> >> being
>> >> used quite a bit in the codebase I have been working on)
>> >>
>> >> Thanks again, that will save me investigating it with bytecode.
>> >>
>> >>
>> >>
>> >>
>> >> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui
>> <ah...@adobe.com.invalid>
>> >> wrote:
>> >>
>> >> > Out of pure random chance, I was starting the migration of
>> >> WebService
>> >> > which had a dependency on XMLUtil which contained the
>> comment:
>> >> >
>> >> > //xml.attribute(QName) will also return local
>> no-namespace
>> >> > attributes
>> >> > //even if we are looking for a specific full
>> qualified name.
>> >> >
>> >> > So, still could be a bug in Flash, but maybe we should just
>> make our
>> >> > implementation work the same way to reduce migration effort
>> in case
>> >> someone
>> >> > is relying on this behavior.
>> >> >
>> >> > Thoughts?
>> >> > -Alex
>> >> >
>> >> > On 9/4/19, 1:47 PM, "Alex Harui" <ah...@adobe.com.INVALID>
>> wrote:
>> >> >
>> >> > I read the example incorrectly. So yeah, it should
>> return 0
>> >> and empty
>> >> > string in both cases, IMO. There might be some subtlety in
>> how the
>> >> > namespaces are specified for a QName or how QName works in
>> child().
>> >> >
>> >> > HTH,
>> >> > -Alex
>> >> >
>> >> > On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com>
>> wrote:
>> >> >
>> >> > Good idea. I'll check the swf output, although
>> probably
>> >> tomorrow
>> >> > as I need
>> >> > to focus on something else today.
>> >> > ' I would have expected both to return "1" and the
>> node. '
>> >> >
>> >> > In that example I would expect the opposite (because
>> the
>> >> the link
>> >> > node
>> >> > being returned by the second query is not in the
>> specified
>> >> explicit
>> >> > namespace of the QName), so I am curious to
>> understand why
>> >> you
>> >> > think
>> >> > that... maybe it will help me understand.
>> >> >
>> >> > When I use feed.atom::link I expect only links that
>> are
>> >> bound to
>> >> > the atom
>> >> > namespace (uri). Because <link ... /> node has no
>> prefix
>> >> bound to
>> >> > the uri
>> >> > that the atom namespace defines, and it is in the
>> default
>> >> > namespace, I
>> >> > would not expect it to be included.
>> >> > At the moment the atom::link part is working the
>> same as
>> >> swf, so
>> >> > I'm happy
>> >> > with that at least for what I am working on. All the
>> >> explicit
>> >> > calls to
>> >> > child(name) or descendants(name) in the app I am
>> working on
>> >> use
>> >> > string args
>> >> > so these all work correctly as well.
>> >> > I'm just trying to cover things for the future...
>> while my
>> >> head is
>> >> > still in
>> >> > this stuff.
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
>> >> <ah...@adobe.com.invalid>
>> >> > wrote:
>> >> >
>> >> > > Speaking of multinames, what is the ABC code
>> generated by
>> >> the
>> >> > Flex
>> >> > > compiler for the two cases? It might contain some
>> >> clues. I
>> >> > would have
>> >> > > expected both to return "1" and the node. But I
>> did see
>> >> in the
>> >> > spec the
>> >> > > notion of "InScopeNamespaces". I generally hate
>> reading
>> >> specs
>> >> > like these
>> >> > > so I am not very knowledgeable about what the spec
>> says.
>> >> > >
>> >> > > HTH,
>> >> > > -Alex
>> >> > >
>> >> > > On 9/4/19, 11:05 AM, "Greg Dove" <
>> greg.dove@gmail.com>
>> >> wrote:
>> >> > >
>> >> > > 'Have you rummaged through the spec?'
>> >> > > Yes, if anything I probably need to step away
>> from it
>> >> and
>> >> > experience
>> >> > > the
>> >> > > world a bit more! I have been focused on each
>> portion
>> >> of the
>> >> > spec as I
>> >> > > create unit tests and verify things between the
>> >> player and
>> >> > the Royale
>> >> > > implementation.
>> >> > > I've also glanced a few times in the avmplus
>> code,
>> >> and that
>> >> > has
>> >> > > provided
>> >> > > some clues where things were intentionally
>> implemented
>> >> > slightly off
>> >> > > spec,
>> >> > > but still a few things to figure out. However
>> I am
>> >> making
>> >> > progress - I
>> >> > > think I have everything covered for the
>> codebase I am
>> >> > working on....
>> >> > > but I
>> >> > > will keep going beyond that. For that example
>> above,
>> >> I might
>> >> > be wrong,
>> >> > > but
>> >> > > I suspect it is using a multiname with default
>> >> namespace
>> >> > included for
>> >> > > the
>> >> > > explicit call case in the player, but not for
>> the
>> >> implicit
>> >> > one, but I
>> >> > > am
>> >> > > not yet sure why. I will double-check the spec
>> >> though...
>> >> > >
>> >> > >
>> >> > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
>> >> > <ah...@adobe.com.invalid>
>> >> > > wrote:
>> >> > >
>> >> > > > Don't know. Have you rummaged through the
>> spec?
>> >> > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034120784048005&sdata=hDhwbA6IQCFHQ3FQkNoVyaUcdZcxrzQS6ZWpiKrYr38%3D&reserved=0
>> >> > > >
>> >> > > > HTH,
>> >> > > > -Alex
>> >> > > >
>> >> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
>> >> greg.dove@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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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.
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>
Re: Heads up on XML
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Thanks. Yeah I remember that is commented out. In a quick look, it wasn't clear why XMLDocument was used instead of E4x in the WebService code. I will probably just use e4x and see what happens.
-Alex
On 9/6/19, 5:30 PM, "Greg Dove" <gr...@gmail.com> wrote:
Just to clarify.... I was referring to this stuff here:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2F8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab%2Fframeworks%2Fprojects%2FMXRoyale%2Fsrc%2Fmain%2Froyale%2Fmx%2Frpc%2Fhttp%2FAbstractOperation.as%23L1038&data=02%7C01%7Caharui%40adobe.com%7Cb03f4d24bb5b4c3b297c08d7332a944b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034130321301841&sdata=HKh9b5WI%2BFiclvbOKLNCFoVpj8cIh%2FUUHREeCef%2BNEU%3D&reserved=0
with '//old XML style'
On Sat, Sep 7, 2019 at 12:24 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> I haven't looked at what XML is used/supported by MX HTTPService. It
> looks like WebService does use MX HTTPService. I am currently migrating
> other things that WebService needs (XMLEncoder/Decoder,
> SOAPEncoder/Decoder). These are new files that aren't in the repo yet, so
> HTTPService couldn't be relying on them or else their use is commented
> out. The goal is to change as little as possible to get it to compile and
> then see if it runs. I have no idea yet if the XML improvements you are
> working on are going to be impactful on what I'm doing or not.
>
> BTW, I could be wrong, but I think that SWFDump will generate valid XML
> and there is a way to get DITA files from Flex ASDoc that are valid XML.
>
> Thanks for the heads up,
> -Alex
>
> On 9/6/19, 5:14 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Actually I know you are looking into the WSDL stuff.... maybe this is
> going
> to be important for that (not sure)?
> My goal is to get the XML stuff tidied up and ready to push by end of
> day
> tomorrow, worst case the following morning, local time (UTC+12). I also
> need to find some big XML test cases to check the memory side of
> things.
> FYI there is also some XMLDocument stuff missing (commented out) from
> some
> of the MX HttpService code, which came up in a recent issue. I don't
> know
> if it shares any of the code from the WSDL stuff you are looking at or
> not...
> If it does then I don't want to double up on things, but otherwise I
> will
> try to look at that on my Monday.
>
>
>
> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <gr...@gmail.com> wrote:
>
> > Thanks for checking that.
> >
> > child is specified in 13.4.4.6 and essentially calls [[Get]]
> > (After cycling through this kind of thing a few times, I found the
> easiest
> > way to find methods is to search in the spec for 'e.mehodName' which
> gets
> > you XML.prototype.methodName)
> >
> > and [[Get]] is specified in 9.1.1.1
> >
> > So I assume it is a bug. As discussed I think it is good to match the
> > behavior. If we can verify 100% it is off spec, we could add
> something as a
> > define to avoid the 'fix' for people who want to be on-spec.
> >
> >
> >
> >
> >
> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui <aharui@adobe.com.invalid
> >
> > wrote:
> >
> >> FWIW, I went and looked at the ABC.
> >>
> >> The first syntax sets up a getProperty just like any other property
> >> fetch. The second (as expected) calls "child()". I've looked at
> the E4X
> >> spec a couple of times now and cannot see where the behavior we are
> seeing
> >> in child() is specified so I am going to assume it is a bug, and
> that we
> >> just have to live with it.
> >>
> >> I expect that getProperty does not call child(). I haven't looked
> at the
> >> AVM code to see what getProperty does for XML.
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >>
> >> Oh that is a good find! And perfect timing :)
> >> Thanks Alex, I am pretty sure that answers the question! (It
> quite
> >> specifically describes what I was seeing, I don't think it
> makes a
> >> difference whether it is attributes or elements)
> >>
> >> And yes, I agree it should be the implemented to give the same
> >> results as
> >> swf.
> >> I will add this to the other work I have over the weekend
> before I
> >> get it
> >> in. It only seems relevant for when child (or descendants, I
> don't
> >> expect
> >> that will be different) method call is explicit (as opposed to
> the
> >> compiler-generated method calls from e4x 'member access') with
> QName
> >> argument only. I think most people won't use this approach with
> >> explicit
> >> QNames, but it is one of those things that will cause misery if
> you do
> >> (when porting legacy code), so it should be the same IMO also.
> I will
> >> make
> >> sure it costs nothing for the more common (other) use cases. I
> have
> >> had to
> >> do something similar to support 'use namespace' directives which
> >> create a
> >> MultiName-like variant of QName in my local change that
> includes the
> >> default namespace and the specified set of other 'used'/open
> >> namespace uris
> >> in the current execution scope. (That 'use namespace' pattern
> was
> >> being
> >> used quite a bit in the codebase I have been working on)
> >>
> >> Thanks again, that will save me investigating it with bytecode.
> >>
> >>
> >>
> >>
> >> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui
> <ah...@adobe.com.invalid>
> >> wrote:
> >>
> >> > Out of pure random chance, I was starting the migration of
> >> WebService
> >> > which had a dependency on XMLUtil which contained the comment:
> >> >
> >> > //xml.attribute(QName) will also return local
> no-namespace
> >> > attributes
> >> > //even if we are looking for a specific full
> qualified name.
> >> >
> >> > So, still could be a bug in Flash, but maybe we should just
> make our
> >> > implementation work the same way to reduce migration effort
> in case
> >> someone
> >> > is relying on this behavior.
> >> >
> >> > Thoughts?
> >> > -Alex
> >> >
> >> > On 9/4/19, 1:47 PM, "Alex Harui" <ah...@adobe.com.INVALID>
> wrote:
> >> >
> >> > I read the example incorrectly. So yeah, it should
> return 0
> >> and empty
> >> > string in both cases, IMO. There might be some subtlety in
> how the
> >> > namespaces are specified for a QName or how QName works in
> child().
> >> >
> >> > HTH,
> >> > -Alex
> >> >
> >> > On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com>
> wrote:
> >> >
> >> > Good idea. I'll check the swf output, although
> probably
> >> tomorrow
> >> > as I need
> >> > to focus on something else today.
> >> > ' I would have expected both to return "1" and the
> node. '
> >> >
> >> > In that example I would expect the opposite (because
> the
> >> the link
> >> > node
> >> > being returned by the second query is not in the
> specified
> >> explicit
> >> > namespace of the QName), so I am curious to
> understand why
> >> you
> >> > think
> >> > that... maybe it will help me understand.
> >> >
> >> > When I use feed.atom::link I expect only links that
> are
> >> bound to
> >> > the atom
> >> > namespace (uri). Because <link ... /> node has no
> prefix
> >> bound to
> >> > the uri
> >> > that the atom namespace defines, and it is in the
> default
> >> > namespace, I
> >> > would not expect it to be included.
> >> > At the moment the atom::link part is working the same
> as
> >> swf, so
> >> > I'm happy
> >> > with that at least for what I am working on. All the
> >> explicit
> >> > calls to
> >> > child(name) or descendants(name) in the app I am
> working on
> >> use
> >> > string args
> >> > so these all work correctly as well.
> >> > I'm just trying to cover things for the future...
> while my
> >> head is
> >> > still in
> >> > this stuff.
> >> >
> >> >
> >> >
> >> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
> >> <ah...@adobe.com.invalid>
> >> > wrote:
> >> >
> >> > > Speaking of multinames, what is the ABC code
> generated by
> >> the
> >> > Flex
> >> > > compiler for the two cases? It might contain some
> >> clues. I
> >> > would have
> >> > > expected both to return "1" and the node. But I
> did see
> >> in the
> >> > spec the
> >> > > notion of "InScopeNamespaces". I generally hate
> reading
> >> specs
> >> > like these
> >> > > so I am not very knowledgeable about what the spec
> says.
> >> > >
> >> > > HTH,
> >> > > -Alex
> >> > >
> >> > > On 9/4/19, 11:05 AM, "Greg Dove" <
> greg.dove@gmail.com>
> >> wrote:
> >> > >
> >> > > 'Have you rummaged through the spec?'
> >> > > Yes, if anything I probably need to step away
> from it
> >> and
> >> > experience
> >> > > the
> >> > > world a bit more! I have been focused on each
> portion
> >> of the
> >> > spec as I
> >> > > create unit tests and verify things between the
> >> player and
> >> > the Royale
> >> > > implementation.
> >> > > I've also glanced a few times in the avmplus
> code,
> >> and that
> >> > has
> >> > > provided
> >> > > some clues where things were intentionally
> implemented
> >> > slightly off
> >> > > spec,
> >> > > but still a few things to figure out. However I
> am
> >> making
> >> > progress - I
> >> > > think I have everything covered for the
> codebase I am
> >> > working on....
> >> > > but I
> >> > > will keep going beyond that. For that example
> above,
> >> I might
> >> > be wrong,
> >> > > but
> >> > > I suspect it is using a multiname with default
> >> namespace
> >> > included for
> >> > > the
> >> > > explicit call case in the player, but not for
> the
> >> implicit
> >> > one, but I
> >> > > am
> >> > > not yet sure why. I will double-check the spec
> >> though...
> >> > >
> >> > >
> >> > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
> >> > <ah...@adobe.com.invalid>
> >> > > wrote:
> >> > >
> >> > > > Don't know. Have you rummaged through the
> spec?
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7Cb03f4d24bb5b4c3b297c08d7332a944b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034130321301841&sdata=C0tyzSrA5FyKi0HOv72fMUgPhimhHby3F9%2BW0mfJMAU%3D&reserved=0
> >> > > >
> >> > > > HTH,
> >> > > > -Alex
> >> > > >
> >> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
> >> greg.dove@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%7Cb03f4d24bb5b4c3b297c08d7332a944b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034130321301841&sdata=vW%2FufHSFv881ctf4rSTmmtr%2FFgYTGWUCRv%2F72WV%2F4XM%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%7Cb03f4d24bb5b4c3b297c08d7332a944b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034130321301841&sdata=vW%2FufHSFv881ctf4rSTmmtr%2FFgYTGWUCRv%2F72WV%2F4XM%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%7Cb03f4d24bb5b4c3b297c08d7332a944b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034130321301841&sdata=vW%2FufHSFv881ctf4rSTmmtr%2FFgYTGWUCRv%2F72WV%2F4XM%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.
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
>
>
>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
Just to clarify.... I was referring to this stuff here:
https://github.com/apache/royale-asjs/blob/8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab/frameworks/projects/MXRoyale/src/main/royale/mx/rpc/http/AbstractOperation.as#L1038
with '//old XML style'
On Sat, Sep 7, 2019 at 12:24 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> I haven't looked at what XML is used/supported by MX HTTPService. It
> looks like WebService does use MX HTTPService. I am currently migrating
> other things that WebService needs (XMLEncoder/Decoder,
> SOAPEncoder/Decoder). These are new files that aren't in the repo yet, so
> HTTPService couldn't be relying on them or else their use is commented
> out. The goal is to change as little as possible to get it to compile and
> then see if it runs. I have no idea yet if the XML improvements you are
> working on are going to be impactful on what I'm doing or not.
>
> BTW, I could be wrong, but I think that SWFDump will generate valid XML
> and there is a way to get DITA files from Flex ASDoc that are valid XML.
>
> Thanks for the heads up,
> -Alex
>
> On 9/6/19, 5:14 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Actually I know you are looking into the WSDL stuff.... maybe this is
> going
> to be important for that (not sure)?
> My goal is to get the XML stuff tidied up and ready to push by end of
> day
> tomorrow, worst case the following morning, local time (UTC+12). I also
> need to find some big XML test cases to check the memory side of
> things.
> FYI there is also some XMLDocument stuff missing (commented out) from
> some
> of the MX HttpService code, which came up in a recent issue. I don't
> know
> if it shares any of the code from the WSDL stuff you are looking at or
> not...
> If it does then I don't want to double up on things, but otherwise I
> will
> try to look at that on my Monday.
>
>
>
> On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <gr...@gmail.com> wrote:
>
> > Thanks for checking that.
> >
> > child is specified in 13.4.4.6 and essentially calls [[Get]]
> > (After cycling through this kind of thing a few times, I found the
> easiest
> > way to find methods is to search in the spec for 'e.mehodName' which
> gets
> > you XML.prototype.methodName)
> >
> > and [[Get]] is specified in 9.1.1.1
> >
> > So I assume it is a bug. As discussed I think it is good to match the
> > behavior. If we can verify 100% it is off spec, we could add
> something as a
> > define to avoid the 'fix' for people who want to be on-spec.
> >
> >
> >
> >
> >
> > On Sat, Sep 7, 2019 at 11:30 AM Alex Harui <aharui@adobe.com.invalid
> >
> > wrote:
> >
> >> FWIW, I went and looked at the ABC.
> >>
> >> The first syntax sets up a getProperty just like any other property
> >> fetch. The second (as expected) calls "child()". I've looked at
> the E4X
> >> spec a couple of times now and cannot see where the behavior we are
> seeing
> >> in child() is specified so I am going to assume it is a bug, and
> that we
> >> just have to live with it.
> >>
> >> I expect that getProperty does not call child(). I haven't looked
> at the
> >> AVM code to see what getProperty does for XML.
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >>
> >> Oh that is a good find! And perfect timing :)
> >> Thanks Alex, I am pretty sure that answers the question! (It
> quite
> >> specifically describes what I was seeing, I don't think it
> makes a
> >> difference whether it is attributes or elements)
> >>
> >> And yes, I agree it should be the implemented to give the same
> >> results as
> >> swf.
> >> I will add this to the other work I have over the weekend
> before I
> >> get it
> >> in. It only seems relevant for when child (or descendants, I
> don't
> >> expect
> >> that will be different) method call is explicit (as opposed to
> the
> >> compiler-generated method calls from e4x 'member access') with
> QName
> >> argument only. I think most people won't use this approach with
> >> explicit
> >> QNames, but it is one of those things that will cause misery if
> you do
> >> (when porting legacy code), so it should be the same IMO also.
> I will
> >> make
> >> sure it costs nothing for the more common (other) use cases. I
> have
> >> had to
> >> do something similar to support 'use namespace' directives which
> >> create a
> >> MultiName-like variant of QName in my local change that
> includes the
> >> default namespace and the specified set of other 'used'/open
> >> namespace uris
> >> in the current execution scope. (That 'use namespace' pattern
> was
> >> being
> >> used quite a bit in the codebase I have been working on)
> >>
> >> Thanks again, that will save me investigating it with bytecode.
> >>
> >>
> >>
> >>
> >> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui
> <ah...@adobe.com.invalid>
> >> wrote:
> >>
> >> > Out of pure random chance, I was starting the migration of
> >> WebService
> >> > which had a dependency on XMLUtil which contained the comment:
> >> >
> >> > //xml.attribute(QName) will also return local
> no-namespace
> >> > attributes
> >> > //even if we are looking for a specific full
> qualified name.
> >> >
> >> > So, still could be a bug in Flash, but maybe we should just
> make our
> >> > implementation work the same way to reduce migration effort
> in case
> >> someone
> >> > is relying on this behavior.
> >> >
> >> > Thoughts?
> >> > -Alex
> >> >
> >> > On 9/4/19, 1:47 PM, "Alex Harui" <ah...@adobe.com.INVALID>
> wrote:
> >> >
> >> > I read the example incorrectly. So yeah, it should
> return 0
> >> and empty
> >> > string in both cases, IMO. There might be some subtlety in
> how the
> >> > namespaces are specified for a QName or how QName works in
> child().
> >> >
> >> > HTH,
> >> > -Alex
> >> >
> >> > On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com>
> wrote:
> >> >
> >> > Good idea. I'll check the swf output, although
> probably
> >> tomorrow
> >> > as I need
> >> > to focus on something else today.
> >> > ' I would have expected both to return "1" and the
> node. '
> >> >
> >> > In that example I would expect the opposite (because
> the
> >> the link
> >> > node
> >> > being returned by the second query is not in the
> specified
> >> explicit
> >> > namespace of the QName), so I am curious to
> understand why
> >> you
> >> > think
> >> > that... maybe it will help me understand.
> >> >
> >> > When I use feed.atom::link I expect only links that
> are
> >> bound to
> >> > the atom
> >> > namespace (uri). Because <link ... /> node has no
> prefix
> >> bound to
> >> > the uri
> >> > that the atom namespace defines, and it is in the
> default
> >> > namespace, I
> >> > would not expect it to be included.
> >> > At the moment the atom::link part is working the same
> as
> >> swf, so
> >> > I'm happy
> >> > with that at least for what I am working on. All the
> >> explicit
> >> > calls to
> >> > child(name) or descendants(name) in the app I am
> working on
> >> use
> >> > string args
> >> > so these all work correctly as well.
> >> > I'm just trying to cover things for the future...
> while my
> >> head is
> >> > still in
> >> > this stuff.
> >> >
> >> >
> >> >
> >> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
> >> <ah...@adobe.com.invalid>
> >> > wrote:
> >> >
> >> > > Speaking of multinames, what is the ABC code
> generated by
> >> the
> >> > Flex
> >> > > compiler for the two cases? It might contain some
> >> clues. I
> >> > would have
> >> > > expected both to return "1" and the node. But I
> did see
> >> in the
> >> > spec the
> >> > > notion of "InScopeNamespaces". I generally hate
> reading
> >> specs
> >> > like these
> >> > > so I am not very knowledgeable about what the spec
> says.
> >> > >
> >> > > HTH,
> >> > > -Alex
> >> > >
> >> > > On 9/4/19, 11:05 AM, "Greg Dove" <
> greg.dove@gmail.com>
> >> wrote:
> >> > >
> >> > > 'Have you rummaged through the spec?'
> >> > > Yes, if anything I probably need to step away
> from it
> >> and
> >> > experience
> >> > > the
> >> > > world a bit more! I have been focused on each
> portion
> >> of the
> >> > spec as I
> >> > > create unit tests and verify things between the
> >> player and
> >> > the Royale
> >> > > implementation.
> >> > > I've also glanced a few times in the avmplus
> code,
> >> and that
> >> > has
> >> > > provided
> >> > > some clues where things were intentionally
> implemented
> >> > slightly off
> >> > > spec,
> >> > > but still a few things to figure out. However I
> am
> >> making
> >> > progress - I
> >> > > think I have everything covered for the
> codebase I am
> >> > working on....
> >> > > but I
> >> > > will keep going beyond that. For that example
> above,
> >> I might
> >> > be wrong,
> >> > > but
> >> > > I suspect it is using a multiname with default
> >> namespace
> >> > included for
> >> > > the
> >> > > explicit call case in the player, but not for
> the
> >> implicit
> >> > one, but I
> >> > > am
> >> > > not yet sure why. I will double-check the spec
> >> though...
> >> > >
> >> > >
> >> > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
> >> > <ah...@adobe.com.invalid>
> >> > > wrote:
> >> > >
> >> > > > Don't know. Have you rummaged through the
> spec?
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034120784048005&sdata=hDhwbA6IQCFHQ3FQkNoVyaUcdZcxrzQS6ZWpiKrYr38%3D&reserved=0
> >> > > >
> >> > > > HTH,
> >> > > > -Alex
> >> > > >
> >> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
> >> greg.dove@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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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.
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
>
>
>
Re: Heads up on XML
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I haven't looked at what XML is used/supported by MX HTTPService. It looks like WebService does use MX HTTPService. I am currently migrating other things that WebService needs (XMLEncoder/Decoder, SOAPEncoder/Decoder). These are new files that aren't in the repo yet, so HTTPService couldn't be relying on them or else their use is commented out. The goal is to change as little as possible to get it to compile and then see if it runs. I have no idea yet if the XML improvements you are working on are going to be impactful on what I'm doing or not.
BTW, I could be wrong, but I think that SWFDump will generate valid XML and there is a way to get DITA files from Flex ASDoc that are valid XML.
Thanks for the heads up,
-Alex
On 9/6/19, 5:14 PM, "Greg Dove" <gr...@gmail.com> wrote:
Actually I know you are looking into the WSDL stuff.... maybe this is going
to be important for that (not sure)?
My goal is to get the XML stuff tidied up and ready to push by end of day
tomorrow, worst case the following morning, local time (UTC+12). I also
need to find some big XML test cases to check the memory side of things.
FYI there is also some XMLDocument stuff missing (commented out) from some
of the MX HttpService code, which came up in a recent issue. I don't know
if it shares any of the code from the WSDL stuff you are looking at or
not...
If it does then I don't want to double up on things, but otherwise I will
try to look at that on my Monday.
On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <gr...@gmail.com> wrote:
> Thanks for checking that.
>
> child is specified in 13.4.4.6 and essentially calls [[Get]]
> (After cycling through this kind of thing a few times, I found the easiest
> way to find methods is to search in the spec for 'e.mehodName' which gets
> you XML.prototype.methodName)
>
> and [[Get]] is specified in 9.1.1.1
>
> So I assume it is a bug. As discussed I think it is good to match the
> behavior. If we can verify 100% it is off spec, we could add something as a
> define to avoid the 'fix' for people who want to be on-spec.
>
>
>
>
>
> On Sat, Sep 7, 2019 at 11:30 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
>> FWIW, I went and looked at the ABC.
>>
>> The first syntax sets up a getProperty just like any other property
>> fetch. The second (as expected) calls "child()". I've looked at the E4X
>> spec a couple of times now and cannot see where the behavior we are seeing
>> in child() is specified so I am going to assume it is a bug, and that we
>> just have to live with it.
>>
>> I expect that getProperty does not call child(). I haven't looked at the
>> AVM code to see what getProperty does for XML.
>>
>> HTH,
>> -Alex
>>
>> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>> Oh that is a good find! And perfect timing :)
>> Thanks Alex, I am pretty sure that answers the question! (It quite
>> specifically describes what I was seeing, I don't think it makes a
>> difference whether it is attributes or elements)
>>
>> And yes, I agree it should be the implemented to give the same
>> results as
>> swf.
>> I will add this to the other work I have over the weekend before I
>> get it
>> in. It only seems relevant for when child (or descendants, I don't
>> expect
>> that will be different) method call is explicit (as opposed to the
>> compiler-generated method calls from e4x 'member access') with QName
>> argument only. I think most people won't use this approach with
>> explicit
>> QNames, but it is one of those things that will cause misery if you do
>> (when porting legacy code), so it should be the same IMO also. I will
>> make
>> sure it costs nothing for the more common (other) use cases. I have
>> had to
>> do something similar to support 'use namespace' directives which
>> create a
>> MultiName-like variant of QName in my local change that includes the
>> default namespace and the specified set of other 'used'/open
>> namespace uris
>> in the current execution scope. (That 'use namespace' pattern was
>> being
>> used quite a bit in the codebase I have been working on)
>>
>> Thanks again, that will save me investigating it with bytecode.
>>
>>
>>
>>
>> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid>
>> wrote:
>>
>> > Out of pure random chance, I was starting the migration of
>> WebService
>> > which had a dependency on XMLUtil which contained the comment:
>> >
>> > //xml.attribute(QName) will also return local no-namespace
>> > attributes
>> > //even if we are looking for a specific full qualified name.
>> >
>> > So, still could be a bug in Flash, but maybe we should just make our
>> > implementation work the same way to reduce migration effort in case
>> someone
>> > is relying on this behavior.
>> >
>> > Thoughts?
>> > -Alex
>> >
>> > On 9/4/19, 1:47 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
>> >
>> > I read the example incorrectly. So yeah, it should return 0
>> and empty
>> > string in both cases, IMO. There might be some subtlety in how the
>> > namespaces are specified for a QName or how QName works in child().
>> >
>> > HTH,
>> > -Alex
>> >
>> > On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com> wrote:
>> >
>> > Good idea. I'll check the swf output, although probably
>> tomorrow
>> > as I need
>> > to focus on something else today.
>> > ' I would have expected both to return "1" and the node. '
>> >
>> > In that example I would expect the opposite (because the
>> the link
>> > node
>> > being returned by the second query is not in the specified
>> explicit
>> > namespace of the QName), so I am curious to understand why
>> you
>> > think
>> > that... maybe it will help me understand.
>> >
>> > When I use feed.atom::link I expect only links that are
>> bound to
>> > the atom
>> > namespace (uri). Because <link ... /> node has no prefix
>> bound to
>> > the uri
>> > that the atom namespace defines, and it is in the default
>> > namespace, I
>> > would not expect it to be included.
>> > At the moment the atom::link part is working the same as
>> swf, so
>> > I'm happy
>> > with that at least for what I am working on. All the
>> explicit
>> > calls to
>> > child(name) or descendants(name) in the app I am working on
>> use
>> > string args
>> > so these all work correctly as well.
>> > I'm just trying to cover things for the future... while my
>> head is
>> > still in
>> > this stuff.
>> >
>> >
>> >
>> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
>> <ah...@adobe.com.invalid>
>> > wrote:
>> >
>> > > Speaking of multinames, what is the ABC code generated by
>> the
>> > Flex
>> > > compiler for the two cases? It might contain some
>> clues. I
>> > would have
>> > > expected both to return "1" and the node. But I did see
>> in the
>> > spec the
>> > > notion of "InScopeNamespaces". I generally hate reading
>> specs
>> > like these
>> > > so I am not very knowledgeable about what the spec says.
>> > >
>> > > HTH,
>> > > -Alex
>> > >
>> > > On 9/4/19, 11:05 AM, "Greg Dove" <gr...@gmail.com>
>> wrote:
>> > >
>> > > 'Have you rummaged through the spec?'
>> > > Yes, if anything I probably need to step away from it
>> and
>> > experience
>> > > the
>> > > world a bit more! I have been focused on each portion
>> of the
>> > spec as I
>> > > create unit tests and verify things between the
>> player and
>> > the Royale
>> > > implementation.
>> > > I've also glanced a few times in the avmplus code,
>> and that
>> > has
>> > > provided
>> > > some clues where things were intentionally implemented
>> > slightly off
>> > > spec,
>> > > but still a few things to figure out. However I am
>> making
>> > progress - I
>> > > think I have everything covered for the codebase I am
>> > working on....
>> > > but I
>> > > will keep going beyond that. For that example above,
>> I might
>> > be wrong,
>> > > but
>> > > I suspect it is using a multiname with default
>> namespace
>> > included for
>> > > the
>> > > explicit call case in the player, but not for the
>> implicit
>> > one, but I
>> > > am
>> > > not yet sure why. I will double-check the spec
>> though...
>> > >
>> > >
>> > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
>> > <ah...@adobe.com.invalid>
>> > > wrote:
>> > >
>> > > > Don't know. Have you rummaged through the spec?
>> > > >
>> > > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034120784048005&sdata=hDhwbA6IQCFHQ3FQkNoVyaUcdZcxrzQS6ZWpiKrYr38%3D&reserved=0
>> > > >
>> > > > HTH,
>> > > > -Alex
>> > > >
>> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
>> greg.dove@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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%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.
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
Actually I know you are looking into the WSDL stuff.... maybe this is going
to be important for that (not sure)?
My goal is to get the XML stuff tidied up and ready to push by end of day
tomorrow, worst case the following morning, local time (UTC+12). I also
need to find some big XML test cases to check the memory side of things.
FYI there is also some XMLDocument stuff missing (commented out) from some
of the MX HttpService code, which came up in a recent issue. I don't know
if it shares any of the code from the WSDL stuff you are looking at or
not...
If it does then I don't want to double up on things, but otherwise I will
try to look at that on my Monday.
On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <gr...@gmail.com> wrote:
> Thanks for checking that.
>
> child is specified in 13.4.4.6 and essentially calls [[Get]]
> (After cycling through this kind of thing a few times, I found the easiest
> way to find methods is to search in the spec for 'e.mehodName' which gets
> you XML.prototype.methodName)
>
> and [[Get]] is specified in 9.1.1.1
>
> So I assume it is a bug. As discussed I think it is good to match the
> behavior. If we can verify 100% it is off spec, we could add something as a
> define to avoid the 'fix' for people who want to be on-spec.
>
>
>
>
>
> On Sat, Sep 7, 2019 at 11:30 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
>> FWIW, I went and looked at the ABC.
>>
>> The first syntax sets up a getProperty just like any other property
>> fetch. The second (as expected) calls "child()". I've looked at the E4X
>> spec a couple of times now and cannot see where the behavior we are seeing
>> in child() is specified so I am going to assume it is a bug, and that we
>> just have to live with it.
>>
>> I expect that getProperty does not call child(). I haven't looked at the
>> AVM code to see what getProperty does for XML.
>>
>> HTH,
>> -Alex
>>
>> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>> Oh that is a good find! And perfect timing :)
>> Thanks Alex, I am pretty sure that answers the question! (It quite
>> specifically describes what I was seeing, I don't think it makes a
>> difference whether it is attributes or elements)
>>
>> And yes, I agree it should be the implemented to give the same
>> results as
>> swf.
>> I will add this to the other work I have over the weekend before I
>> get it
>> in. It only seems relevant for when child (or descendants, I don't
>> expect
>> that will be different) method call is explicit (as opposed to the
>> compiler-generated method calls from e4x 'member access') with QName
>> argument only. I think most people won't use this approach with
>> explicit
>> QNames, but it is one of those things that will cause misery if you do
>> (when porting legacy code), so it should be the same IMO also. I will
>> make
>> sure it costs nothing for the more common (other) use cases. I have
>> had to
>> do something similar to support 'use namespace' directives which
>> create a
>> MultiName-like variant of QName in my local change that includes the
>> default namespace and the specified set of other 'used'/open
>> namespace uris
>> in the current execution scope. (That 'use namespace' pattern was
>> being
>> used quite a bit in the codebase I have been working on)
>>
>> Thanks again, that will save me investigating it with bytecode.
>>
>>
>>
>>
>> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid>
>> wrote:
>>
>> > Out of pure random chance, I was starting the migration of
>> WebService
>> > which had a dependency on XMLUtil which contained the comment:
>> >
>> > //xml.attribute(QName) will also return local no-namespace
>> > attributes
>> > //even if we are looking for a specific full qualified name.
>> >
>> > So, still could be a bug in Flash, but maybe we should just make our
>> > implementation work the same way to reduce migration effort in case
>> someone
>> > is relying on this behavior.
>> >
>> > Thoughts?
>> > -Alex
>> >
>> > On 9/4/19, 1:47 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
>> >
>> > I read the example incorrectly. So yeah, it should return 0
>> and empty
>> > string in both cases, IMO. There might be some subtlety in how the
>> > namespaces are specified for a QName or how QName works in child().
>> >
>> > HTH,
>> > -Alex
>> >
>> > On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com> wrote:
>> >
>> > Good idea. I'll check the swf output, although probably
>> tomorrow
>> > as I need
>> > to focus on something else today.
>> > ' I would have expected both to return "1" and the node. '
>> >
>> > In that example I would expect the opposite (because the
>> the link
>> > node
>> > being returned by the second query is not in the specified
>> explicit
>> > namespace of the QName), so I am curious to understand why
>> you
>> > think
>> > that... maybe it will help me understand.
>> >
>> > When I use feed.atom::link I expect only links that are
>> bound to
>> > the atom
>> > namespace (uri). Because <link ... /> node has no prefix
>> bound to
>> > the uri
>> > that the atom namespace defines, and it is in the default
>> > namespace, I
>> > would not expect it to be included.
>> > At the moment the atom::link part is working the same as
>> swf, so
>> > I'm happy
>> > with that at least for what I am working on. All the
>> explicit
>> > calls to
>> > child(name) or descendants(name) in the app I am working on
>> use
>> > string args
>> > so these all work correctly as well.
>> > I'm just trying to cover things for the future... while my
>> head is
>> > still in
>> > this stuff.
>> >
>> >
>> >
>> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
>> <ah...@adobe.com.invalid>
>> > wrote:
>> >
>> > > Speaking of multinames, what is the ABC code generated by
>> the
>> > Flex
>> > > compiler for the two cases? It might contain some
>> clues. I
>> > would have
>> > > expected both to return "1" and the node. But I did see
>> in the
>> > spec the
>> > > notion of "InScopeNamespaces". I generally hate reading
>> specs
>> > like these
>> > > so I am not very knowledgeable about what the spec says.
>> > >
>> > > HTH,
>> > > -Alex
>> > >
>> > > On 9/4/19, 11:05 AM, "Greg Dove" <gr...@gmail.com>
>> wrote:
>> > >
>> > > 'Have you rummaged through the spec?'
>> > > Yes, if anything I probably need to step away from it
>> and
>> > experience
>> > > the
>> > > world a bit more! I have been focused on each portion
>> of the
>> > spec as I
>> > > create unit tests and verify things between the
>> player and
>> > the Royale
>> > > implementation.
>> > > I've also glanced a few times in the avmplus code,
>> and that
>> > has
>> > > provided
>> > > some clues where things were intentionally implemented
>> > slightly off
>> > > spec,
>> > > but still a few things to figure out. However I am
>> making
>> > progress - I
>> > > think I have everything covered for the codebase I am
>> > working on....
>> > > but I
>> > > will keep going beyond that. For that example above,
>> I might
>> > be wrong,
>> > > but
>> > > I suspect it is using a multiname with default
>> namespace
>> > included for
>> > > the
>> > > explicit call case in the player, but not for the
>> implicit
>> > one, but I
>> > > am
>> > > not yet sure why. I will double-check the spec
>> though...
>> > >
>> > >
>> > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
>> > <ah...@adobe.com.invalid>
>> > > wrote:
>> > >
>> > > > Don't know. Have you rummaged through the spec?
>> > > >
>> > > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637033071564533291&sdata=N1f5b20jjPP4SHWNM4hyleXMJW6qW%2FItnmgJ7oU73Hs%3D&reserved=0
>> > > >
>> > > > HTH,
>> > > > -Alex
>> > > >
>> > > > On 9/4/19, 3:11 AM, "Greg Dove" <
>> greg.dove@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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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.
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
Thanks for checking that.
child is specified in 13.4.4.6 and essentially calls [[Get]]
(After cycling through this kind of thing a few times, I found the easiest
way to find methods is to search in the spec for 'e.mehodName' which gets
you XML.prototype.methodName)
and [[Get]] is specified in 9.1.1.1
So I assume it is a bug. As discussed I think it is good to match the
behavior. If we can verify 100% it is off spec, we could add something as a
define to avoid the 'fix' for people who want to be on-spec.
On Sat, Sep 7, 2019 at 11:30 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> FWIW, I went and looked at the ABC.
>
> The first syntax sets up a getProperty just like any other property
> fetch. The second (as expected) calls "child()". I've looked at the E4X
> spec a couple of times now and cannot see where the behavior we are seeing
> in child() is specified so I am going to assume it is a bug, and that we
> just have to live with it.
>
> I expect that getProperty does not call child(). I haven't looked at the
> AVM code to see what getProperty does for XML.
>
> HTH,
> -Alex
>
> On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Oh that is a good find! And perfect timing :)
> Thanks Alex, I am pretty sure that answers the question! (It quite
> specifically describes what I was seeing, I don't think it makes a
> difference whether it is attributes or elements)
>
> And yes, I agree it should be the implemented to give the same results
> as
> swf.
> I will add this to the other work I have over the weekend before I get
> it
> in. It only seems relevant for when child (or descendants, I don't
> expect
> that will be different) method call is explicit (as opposed to the
> compiler-generated method calls from e4x 'member access') with QName
> argument only. I think most people won't use this approach with
> explicit
> QNames, but it is one of those things that will cause misery if you do
> (when porting legacy code), so it should be the same IMO also. I will
> make
> sure it costs nothing for the more common (other) use cases. I have
> had to
> do something similar to support 'use namespace' directives which
> create a
> MultiName-like variant of QName in my local change that includes the
> default namespace and the specified set of other 'used'/open namespace
> uris
> in the current execution scope. (That 'use namespace' pattern was being
> used quite a bit in the codebase I have been working on)
>
> Thanks again, that will save me investigating it with bytecode.
>
>
>
>
> On Fri, Sep 6, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Out of pure random chance, I was starting the migration of WebService
> > which had a dependency on XMLUtil which contained the comment:
> >
> > //xml.attribute(QName) will also return local no-namespace
> > attributes
> > //even if we are looking for a specific full qualified name.
> >
> > So, still could be a bug in Flash, but maybe we should just make our
> > implementation work the same way to reduce migration effort in case
> someone
> > is relying on this behavior.
> >
> > Thoughts?
> > -Alex
> >
> > On 9/4/19, 1:47 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
> >
> > I read the example incorrectly. So yeah, it should return 0 and
> empty
> > string in both cases, IMO. There might be some subtlety in how the
> > namespaces are specified for a QName or how QName works in child().
> >
> > HTH,
> > -Alex
> >
> > On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com> wrote:
> >
> > Good idea. I'll check the swf output, although probably
> tomorrow
> > as I need
> > to focus on something else today.
> > ' I would have expected both to return "1" and the node. '
> >
> > In that example I would expect the opposite (because the the
> link
> > node
> > being returned by the second query is not in the specified
> explicit
> > namespace of the QName), so I am curious to understand why
> you
> > think
> > that... maybe it will help me understand.
> >
> > When I use feed.atom::link I expect only links that are
> bound to
> > the atom
> > namespace (uri). Because <link ... /> node has no prefix
> bound to
> > the uri
> > that the atom namespace defines, and it is in the default
> > namespace, I
> > would not expect it to be included.
> > At the moment the atom::link part is working the same as
> swf, so
> > I'm happy
> > with that at least for what I am working on. All the explicit
> > calls to
> > child(name) or descendants(name) in the app I am working on
> use
> > string args
> > so these all work correctly as well.
> > I'm just trying to cover things for the future... while my
> head is
> > still in
> > this stuff.
> >
> >
> >
> > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > > Speaking of multinames, what is the ABC code generated by
> the
> > Flex
> > > compiler for the two cases? It might contain some clues.
> I
> > would have
> > > expected both to return "1" and the node. But I did see
> in the
> > spec the
> > > notion of "InScopeNamespaces". I generally hate reading
> specs
> > like these
> > > so I am not very knowledgeable about what the spec says.
> > >
> > > HTH,
> > > -Alex
> > >
> > > On 9/4/19, 11:05 AM, "Greg Dove" <gr...@gmail.com>
> wrote:
> > >
> > > 'Have you rummaged through the spec?'
> > > Yes, if anything I probably need to step away from it
> and
> > experience
> > > the
> > > world a bit more! I have been focused on each portion
> of the
> > spec as I
> > > create unit tests and verify things between the player
> and
> > the Royale
> > > implementation.
> > > I've also glanced a few times in the avmplus code, and
> that
> > has
> > > provided
> > > some clues where things were intentionally implemented
> > slightly off
> > > spec,
> > > but still a few things to figure out. However I am
> making
> > progress - I
> > > think I have everything covered for the codebase I am
> > working on....
> > > but I
> > > will keep going beyond that. For that example above, I
> might
> > be wrong,
> > > but
> > > I suspect it is using a multiname with default
> namespace
> > included for
> > > the
> > > explicit call case in the player, but not for the
> implicit
> > one, but I
> > > am
> > > not yet sure why. I will double-check the spec
> though...
> > >
> > >
> > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
> > <ah...@adobe.com.invalid>
> > > wrote:
> > >
> > > > Don't know. Have you rummaged through the spec?
> > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637033071564533291&sdata=N1f5b20jjPP4SHWNM4hyleXMJW6qW%2FItnmgJ7oU73Hs%3D&reserved=0
> > > >
> > > > HTH,
> > > > -Alex
> > > >
> > > > On 9/4/19, 3:11 AM, "Greg Dove" <greg.dove@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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
Re: Heads up on XML
Posted by Alex Harui <ah...@adobe.com.INVALID>.
FWIW, I went and looked at the ABC.
The first syntax sets up a getProperty just like any other property fetch. The second (as expected) calls "child()". I've looked at the E4X spec a couple of times now and cannot see where the behavior we are seeing in child() is specified so I am going to assume it is a bug, and that we just have to live with it.
I expect that getProperty does not call child(). I haven't looked at the AVM code to see what getProperty does for XML.
HTH,
-Alex
On 9/5/19, 12:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
Oh that is a good find! And perfect timing :)
Thanks Alex, I am pretty sure that answers the question! (It quite
specifically describes what I was seeing, I don't think it makes a
difference whether it is attributes or elements)
And yes, I agree it should be the implemented to give the same results as
swf.
I will add this to the other work I have over the weekend before I get it
in. It only seems relevant for when child (or descendants, I don't expect
that will be different) method call is explicit (as opposed to the
compiler-generated method calls from e4x 'member access') with QName
argument only. I think most people won't use this approach with explicit
QNames, but it is one of those things that will cause misery if you do
(when porting legacy code), so it should be the same IMO also. I will make
sure it costs nothing for the more common (other) use cases. I have had to
do something similar to support 'use namespace' directives which create a
MultiName-like variant of QName in my local change that includes the
default namespace and the specified set of other 'used'/open namespace uris
in the current execution scope. (That 'use namespace' pattern was being
used quite a bit in the codebase I have been working on)
Thanks again, that will save me investigating it with bytecode.
On Fri, Sep 6, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Out of pure random chance, I was starting the migration of WebService
> which had a dependency on XMLUtil which contained the comment:
>
> //xml.attribute(QName) will also return local no-namespace
> attributes
> //even if we are looking for a specific full qualified name.
>
> So, still could be a bug in Flash, but maybe we should just make our
> implementation work the same way to reduce migration effort in case someone
> is relying on this behavior.
>
> Thoughts?
> -Alex
>
> On 9/4/19, 1:47 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
>
> I read the example incorrectly. So yeah, it should return 0 and empty
> string in both cases, IMO. There might be some subtlety in how the
> namespaces are specified for a QName or how QName works in child().
>
> HTH,
> -Alex
>
> On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Good idea. I'll check the swf output, although probably tomorrow
> as I need
> to focus on something else today.
> ' I would have expected both to return "1" and the node. '
>
> In that example I would expect the opposite (because the the link
> node
> being returned by the second query is not in the specified explicit
> namespace of the QName), so I am curious to understand why you
> think
> that... maybe it will help me understand.
>
> When I use feed.atom::link I expect only links that are bound to
> the atom
> namespace (uri). Because <link ... /> node has no prefix bound to
> the uri
> that the atom namespace defines, and it is in the default
> namespace, I
> would not expect it to be included.
> At the moment the atom::link part is working the same as swf, so
> I'm happy
> with that at least for what I am working on. All the explicit
> calls to
> child(name) or descendants(name) in the app I am working on use
> string args
> so these all work correctly as well.
> I'm just trying to cover things for the future... while my head is
> still in
> this stuff.
>
>
>
> On Thu, Sep 5, 2019 at 6:11 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Speaking of multinames, what is the ABC code generated by the
> Flex
> > compiler for the two cases? It might contain some clues. I
> would have
> > expected both to return "1" and the node. But I did see in the
> spec the
> > notion of "InScopeNamespaces". I generally hate reading specs
> like these
> > so I am not very knowledgeable about what the spec says.
> >
> > HTH,
> > -Alex
> >
> > On 9/4/19, 11:05 AM, "Greg Dove" <gr...@gmail.com> wrote:
> >
> > 'Have you rummaged through the spec?'
> > Yes, if anything I probably need to step away from it and
> experience
> > the
> > world a bit more! I have been focused on each portion of the
> spec as I
> > create unit tests and verify things between the player and
> the Royale
> > implementation.
> > I've also glanced a few times in the avmplus code, and that
> has
> > provided
> > some clues where things were intentionally implemented
> slightly off
> > spec,
> > but still a few things to figure out. However I am making
> progress - I
> > think I have everything covered for the codebase I am
> working on....
> > but I
> > will keep going beyond that. For that example above, I might
> be wrong,
> > but
> > I suspect it is using a multiname with default namespace
> included for
> > the
> > explicit call case in the player, but not for the implicit
> one, but I
> > am
> > not yet sure why. I will double-check the spec though...
> >
> >
> > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > > Don't know. Have you rummaged through the spec?
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637033071564533291&sdata=N1f5b20jjPP4SHWNM4hyleXMJW6qW%2FItnmgJ7oU73Hs%3D&reserved=0
> > >
> > > HTH,
> > > -Alex
> > >
> > > On 9/4/19, 3:11 AM, "Greg Dove" <gr...@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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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.
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
Oh that is a good find! And perfect timing :)
Thanks Alex, I am pretty sure that answers the question! (It quite
specifically describes what I was seeing, I don't think it makes a
difference whether it is attributes or elements)
And yes, I agree it should be the implemented to give the same results as
swf.
I will add this to the other work I have over the weekend before I get it
in. It only seems relevant for when child (or descendants, I don't expect
that will be different) method call is explicit (as opposed to the
compiler-generated method calls from e4x 'member access') with QName
argument only. I think most people won't use this approach with explicit
QNames, but it is one of those things that will cause misery if you do
(when porting legacy code), so it should be the same IMO also. I will make
sure it costs nothing for the more common (other) use cases. I have had to
do something similar to support 'use namespace' directives which create a
MultiName-like variant of QName in my local change that includes the
default namespace and the specified set of other 'used'/open namespace uris
in the current execution scope. (That 'use namespace' pattern was being
used quite a bit in the codebase I have been working on)
Thanks again, that will save me investigating it with bytecode.
On Fri, Sep 6, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Out of pure random chance, I was starting the migration of WebService
> which had a dependency on XMLUtil which contained the comment:
>
> //xml.attribute(QName) will also return local no-namespace
> attributes
> //even if we are looking for a specific full qualified name.
>
> So, still could be a bug in Flash, but maybe we should just make our
> implementation work the same way to reduce migration effort in case someone
> is relying on this behavior.
>
> Thoughts?
> -Alex
>
> On 9/4/19, 1:47 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
>
> I read the example incorrectly. So yeah, it should return 0 and empty
> string in both cases, IMO. There might be some subtlety in how the
> namespaces are specified for a QName or how QName works in child().
>
> HTH,
> -Alex
>
> On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Good idea. I'll check the swf output, although probably tomorrow
> as I need
> to focus on something else today.
> ' I would have expected both to return "1" and the node. '
>
> In that example I would expect the opposite (because the the link
> node
> being returned by the second query is not in the specified explicit
> namespace of the QName), so I am curious to understand why you
> think
> that... maybe it will help me understand.
>
> When I use feed.atom::link I expect only links that are bound to
> the atom
> namespace (uri). Because <link ... /> node has no prefix bound to
> the uri
> that the atom namespace defines, and it is in the default
> namespace, I
> would not expect it to be included.
> At the moment the atom::link part is working the same as swf, so
> I'm happy
> with that at least for what I am working on. All the explicit
> calls to
> child(name) or descendants(name) in the app I am working on use
> string args
> so these all work correctly as well.
> I'm just trying to cover things for the future... while my head is
> still in
> this stuff.
>
>
>
> On Thu, Sep 5, 2019 at 6:11 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Speaking of multinames, what is the ABC code generated by the
> Flex
> > compiler for the two cases? It might contain some clues. I
> would have
> > expected both to return "1" and the node. But I did see in the
> spec the
> > notion of "InScopeNamespaces". I generally hate reading specs
> like these
> > so I am not very knowledgeable about what the spec says.
> >
> > HTH,
> > -Alex
> >
> > On 9/4/19, 11:05 AM, "Greg Dove" <gr...@gmail.com> wrote:
> >
> > 'Have you rummaged through the spec?'
> > Yes, if anything I probably need to step away from it and
> experience
> > the
> > world a bit more! I have been focused on each portion of the
> spec as I
> > create unit tests and verify things between the player and
> the Royale
> > implementation.
> > I've also glanced a few times in the avmplus code, and that
> has
> > provided
> > some clues where things were intentionally implemented
> slightly off
> > spec,
> > but still a few things to figure out. However I am making
> progress - I
> > think I have everything covered for the codebase I am
> working on....
> > but I
> > will keep going beyond that. For that example above, I might
> be wrong,
> > but
> > I suspect it is using a multiname with default namespace
> included for
> > the
> > explicit call case in the player, but not for the implicit
> one, but I
> > am
> > not yet sure why. I will double-check the spec though...
> >
> >
> > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > > Don't know. Have you rummaged through the spec?
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637032268439916076&sdata=lY0hDgIEf68pv9fzW6NopGDv5cBdR2wfB49npPDcT7Y%3D&reserved=0
> > >
> > > HTH,
> > > -Alex
> > >
> > > On 9/4/19, 3:11 AM, "Greg Dove" <gr...@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%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032268439916076&sdata=65p3lsTIh3r%2BUB86WbQ%2F75Fcj8WhIAr9SuWxSS5se8k%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%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032268439916076&sdata=65p3lsTIh3r%2BUB86WbQ%2F75Fcj8WhIAr9SuWxSS5se8k%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%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032268439916076&sdata=65p3lsTIh3r%2BUB86WbQ%2F75Fcj8WhIAr9SuWxSS5se8k%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.
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
>
Re: Heads up on XML
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Out of pure random chance, I was starting the migration of WebService which had a dependency on XMLUtil which contained the comment:
//xml.attribute(QName) will also return local no-namespace attributes
//even if we are looking for a specific full qualified name.
So, still could be a bug in Flash, but maybe we should just make our implementation work the same way to reduce migration effort in case someone is relying on this behavior.
Thoughts?
-Alex
On 9/4/19, 1:47 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
I read the example incorrectly. So yeah, it should return 0 and empty string in both cases, IMO. There might be some subtlety in how the namespaces are specified for a QName or how QName works in child().
HTH,
-Alex
On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com> wrote:
Good idea. I'll check the swf output, although probably tomorrow as I need
to focus on something else today.
' I would have expected both to return "1" and the node. '
In that example I would expect the opposite (because the the link node
being returned by the second query is not in the specified explicit
namespace of the QName), so I am curious to understand why you think
that... maybe it will help me understand.
When I use feed.atom::link I expect only links that are bound to the atom
namespace (uri). Because <link ... /> node has no prefix bound to the uri
that the atom namespace defines, and it is in the default namespace, I
would not expect it to be included.
At the moment the atom::link part is working the same as swf, so I'm happy
with that at least for what I am working on. All the explicit calls to
child(name) or descendants(name) in the app I am working on use string args
so these all work correctly as well.
I'm just trying to cover things for the future... while my head is still in
this stuff.
On Thu, Sep 5, 2019 at 6:11 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Speaking of multinames, what is the ABC code generated by the Flex
> compiler for the two cases? It might contain some clues. I would have
> expected both to return "1" and the node. But I did see in the spec the
> notion of "InScopeNamespaces". I generally hate reading specs like these
> so I am not very knowledgeable about what the spec says.
>
> HTH,
> -Alex
>
> On 9/4/19, 11:05 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
> 'Have you rummaged through the spec?'
> Yes, if anything I probably need to step away from it and experience
> the
> world a bit more! I have been focused on each portion of the spec as I
> create unit tests and verify things between the player and the Royale
> implementation.
> I've also glanced a few times in the avmplus code, and that has
> provided
> some clues where things were intentionally implemented slightly off
> spec,
> but still a few things to figure out. However I am making progress - I
> think I have everything covered for the codebase I am working on....
> but I
> will keep going beyond that. For that example above, I might be wrong,
> but
> I suspect it is using a multiname with default namespace included for
> the
> explicit call case in the player, but not for the implicit one, but I
> am
> not yet sure why. I will double-check the spec though...
>
>
> On Thu, Sep 5, 2019 at 4:02 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Don't know. Have you rummaged through the spec?
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637032268439916076&sdata=lY0hDgIEf68pv9fzW6NopGDv5cBdR2wfB49npPDcT7Y%3D&reserved=0
> >
> > HTH,
> > -Alex
> >
> > On 9/4/19, 3:11 AM, "Greg Dove" <gr...@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%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032268439916076&sdata=65p3lsTIh3r%2BUB86WbQ%2F75Fcj8WhIAr9SuWxSS5se8k%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%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032268439916076&sdata=65p3lsTIh3r%2BUB86WbQ%2F75Fcj8WhIAr9SuWxSS5se8k%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%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032268439916076&sdata=65p3lsTIh3r%2BUB86WbQ%2F75Fcj8WhIAr9SuWxSS5se8k%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.
> >
> >
> >
>
>
>
Re: Heads up on XML
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I read the example incorrectly. So yeah, it should return 0 and empty string in both cases, IMO. There might be some subtlety in how the namespaces are specified for a QName or how QName works in child().
HTH,
-Alex
On 9/4/19, 11:33 AM, "Greg Dove" <gr...@gmail.com> wrote:
Good idea. I'll check the swf output, although probably tomorrow as I need
to focus on something else today.
' I would have expected both to return "1" and the node. '
In that example I would expect the opposite (because the the link node
being returned by the second query is not in the specified explicit
namespace of the QName), so I am curious to understand why you think
that... maybe it will help me understand.
When I use feed.atom::link I expect only links that are bound to the atom
namespace (uri). Because <link ... /> node has no prefix bound to the uri
that the atom namespace defines, and it is in the default namespace, I
would not expect it to be included.
At the moment the atom::link part is working the same as swf, so I'm happy
with that at least for what I am working on. All the explicit calls to
child(name) or descendants(name) in the app I am working on use string args
so these all work correctly as well.
I'm just trying to cover things for the future... while my head is still in
this stuff.
On Thu, Sep 5, 2019 at 6:11 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Speaking of multinames, what is the ABC code generated by the Flex
> compiler for the two cases? It might contain some clues. I would have
> expected both to return "1" and the node. But I did see in the spec the
> notion of "InScopeNamespaces". I generally hate reading specs like these
> so I am not very knowledgeable about what the spec says.
>
> HTH,
> -Alex
>
> On 9/4/19, 11:05 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
> 'Have you rummaged through the spec?'
> Yes, if anything I probably need to step away from it and experience
> the
> world a bit more! I have been focused on each portion of the spec as I
> create unit tests and verify things between the player and the Royale
> implementation.
> I've also glanced a few times in the avmplus code, and that has
> provided
> some clues where things were intentionally implemented slightly off
> spec,
> but still a few things to figure out. However I am making progress - I
> think I have everything covered for the codebase I am working on....
> but I
> will keep going beyond that. For that example above, I might be wrong,
> but
> I suspect it is using a multiname with default namespace included for
> the
> explicit call case in the player, but not for the implicit one, but I
> am
> not yet sure why. I will double-check the spec though...
>
>
> On Thu, Sep 5, 2019 at 4:02 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Don't know. Have you rummaged through the spec?
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C1ade69b1ed4844c4371f08d731665509%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637032187917207574&sdata=gFsLnUcRjOioiOWViLttSkIBsISlcN%2F9AlGhpC4rX1c%3D&reserved=0
> >
> > HTH,
> > -Alex
> >
> > On 9/4/19, 3:11 AM, "Greg Dove" <gr...@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%7C1ade69b1ed4844c4371f08d731665509%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032187917217570&sdata=kIqpE59H4K4lrL4YCGqKTDmimTt%2F9v0YC5yPAQdZX3w%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%7C1ade69b1ed4844c4371f08d731665509%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032187917217570&sdata=kIqpE59H4K4lrL4YCGqKTDmimTt%2F9v0YC5yPAQdZX3w%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%7C1ade69b1ed4844c4371f08d731665509%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032187917217570&sdata=kIqpE59H4K4lrL4YCGqKTDmimTt%2F9v0YC5yPAQdZX3w%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.
> >
> >
> >
>
>
>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
Good idea. I'll check the swf output, although probably tomorrow as I need
to focus on something else today.
' I would have expected both to return "1" and the node. '
In that example I would expect the opposite (because the the link node
being returned by the second query is not in the specified explicit
namespace of the QName), so I am curious to understand why you think
that... maybe it will help me understand.
When I use feed.atom::link I expect only links that are bound to the atom
namespace (uri). Because <link ... /> node has no prefix bound to the uri
that the atom namespace defines, and it is in the default namespace, I
would not expect it to be included.
At the moment the atom::link part is working the same as swf, so I'm happy
with that at least for what I am working on. All the explicit calls to
child(name) or descendants(name) in the app I am working on use string args
so these all work correctly as well.
I'm just trying to cover things for the future... while my head is still in
this stuff.
On Thu, Sep 5, 2019 at 6:11 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Speaking of multinames, what is the ABC code generated by the Flex
> compiler for the two cases? It might contain some clues. I would have
> expected both to return "1" and the node. But I did see in the spec the
> notion of "InScopeNamespaces". I generally hate reading specs like these
> so I am not very knowledgeable about what the spec says.
>
> HTH,
> -Alex
>
> On 9/4/19, 11:05 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
> 'Have you rummaged through the spec?'
> Yes, if anything I probably need to step away from it and experience
> the
> world a bit more! I have been focused on each portion of the spec as I
> create unit tests and verify things between the player and the Royale
> implementation.
> I've also glanced a few times in the avmplus code, and that has
> provided
> some clues where things were intentionally implemented slightly off
> spec,
> but still a few things to figure out. However I am making progress - I
> think I have everything covered for the codebase I am working on....
> but I
> will keep going beyond that. For that example above, I might be wrong,
> but
> I suspect it is using a multiname with default namespace included for
> the
> explicit call case in the player, but not for the implicit one, but I
> am
> not yet sure why. I will double-check the spec though...
>
>
> On Thu, Sep 5, 2019 at 4:02 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Don't know. Have you rummaged through the spec?
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C8b56d09a6a314e2d55aa08d731628822%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637032171567244570&sdata=8LW6weJevEYXpCx%2FEdegixnO%2BgVXDasn3gjKZFOrPFI%3D&reserved=0
> >
> > HTH,
> > -Alex
> >
> > On 9/4/19, 3:11 AM, "Greg Dove" <gr...@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%7C8b56d09a6a314e2d55aa08d731628822%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032171567244570&sdata=MGdQ%2FHKuHFqdLQtVw2I%2FO4OWBI5sjyDH7PxEu9Ezmh4%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%7C8b56d09a6a314e2d55aa08d731628822%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032171567254566&sdata=zKzFOcxizdYggXkjT2u6vXTRq6j4ulDquAwuH49WLTY%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%7C8b56d09a6a314e2d55aa08d731628822%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032171567254566&sdata=zKzFOcxizdYggXkjT2u6vXTRq6j4ulDquAwuH49WLTY%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.
> >
> >
> >
>
>
>
Re: Heads up on XML
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Speaking of multinames, what is the ABC code generated by the Flex compiler for the two cases? It might contain some clues. I would have expected both to return "1" and the node. But I did see in the spec the notion of "InScopeNamespaces". I generally hate reading specs like these so I am not very knowledgeable about what the spec says.
HTH,
-Alex
On 9/4/19, 11:05 AM, "Greg Dove" <gr...@gmail.com> wrote:
'Have you rummaged through the spec?'
Yes, if anything I probably need to step away from it and experience the
world a bit more! I have been focused on each portion of the spec as I
create unit tests and verify things between the player and the Royale
implementation.
I've also glanced a few times in the avmplus code, and that has provided
some clues where things were intentionally implemented slightly off spec,
but still a few things to figure out. However I am making progress - I
think I have everything covered for the codebase I am working on.... but I
will keep going beyond that. For that example above, I might be wrong, but
I suspect it is using a multiname with default namespace included for the
explicit call case in the player, but not for the implicit one, but I am
not yet sure why. I will double-check the spec though...
On Thu, Sep 5, 2019 at 4:02 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Don't know. Have you rummaged through the spec?
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C8b56d09a6a314e2d55aa08d731628822%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637032171567244570&sdata=8LW6weJevEYXpCx%2FEdegixnO%2BgVXDasn3gjKZFOrPFI%3D&reserved=0
>
> HTH,
> -Alex
>
> On 9/4/19, 3:11 AM, "Greg Dove" <gr...@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%7C8b56d09a6a314e2d55aa08d731628822%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032171567244570&sdata=MGdQ%2FHKuHFqdLQtVw2I%2FO4OWBI5sjyDH7PxEu9Ezmh4%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%7C8b56d09a6a314e2d55aa08d731628822%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032171567254566&sdata=zKzFOcxizdYggXkjT2u6vXTRq6j4ulDquAwuH49WLTY%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%7C8b56d09a6a314e2d55aa08d731628822%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032171567254566&sdata=zKzFOcxizdYggXkjT2u6vXTRq6j4ulDquAwuH49WLTY%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.
>
>
>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
'Have you rummaged through the spec?'
Yes, if anything I probably need to step away from it and experience the
world a bit more! I have been focused on each portion of the spec as I
create unit tests and verify things between the player and the Royale
implementation.
I've also glanced a few times in the avmplus code, and that has provided
some clues where things were intentionally implemented slightly off spec,
but still a few things to figure out. However I am making progress - I
think I have everything covered for the codebase I am working on.... but I
will keep going beyond that. For that example above, I might be wrong, but
I suspect it is using a multiname with default namespace included for the
explicit call case in the player, but not for the implicit one, but I am
not yet sure why. I will double-check the spec though...
On Thu, Sep 5, 2019 at 4:02 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Don't know. Have you rummaged through the spec?
>
> https://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/Ecma-357.pdf
>
> HTH,
> -Alex
>
> On 9/4/19, 3:11 AM, "Greg Dove" <gr...@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%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971&sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%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%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971&sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%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%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971&sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%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.
>
>
>
Re: Heads up on XML
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Don't know. Have you rummaged through the spec?
https://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/Ecma-357.pdf
HTH,
-Alex
On 9/4/19, 3:11 AM, "Greg Dove" <gr...@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%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971&sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%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%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971&sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%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%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971&sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%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.
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
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 <pi...@gmail.com>
wrote:
> Hi Greg,
>
> Questions inline.
>
> pon., 7 paź 2019 o 01:49 Greg Dove <gr...@gmail.com> 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 <gr...@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, <pi...@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://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 <ha...@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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="
> 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>*
>
Re: Heads up on XML
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Greg,
Questions inline.
pon., 7 paź 2019 o 01:49 Greg Dove <gr...@gmail.com> 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 <gr...@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, <pi...@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://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 <ha...@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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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>*
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
Ok, thanks Alex, I will do that tomorrow.
On Mon, Oct 7, 2019 at 4:02 PM Alex Harui <ah...@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" <gr...@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 <gr...@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, <piotrzarzycki21@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 <ha...@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 <gr...@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 <gr...@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 <ha...@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 <gr...@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
> >*
> >>
> >
>
>
>
Re: Heads up on XML
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@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 <gr...@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, <pi...@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 <ha...@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 <gr...@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 <gr...@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 <ha...@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 <gr...@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>*
>>
>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
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 <gr...@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, <pi...@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://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 <ha...@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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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>*
>>
>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
Hi Piotr, I will check that in the morning local time... in about 8 hours.
On Sun, 6 Oct 2019, 21:54 Piotr Zarzycki, <pi...@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://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 <ha...@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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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>*
>
Re: Heads up on XML
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ha...@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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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>*
Re: Heads up on XML
Posted by Harbs <ha...@gmail.com>.
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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
>>>
>>>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
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 <gr...@gmail.com> wrote:
>
> Oh - just saw this. Thanks.
> Please ignore my comments in the other thread :).
>
>
> On Fri, Nov 29, 2019 at 6:12 AM Harbs <ha...@gmail.com> 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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
>> >>>
>> >>>
>>
>>
Re: Heads up on XML
Posted by Harbs <ha...@gmail.com>.
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 <gr...@gmail.com> 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 <ha...@gmail.com> 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 <gr...@gmail.com> wrote:
>>>
>>> You mean this (hopefully the xml angle brackets won't be mangled in your
>>> view of this)?
>>>
>>> var xml:XML = <root/>;
>>> xml.appendChild("test1");
>>> xml.appendChild("test2");
>>> xml.appendChild(<element/>);
>>> xml.appendChild("test3");
>>> xml.appendChild("test4");
>>>
>>>
>>> trace(xml.toXMLString())
>>> output in swf:
>>> <root>
>>> test1
>>> test2
>>> <element/>
>>> <element>test3</element>
>>> <element>test4</element>
>>> </root>
>>>
>>>
>>>
>>> On Fri, Nov 29, 2019 at 7:12 AM Harbs <ha...@gmail.com> wrote:
>>>
>>>> I can’t imagine where <element>test3</element> comes from when you
>> append
>>>> “test3”...
>>>>
>>>> It should be a text node. No?
>>>>
>>>>> On Nov 28, 2019, at 8:09 PM, Greg Dove <gr...@gmail.com> wrote:
>>>>>
>>>>> OK, I will check it now.
>>>>>
>>>>> On Fri, Nov 29, 2019 at 7:08 AM Harbs <ha...@gmail.com> 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 <gr...@gmail.com> wrote:
>>>>>>>
>>>>>>> Oh - just saw this. Thanks.
>>>>>>> Please ignore my comments in the other thread :).
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 29, 2019 at 6:12 AM Harbs <ha...@gmail.com> 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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
' 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 <ha...@gmail.com> 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 <gr...@gmail.com> wrote:
> >
> > You mean this (hopefully the xml angle brackets won't be mangled in your
> > view of this)?
> >
> > var xml:XML = <root/>;
> > xml.appendChild("test1");
> > xml.appendChild("test2");
> > xml.appendChild(<element/>);
> > xml.appendChild("test3");
> > xml.appendChild("test4");
> >
> >
> > trace(xml.toXMLString())
> > output in swf:
> > <root>
> > test1
> > test2
> > <element/>
> > <element>test3</element>
> > <element>test4</element>
> > </root>
> >
> >
> >
> > On Fri, Nov 29, 2019 at 7:12 AM Harbs <ha...@gmail.com> wrote:
> >
> >> I can’t imagine where <element>test3</element> comes from when you
> append
> >> “test3”...
> >>
> >> It should be a text node. No?
> >>
> >>> On Nov 28, 2019, at 8:09 PM, Greg Dove <gr...@gmail.com> wrote:
> >>>
> >>> OK, I will check it now.
> >>>
> >>> On Fri, Nov 29, 2019 at 7:08 AM Harbs <ha...@gmail.com> 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 <gr...@gmail.com> wrote:
> >>>>>
> >>>>> Oh - just saw this. Thanks.
> >>>>> Please ignore my comments in the other thread :).
> >>>>>
> >>>>>
> >>>>> On Fri, Nov 29, 2019 at 6:12 AM Harbs <ha...@gmail.com> 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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Heads up on XML
Posted by Harbs <ha...@gmail.com>.
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 <gr...@gmail.com> wrote:
>
> You mean this (hopefully the xml angle brackets won't be mangled in your
> view of this)?
>
> var xml:XML = <root/>;
> xml.appendChild("test1");
> xml.appendChild("test2");
> xml.appendChild(<element/>);
> xml.appendChild("test3");
> xml.appendChild("test4");
>
>
> trace(xml.toXMLString())
> output in swf:
> <root>
> test1
> test2
> <element/>
> <element>test3</element>
> <element>test4</element>
> </root>
>
>
>
> On Fri, Nov 29, 2019 at 7:12 AM Harbs <ha...@gmail.com> wrote:
>
>> I can’t imagine where <element>test3</element> comes from when you append
>> “test3”...
>>
>> It should be a text node. No?
>>
>>> On Nov 28, 2019, at 8:09 PM, Greg Dove <gr...@gmail.com> wrote:
>>>
>>> OK, I will check it now.
>>>
>>> On Fri, Nov 29, 2019 at 7:08 AM Harbs <ha...@gmail.com> 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 <gr...@gmail.com> wrote:
>>>>>
>>>>> Oh - just saw this. Thanks.
>>>>> Please ignore my comments in the other thread :).
>>>>>
>>>>>
>>>>> On Fri, Nov 29, 2019 at 6:12 AM Harbs <ha...@gmail.com> 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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
You mean this (hopefully the xml angle brackets won't be mangled in your
view of this)?
var xml:XML = <root/>;
xml.appendChild("test1");
xml.appendChild("test2");
xml.appendChild(<element/>);
xml.appendChild("test3");
xml.appendChild("test4");
trace(xml.toXMLString())
output in swf:
<root>
test1
test2
<element/>
<element>test3</element>
<element>test4</element>
</root>
On Fri, Nov 29, 2019 at 7:12 AM Harbs <ha...@gmail.com> wrote:
> I can’t imagine where <element>test3</element> comes from when you append
> “test3”...
>
> It should be a text node. No?
>
> > On Nov 28, 2019, at 8:09 PM, Greg Dove <gr...@gmail.com> wrote:
> >
> > OK, I will check it now.
> >
> > On Fri, Nov 29, 2019 at 7:08 AM Harbs <ha...@gmail.com> 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 <gr...@gmail.com> wrote:
> >>>
> >>> Oh - just saw this. Thanks.
> >>> Please ignore my comments in the other thread :).
> >>>
> >>>
> >>> On Fri, Nov 29, 2019 at 6:12 AM Harbs <ha...@gmail.com> 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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Heads up on XML
Posted by Harbs <ha...@gmail.com>.
I can’t imagine where <element>test3</element> comes from when you append “test3”...
It should be a text node. No?
> On Nov 28, 2019, at 8:09 PM, Greg Dove <gr...@gmail.com> wrote:
>
> OK, I will check it now.
>
> On Fri, Nov 29, 2019 at 7:08 AM Harbs <ha...@gmail.com> 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 <gr...@gmail.com> wrote:
>>>
>>> Oh - just saw this. Thanks.
>>> Please ignore my comments in the other thread :).
>>>
>>>
>>> On Fri, Nov 29, 2019 at 6:12 AM Harbs <ha...@gmail.com> 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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
OK, I will check it now.
On Fri, Nov 29, 2019 at 7:08 AM Harbs <ha...@gmail.com> 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 <gr...@gmail.com> wrote:
> >
> > Oh - just saw this. Thanks.
> > Please ignore my comments in the other thread :).
> >
> >
> > On Fri, Nov 29, 2019 at 6:12 AM Harbs <ha...@gmail.com> 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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
> >>>>>
> >>>>>
> >>
> >>
>
>
Re: Heads up on XML
Posted by Harbs <ha...@gmail.com>.
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 <gr...@gmail.com> wrote:
>
> Oh - just saw this. Thanks.
> Please ignore my comments in the other thread :).
>
>
> On Fri, Nov 29, 2019 at 6:12 AM Harbs <ha...@gmail.com> 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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
>>>>>
>>>>>
>>
>>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
Oh - just saw this. Thanks.
Please ignore my comments in the other thread :).
On Fri, Nov 29, 2019 at 6:12 AM Harbs <ha...@gmail.com> 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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
> >>>
> >>>
>
>
Re: Heads up on XML
Posted by Harbs <ha...@gmail.com>.
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 <gr...@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 <gr...@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 <ha...@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 <gr...@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="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.
>>>
>>>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
@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 <gr...@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 <ha...@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 <gr...@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="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.
>>
>>
Re: Heads up on XML
Posted by Greg Dove <gr...@gmail.com>.
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 <ha...@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 <gr...@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="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.
>
>
Re: Heads up on XML
Posted by Harbs <ha...@gmail.com>.
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 <gr...@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="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.