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 <[email protected]> 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 <[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> >> >
