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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > >> 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" <[email protected]> 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 <[email protected]> > >>> 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 > <[email protected] > >>> > > >>> > 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" <[email protected]> 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 > >>> <[email protected]> > >>> >> 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" <[email protected] > > > >>> 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" <[email protected] > > > >>> 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 > >>> >> <[email protected]> > >>> >> > 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" < > >>> [email protected]> > >>> >> 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 > >>> >> > <[email protected]> > >>> >> > > 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" < > >>> >> [email protected]> > >>> >> > wrote: > >>> >> > > > > >>> >> > > > This is particularly for Harbs and > >>> Yishay, as I > >>> >> think > >>> >> > you are > >>> >> > > both (or > >>> >> > > > both > >>> >> > > > have been) using XML quite a bit. I > have > >>> quite > >>> >> a few > >>> >> > fixes > >>> >> > > coming. All > >>> >> > > > with tests that match on swf and js. > >>> >> > > > > >>> >> > > > I am currently working to demonstrate > >>> proof of > >>> >> concept > >>> >> > to a > >>> >> > > prospective > >>> >> > > > client for migration of a Flex app. > The > >>> app > >>> >> makes > >>> >> > extensive use > >>> >> > > of e4x > >>> >> > > > and > >>> >> > > > uses a bunch of features that I expect > >>> had not > >>> >> > received attention > >>> >> > > > previously, because they were > originally > >>> either > >>> >> not > >>> >> > working with > >>> >> > > the > >>> >> > > > codebase I am porting, or i think some > >>> even > >>> >> caused > >>> >> > errors in the > >>> >> > > > javascript > >>> >> > > > output. > >>> >> > > > > >>> >> > > > So I have spent the last several days > >>> almost > >>> >> full time > >>> >> > figuring > >>> >> > > things > >>> >> > > > out > >>> >> > > > and working on fixes, between the > >>> compiler and > >>> >> > emulation classes. > >>> >> > > > All the previous XML tests continue to > >>> pass, > >>> >> but I > >>> >> > have many > >>> >> > > more unit > >>> >> > > > tests and fixes lined up for the > >>> following: > >>> >> > > > > >>> >> > > > namespace directives > >>> >> > > > default xml namespace > >>> >> > > > use namespace (multiple) > >>> >> > > > > >>> >> > > > a number of fixes for xml filtering, > >>> including: > >>> >> > > > -'this' resolves correctly in filters > >>> that > >>> >> include > >>> >> > external > >>> >> > > references > >>> >> > > > from > >>> >> > > > the fitler expression to the 'this' > scope > >>> >> > > > -handles alternate ordering of > >>> comparisons > >>> >> between XML > >>> >> > 'getters' > >>> >> > > and > >>> >> > > > literals > >>> >> > > > e.g. something.(name() = "cat") or > >>> >> something.("cat" = > >>> >> > name()) > >>> >> > > (these > >>> >> > > > are > >>> >> > > > the same) > >>> >> > > > -it (will) now handle XML e4x > references > >>> in > >>> >> nested > >>> >> > function calls > >>> >> > > > inside > >>> >> > > > the filter, e.g. things like: > >>> >> > > > e.g. > >>> >> > > > var people:XML = <people> > >>> >> > > > <person> > >>> >> > > > <name>Bob</name> > >>> >> > > > <age>32</age> > >>> >> > > > </person> > >>> >> > > > <person> > >>> >> > > > <name>Joe</name> > >>> >> > > > <age>46</age> > >>> >> > > > </person> > >>> >> > > > </people>; > >>> >> > > > var findJoeByAge:Function = function > >>> >> (i:int):Boolean { > >>> >> > > > return i > 40; > >>> >> > > > }; > >>> >> > > > > >>> people.person.(findJoeByAge(parseInt(age))).name > >>> >> > > > > >>> >> > > > > >>> >> > > > I have lots more granular tests in > QName, > >>> >> Namespace, > >>> >> > and XML with > >>> >> > > > tuning to > >>> >> > > > improve reliability. > >>> >> > > > toXMLString XML node output also > matches > >>> flash > >>> >> more > >>> >> > correctly in > >>> >> > > what I > >>> >> > > > have coming. > >>> >> > > > > >>> >> > > > One thing that I am trying to figure > >>> out, which > >>> >> I would > >>> >> > > appreciate > >>> >> > > > input on > >>> >> > > > if someone has an answer: > >>> >> > > > For the example: > >>> >> > > > > >>> >> > > > var feed:XML = new XML( > >>> >> > > > '<feed > xmlns:atom=" > >>> >> > > > > >>> >> > > > >>> >> > > >>> >> > >>> > > 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> >
