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 <joshtynj...@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 <greg.d...@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 <greg.d...@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 <aha...@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" <greg.d...@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.d...@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
> <aha...@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" <greg.d...@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
> >>> <aha...@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" <aha...@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.d...@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
> >>>     >> <aha...@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.d...@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
> >>>     >>     > <aha...@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&amp;data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034120784048005&amp;sdata=hDhwbA6IQCFHQ3FQkNoVyaUcdZcxrzQS6ZWpiKrYr38%3D&amp;reserved=0
> >>>     >>     >         >     >
> >>>     >>     >         >     > HTH,
> >>>     >>     >         >     > -Alex
> >>>     >>     >         >     >
> >>>     >>     >         >     > On 9/4/19, 3:11 AM, "Greg Dove" <
> >>>     >> greg.d...@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&amp;data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&amp;sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%3D&amp;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&amp;data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&amp;sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%3D&amp;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&amp;data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&amp;sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%3D&amp;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>
>

Reply via email to