Alex, the idea was to make the js output itself support the options,
without any need to manipulate any files at all.
Why would you not want to use goog defines?
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#define-type-description
It seems like the easiest way and it leverages the strength of GCC.
if (JSBuild.includeReflection) {
regular reflection data
}
redefining that JSBuild.includeReflection goog define to be false at the
application build stage (which is for illustrative purposes here only, and
would be true by default), eliminates it from all classes (that have had it
included in the js output) in the release build, just like how goog.DEBUG
works now.
Having alternate swcs sounds complicated to me. It's different, but in some
ways conceptually similar to monkey patching I guess (which works also).
But it seems less desirable than being able to get everything you need from
the one swc.
OT: For the public vars stuff, that is not an issue for AMF serialization.
Reflection classes do support the public var renaming and AMF works fine
with the minimized names. I think the general issue with public vars is
that people can use regular dynamic access in actionscript, and that should
work by default rather than be another hurdle. But of course it should also
be able to be switched back to how it is now.
The ideas for the granular stuff are interesting, but I think we need to
go with things that are achievable in the near future, unless you
realistically think the code-flow stuff is something you can work on.
I don't think it's for me, but I believe I can do the stuff I already
mentioned. And I don't expect the approaches would be mutually exclusive in
terms of evolving things in the future.
Whatever the menu 'buckets' are can be debated, but they would simply be
sets of granular settings that people don't have to try to understand if
they don't want to.
On Thu, Sep 19, 2019 at 5:24 AM Alex Harui <[email protected]> wrote:
> I probably won't object to folks trying out different config options, but
> the 3 buckets Harbs proposed didn't make any sense to me. I would want to
> turn them all on, and not be sure what the trade-offs are.
>
> IMO, modifying the JS from SWCs after compilation is "easy" in the sense
> that it is all regular expressions in text and JS allows for it (at least
> so far). The compiler already has options to skip linking certain
> classes. That syntax can be extended to skip or modify some of the JS for
> a class. Also, the GoogDepsWriter reads just about every file already so
> doing more automated text manipulation is also "easy".
>
> Also note that code-flow-analysis is also possible and may allow us to
> automatically/intelligently modify/remove code someday, so some of these
> options may be interim solutions. For example, it might be possible to
> know which classes are being passed into Reflection and thus toss the
> reflection data from all of the other classes.
>
> I haven't tried this, but I've also considered that instead of compile
> options that you can link in alternate SWCs with alternate code, or that
> will overwrite the prototype at runtime to alter how things behave.
>
> Also, regarding public vars specifically, it may be that we use metadata
> to generate different code for vars. We already do that with [Bindable].
> It may be that if a class isn't a UI class and has [ClassAlias] or
> implements IExternalizable that we convert all vars to getter/setter (or do
> something else to prevent renaming) and that will the right default. Or
> invent some new metadata to signal different var output.
>
> In summary, large bucket options can be confusing, granular options can be
> painful, but we might be able to use code-flow or other hints and get it
> right more often than we do now.
>
> My 2 cents,
> -Alex
>
>
>
> On 9/18/19, 9:45 AM, "Greg Dove" <[email protected]> wrote:
>
> I think it could be as simple as having something like a class (eg.
> JSBuild) with a bunch of static goog @defines. These could be used to
> delimit sections of output that provide things like reflection, default
> initialized, vector runtime checking etc. In a sense it is not much
> different to how you might think of as3 compile flag stuff. But perhaps
> there are ways to use some bitwise flag sets that evaluate to compile
> time
> constants (for GCC) to achieve some of the granular/selective content
> discrimination like I described with the hypothetical reflection
> optimization example. E.g framework vs non-framework/ UI vs. non-UI. I
> realise that all sounds complicated, which is why simple combos would
> be
> good for most people as Harbs mentioned.
>
> On Thu, 19 Sep 2019, 02:15 Harbs, <[email protected]> wrote:
>
> > Absolutely. Now we just need to figure out how… ;-)
> >
> > > On Sep 18, 2019, at 5:10 PM, Josh Tynjala <
> [email protected]>
> > wrote:
> > >
> > >> I think the main thing we are missing (from my perspective) is to
> avoid
> > > the need to recompile the swcs to swap things in and out.
> > >
> > > I think that being able to switch things off and on without
> recompiling
> > > SWCs would be awesome. Without that control, we will continue to
> struggle
> > > with differing opinions on how it should work.
> > >
> > > --
> > > Josh Tynjala
> > > Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C38a5983306fd40c2568408d73c5792fe%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044219172559957&sdata=%2BfneeDw8TTECXeH2iugzmyQpP3WoKLFoLUmZ0Y1o720%3D&reserved=0
> >
> > >
> > >
> > > On Wed, Sep 18, 2019 at 12:31 AM Greg Dove <[email protected]>
> wrote:
> > >
> > >> I agree 100% Harbs. And I think that is not difficult to achieve.
> > >>
> > >> The decisions and collaborative effort need to take place in the
> > planning
> > >> side of things to figure out the reasonable set of granular
> things to
> > >> support. Perhaps we can do that once the 'dust has settled' after
> 0.9.6
> > is
> > >> out. Then your 3 sets (or whatever is decided to be the menu)
> could
> > simply
> > >> be defined as a collection of settings for those, with people
> free to
> > tune
> > >> things at a more granular level if they wanted.
> > >> I might want to, for example, be able to strip out reflection
> data from
> > UI
> > >> based Framework classes but keep it for all other framework
> stuff, and
> > all
> > >> my own custom UI components, (perhaps that sounds weird, but I can
> > think of
> > >> this as being useful in a real-world scenario with Crux). Whether
> that
> > >> level or control is reasonable for us to support is probably
> > questionable.
> > >> But I think it is *possible*. This is the same type of granular
> > switching I
> > >> was trying to explain for switching off Vector runtime checking in
> > recent
> > >> months, but I did not get a sense that anyone clearly understood
> what I
> > was
> > >> trying to convey at the time (my impression only).
> > >>
> > >> I think the main thing we are missing (from my perspective) is to
> avoid
> > the
> > >> need to recompile the swcs to swap things in and out.
> > >> Anyway, I will stop talking about this, I just wanted to
> highlight the
> > fact
> > >> that I believe we can technically meet most people's needs,
> whatever
> > they
> > >> are, but that I also think the general need is best served by
> matching
> > as3
> > >> behavior by default, as Josh has proposed for public vars.
> > >>
> > >>
> > >>
> > >> On Tue, Sep 17, 2019 at 10:28 PM Harbs <[email protected]>
> wrote:
> > >>
> > >>> Rather than having to specify a whole slew of compiler options,
> I’d
> > like
> > >>> to see 2 or 3 compiler configurations that would set the
> defaults on a
> > >>> group of options to get the best default behavior for a use case.
> > >>> Maybe something like this:
> > >>>
> > >>> js-config=compatible (for maximum, compatibility with Flash
> behavior)
> > >>> js-config=optimized (for minimum code size)
> > >>> js-config=safe (for best type safety but not necessarily Flash
> > >> compatible)
> > >>>
> > >>> Obviously, you could override the defaults on any one of these,
> but I
> > >> hope
> > >>> we could give predefined sets of defaults which cover the vast
> majority
> > >> of
> > >>> use cases out of the box.
> > >>>
> > >>> It’s hard learning all the compiler options, but being able to
> specify
> > a
> > >>> few sets of defaults seems reasonable.
> > >>>
> > >>> Harbs
> > >>>
> > >>>> On Sep 17, 2019, at 11:02 AM, Greg Dove <[email protected]>
> wrote:
> > >>>>
> > >>>> I personally would use a non-default setting to keep things as
> they
> > are
> > >>>> right now, but I agree with Josh in that as it is, I don't
> think it's
> > a
> > >>>> good hurdle to present to new users, or people in general that
> simply
> > >>> want
> > >>>> things to 'work' out of the box, based on what they should
> reasonably
> > >>>> expect to work. The language layer is the foundation for
> building
> > >>>> everything else. People have serious doubts when things don't
> work
> > >> right
> > >>> at
> > >>>> that level. I have had to reassure people about this recently
> (XML -
> > >>> still
> > >>>> working on it - soon!).
> > >>>>
> > >>>> We have only touched the surface of what we could do with GCC
> for
> > >> tuning
> > >>>> the output. There are ways to have all the default stuff in
> there but
> > >>>> selectively remove it from release builds without having to
> recompile
> > >>>> library code, for example. So I think it is possible that we
> could
> > >>> provide
> > >>>> flexible solutions that match whatever we consider people want.
> > >>>> But in terms of defaults, is it not obvious that it we should be
> > guided
> > >>> by
> > >>>> actionscript 3 language itself and the reference implementation
> we
> > >>> already
> > >>>> have? We can't always match things, but I think the onus is on
> us to
> > >> get
> > >>> as
> > >>>> close as we can by default.
> > >>>>
> > >>>>
> > >>>> On Tue, Sep 17, 2019 at 5:59 PM Alex Harui
> <[email protected]>
> > >>> wrote:
> > >>>>
> > >>>>> Some folks want us to get smarter and not automatically export
> all
> > >>> public
> > >>>>> methods and getter/setters. There are a lot of just-in-case
> strings
> > >> in
> > >>>>> Royale apps. That's not good. So better control over things
> even
> > >> after
> > >>>>> compiling without being painful to use is the goal.
> > >>>>>
> > >>>>> My 2 cents,
> > >>>>> -Alex
> > >>>>>
> > >>>>> On 9/16/19, 12:39 PM, "Josh Tynjala" <
> [email protected]>
> > >>> wrote:
> > >>>>>
> > >>>>> I was thinking about this some more, and is there anything
> else
> > >>> that's
> > >>>>> public that also we allow to be renamed? I'm not aware of
> anything,
> > >>> but
> > >>>>> maybe I've missed something. If it's true, it seems
> inconsistent to
> > >>>>> allow
> > >>>>> public variables to be the one exception that should be
> renamed. If
> > >>>>> public
> > >>>>> methods, properties, and other things can't be renamed,
> public
> > >>>>> variables
> > >>>>> shouldn't be either.
> > >>>>>
> > >>>>> Looking into the configuration classes, I see that we have
> the
> > >>>>> export-public-symbols compiler option. That seems like it's
> the one
> > >>>>> that is
> > >>>>> meant to control whether public things should be renamed or
> not.
> > >> It's
> > >>>>> true
> > >>>>> by default. I have no issue with public variables being
> renamed
> > >> when
> > >>>>> it's
> > >>>>> false. Again, that would be consistent with how the compiler
> > >> handles
> > >>>>> other
> > >>>>> public things.
> > >>>>>
> > >>>>> --
> > >>>>> Josh Tynjala
> > >>>>> Bowler Hat LLC <
> > >>>>>
> > >>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C38a5983306fd40c2568408d73c5792fe%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044219172559957&sdata=%2BfneeDw8TTECXeH2iugzmyQpP3WoKLFoLUmZ0Y1o720%3D&reserved=0
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Mon, Sep 16, 2019 at 11:13 AM Josh Tynjala <
> > >>>>> [email protected]>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Unfortunately, people actively avoid using public vars
> because we
> > >>>>> warn
> > >>>>>> about them. Our warnings are too aggressive if it doesn't
> actually
> > >>>>> matter
> > >>>>>> most of the time. Plus, this warning leaves a bad impression
> because
> > >>>>> it's
> > >>>>>> such a basic feature of the language that pretty much
> everyone uses.
> > >>>>>>
> > >>>>>> What can we do to provide a more sensible default behavior,
> while
> > >>>>> also
> > >>>>>> giving someone the ability to tell the compiler that
> everything can
> > >>>>> be
> > >>>>>> renamed (or selective renaming)?
> > >>>>>>
> > >>>>>> We could add an option that doesn't rename public things by
> default,
> > >>>>> but
> > >>>>>> can also be toggled to rename everything. I guess we could
> have some
> > >>>>>> @royalewhatever annotations to give someone selective control
> over
> > >>>>> which
> > >>>>>> things are renamed or not, if someone needs that. Thoughts?
> > >>>>>>
> > >>>>>> --
> > >>>>>> Josh Tynjala
> > >>>>>> Bowler Hat LLC <
> > >>>>>
> > >>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C38a5983306fd40c2568408d73c5792fe%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044219172559957&sdata=%2BfneeDw8TTECXeH2iugzmyQpP3WoKLFoLUmZ0Y1o720%3D&reserved=0
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Mon, Sep 16, 2019 at 10:50 AM Alex Harui
> > <[email protected]
> > >>>>>>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> I'm not sure I understand your proposal. Are you proposing
> that
> > all
> > >>>>>>> public variables will be quoted and thus not renamed so we
> never
> > >>>>> warn
> > >>>>>>> again? I am not in favor of that. IMO, the vast majority of
> > >>>>> public vars
> > >>>>>>> can be renamed without penalty. It is only certain classes
> that
> > >>>>> will be
> > >>>>>>> mapped to external code that matter.
> > >>>>>>>
> > >>>>>>> My 2 cents,
> > >>>>>>> -Alex
> > >>>>>>>
> > >>>>>>> On 9/16/19, 10:46 AM, "Josh Tynjala" <
> [email protected]>
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>> You're right. After a number of tests, I cannot find any
> > >>>>> annotation
> > >>>>>>> (or
> > >>>>>>> combination of them) that will prevent the renaming of
> variables
> > >>>>>>> defined on
> > >>>>>>> a prototype. All of the official advice that I see from
> Google
> > >>>>>>> suggests
> > >>>>>>> quoting the properties (or using externs). So, from a
> Royale
> > >>>>>>> perspective,
> > >>>>>>> it looks like quoting the public variable's name is our
> best
> > >>>>> option.
> > >>>>>>>
> > >>>>>>> Similar to how we handle
> js-dynamic-access-unknown-members, we
> > >>>>> can
> > >>>>>>> quote
> > >>>>>>> the public variable's name when getting or setting it in
> JS:
> > >>>>>>>
> > >>>>>>> var foo = new Foo();
> > >>>>>>> foo["bar"] = 2;
> > >>>>>>> var baz = foo["bar"];
> > >>>>>>>
> > >>>>>>> In this case, we also need to quote the public variable's
> name
> > >>>>> when
> > >>>>>>> declaring it on the prototype:
> > >>>>>>>
> > >>>>>>> Foo.prototype["bar"] = 3;
> > >>>>>>>
> > >>>>>>> I did some tests, and I can confirm that Closure will
> preserve
> > >>>>> the
> > >>>>>>> public
> > >>>>>>> variable's name, similar to how it preserves the names
> when we
> > >>>>> declare
> > >>>>>>> public getters and setters. I'm going to make this change
> and
> > >>>>> turn off
> > >>>>>>> warn-public-vars.
> > >>>>>>>
> > >>>>>>> (To be clear, I'm only going to change how the emitter
> handles
> > >>>>> public
> > >>>>>>> variables specifically. Behavior for other types of
> property
> > >>>>> access
> > >>>>>>> will
> > >>>>>>> remain the same.)
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Josh Tynjala
> > >>>>>>> Bowler Hat LLC <
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C38a5983306fd40c2568408d73c5792fe%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044219172559957&sdata=%2BfneeDw8TTECXeH2iugzmyQpP3WoKLFoLUmZ0Y1o720%3D&reserved=0
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Mon, Sep 16, 2019 at 10:06 AM Alex Harui
> > >>>>> <[email protected]
> > >>>>>>>>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Feel free to revisit. IIRC, the issue is that you can't
> > >>>>> @export a
> > >>>>>>> "var".
> > >>>>>>>> You can only @export a function because @export sets up a
> > >>>>> reference
> > >>>>>>> to the
> > >>>>>>>> renamed function and you can't set up a reference to simple
> > >>>>> vars.
> > >>>>>>>>
> > >>>>>>>> Class Josh {
> > >>>>>>>> Static var foo:int = 1;
> > >>>>>>>> }
> > >>>>>>>>
> > >>>>>>>> Compiles to:
> > >>>>>>>>
> > >>>>>>>> Josh.foo = 1;
> > >>>>>>>>
> > >>>>>>>> Gets renamed to:
> > >>>>>>>>
> > >>>>>>>> a.b = 1;
> > >>>>>>>>
> > >>>>>>>> The @export will result in:
> > >>>>>>>>
> > >>>>>>>> ['Josh']['foo'] = a.b;
> > >>>>>>>>
> > >>>>>>>> And then code that does:
> > >>>>>>>>
> > >>>>>>>> Josh.foo = 2;
> > >>>>>>>>
> > >>>>>>>> Will not change
> > >>>>>>>>
> > >>>>>>>> Console.log(a.b); // 1 (not 2)
> > >>>>>>>>
> > >>>>>>>> Of course, I could be wrong..
> > >>>>>>>>
> > >>>>>>>> -Alex
> > >>>>>>>>
> > >>>>>>>> On 9/16/19, 9:57 AM, "Josh Tynjala" <
> > >>>>> [email protected]>
> > >>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> I guess I was assuming that @nocollapse combined with
> > >>>>> @export
> > >>>>>>> would
> > >>>>>>>> make it
> > >>>>>>>> also prevent renaming. I suppose I can test it and see
> > >>>>> what
> > >>>>>>> happens.
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Josh Tynjala
> > >>>>>>>> Bowler Hat LLC <
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C38a5983306fd40c2568408d73c5792fe%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044219172559957&sdata=%2BfneeDw8TTECXeH2iugzmyQpP3WoKLFoLUmZ0Y1o720%3D&reserved=0
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Mon, Sep 16, 2019 at 9:54 AM Alex Harui
> > >>>>>>> <[email protected]>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> IMO, the -warn-public-vars is more about the "renaming"
> > >>>>>>> mentioned in
> > >>>>>>>> that
> > >>>>>>>>> link than the "collapse".
> > >>>>>>>>>
> > >>>>>>>>> If you have:
> > >>>>>>>>>
> > >>>>>>>>> Package {
> > >>>>>>>>> Class Josh {
> > >>>>>>>>> Public var name:String;
> > >>>>>>>>> }
> > >>>>>>>>> Var foo:Josh = new Josh();
> > >>>>>>>>> foo.name = 'josh';
> > >>>>>>>>>
> > >>>>>>>>> I don't think @nocollapse will prevent renaming the
> > >>>>> 'name'
> > >>>>>>> property
> > >>>>>>>> to
> > >>>>>>>>> something random like 'jt':
> > >>>>>>>>>
> > >>>>>>>>> Var foo = new Josh();
> > >>>>>>>>> foo.jt = 'josh';
> > >>>>>>>>>
> > >>>>>>>>> AIUI, @nocollapse is used for things that are not
> > >>>>> obviously
> > >>>>>>>> mutable. If
> > >>>>>>>>> you look in the globals in the browser debugger for any
> > >>>>>>> js-debug
> > >>>>>>>> version of
> > >>>>>>>>> a Royale app, you can see the structure:
> > >>>>>>>>>
> > >>>>>>>>> org.apache.royale.core
> > >>>>>>>>>
> > >>>>>>>>> It was created by code similar to:
> > >>>>>>>>>
> > >>>>>>>>> window.org = {};
> > >>>>>>>>> window.org.apache = {};
> > >>>>>>>>> window.org.apache.royale = {};
> > >>>>>>>>> window.org.apache.royale.core = {};
> > >>>>>>>>>
> > >>>>>>>>> Then some class gets added:
> > >>>>>>>>>
> > >>>>>>>>> window.org.apache.royale.core.UIBase = function ()...
> > >>>>>>>>>
> > >>>>>>>>> And some static might get added to that:
> > >>>>>>>>>
> > >>>>>>>>> window.org.apache.royale.core.UIBase.FOO = "BAR";
> > >>>>>>>>>
> > >>>>>>>>> Closure will collapse org.apache.royale.core to just
> > >>>>>>> something like
> > >>>>>>>> "bb"
> > >>>>>>>>> in the js-release output. And that means that code
> > >>>>> that sets
> > >>>>>>>> UIBase.FOO
> > >>>>>>>>> will break because there won't be an
> > >>>>> org.apache.royale.core
> > >>>>>>>> structure.
> > >>>>>>>>> AIUI, nocollapse would prevent collapsing that
> > >>>>> structure, but
> > >>>>>>> won't
> > >>>>>>>> prevent
> > >>>>>>>>> UIBase and FOO from being renamed. And the renaming
> > >>>>> mainly
> > >>>>>>> causes
> > >>>>>>>> problems
> > >>>>>>>>> when deserializing data structures coming from a server
> > >>>>> or
> > >>>>>>> other
> > >>>>>>>> external
> > >>>>>>>>> source.
> > >>>>>>>>>
> > >>>>>>>>> Of course, I could be wrong...
> > >>>>>>>>> -Alex
> > >>>>>>>>>
> > >>>>>>>>> On 9/16/19, 9:07 AM, "Josh Tynjala" <
> > >>>>>>> [email protected]>
> > >>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>> I was looking through the Closure compiler
> > >>>>> annotations,
> > >>>>>>> and I
> > >>>>>>>> noticed
> > >>>>>>>>> @nocollapse:
> > >>>>>>>>>
> > >>>>>>>>> Denotes a property that should not be collapsed by
> > >>>>> the
> > >>>>>>> compiler
> > >>>>>>>> into a
> > >>>>>>>>>> variable. The primary use for @nocollapse is to
> > >>>>> allow
> > >>>>>>>> exporting of
> > >>>>>>>>> mutable
> > >>>>>>>>>> properties.
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23nocollapse&data=02%7C01%7Caharui%40adobe.com%7C38a5983306fd40c2568408d73c5792fe%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044219172559957&sdata=FNI8vFIUfaiBZkcJvcPNudfsNstHKVUvNTTWWnjnHSo%3D&reserved=0
> > >>>>>>>>>
> > >>>>>>>>> Isn't this collapsing behavior the reason why we
> > >>>>> needed
> > >>>>>>> to add
> > >>>>>>>>> -warn-public-vars?
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Josh Tynjala
> > >>>>>>>>> Bowler Hat LLC <
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C38a5983306fd40c2568408d73c5792fe%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044219172559957&sdata=%2BfneeDw8TTECXeH2iugzmyQpP3WoKLFoLUmZ0Y1o720%3D&reserved=0
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>
> >
> >
>
>
>
