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" <greg.d...@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 <greg.d...@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 <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://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 <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&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.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&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>
>>
>
