I like the idea of checking the layout of the SWC. I'll give that a try. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev>
On Wed, Jul 10, 2019 at 11:20 PM Alex Harui <aha...@adobe.com.invalid> wrote: > Is the "isNative()" function hooked up to the native keyword or the > [native] metadata? > > This is not the gotcha I was trying to remember in my last post, but one > concern that came to mind was that some API that we consider "native" or a > "typedef" for JS in the browser because it is supplied by the browser or a > third-party library may not be provided the same way on other > platforms/runtimes, so there is a danger that if you declare some class or > function as native that someone trying to create an > implementation/emulation of that API on some other platform/runtime will > run into trouble. > > So maybe we should flip the problem on its head and consider how to > identify classes whose JS output includes goog.provides(). That feels a > bit better because it is specific to JS output. A possible first > approximation would simply be to see if the SWC has a js/out folder and if > it does, assume that all classes from that SWC support goog.provides. > Typedef SWCs should not have a js/out folder and only an externs folder. > > HTH, > -Alex > > On 7/10/19, 8:54 AM, "Josh Tynjala" <joshtynj...@bowlerhat.dev> wrote: > > It looks like the native keyword is allowed on functions only. You'll > get a > compiler error if you try to add the native keyword onto a class. After > discovering this, I looked at how classes are compiled into > playerglobal.swc, and it looks like they have [native] metadata. That > could > possibly serve the same purpose. > > Here are a few options that might work: > > 1) Modify the compiler to allow the native keyword to be used on > classes. > > 2) Use [native] metadata to detect typedef classes. > > 3) Check the class for a constructor that has the native keyword > (since a > constructor is a function, native is allowed there). > > -- > Josh Tynjala > Bowler Hat LLC < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764667456&sdata=DEinUrLNfiRQmsk9kPo9bMXAik2hH2R1h6%2FuhvB2fq4%3D&reserved=0 > > > > > On Tue, Jul 9, 2019 at 8:08 PM Alex Harui <aha...@adobe.com.invalid> > wrote: > > > Good idea. I have this vague memory that there are some other > gotchas > > around using "native", but give it a try and see what happens. > > > > -Alex > > > > On 7/9/19, 4:21 PM, "Josh Tynjala" <joshtynj...@bowlerhat.dev> > wrote: > > > > You know, I just realized... we should start adding the "native" > > modifier > > to ActionScript classes in typedef SWCs. Typedef SWCs serve the > same > > purpose as playerglobal/airglobal SWCs, which are also compiled > as > > "native". They all define APIs that will be available at > run-time and > > the > > SWC should only be used for checking types and things at > compile-time. > > > > IDefinition has an isNative() method that tells you if a class > was > > marked > > with the "native" keyword. We would use that instead of > > library-path/external-library-path to determine whether > goog.require() > > is > > needed for a particular class. This would keep > > library-path/external-library-path working as they always have, > without > > affecting goog.require(). > > > > I think I actually suggested using the "native" keyword for > typedefs a > > very > > long time ago. I think you said that externc or the JS emitter > didn't > > handle it properly. Since I wasn't very familiar with the > compiler > > code at > > the time, I didn't think I could fix it, so I dropped the idea. > > > > This is what was missing. We were ignoring a feature of the > language > > that > > was meant for exactly this situation. > > > > -- > > Josh Tynjala > > Bowler Hat LLC < > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451&sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3D&reserved=0 > > > > > > > > > On Tue, Jul 9, 2019 at 4:00 PM Alex Harui > <aha...@adobe.com.invalid> > > wrote: > > > > > Category #1 is when someone intends to combine code from a SWC > into > > > another SWC to create one mega-swc, maybe to reduce the number > of > > SWCs or, > > > back in the day, to create one RSL instead of two. I don't > think > > Royale > > > should ever need to do this. > > > > > > Category #2 is the other AS classes from other SWCs you need. > As you > > > mentioned Jewel.SWC uses Basic org.apache.royale.states.States > (from > > > Core.swc or Basic.swc). > > > > > > Category #3 is definitions that are not in Royale code. For > SWF > > versions > > > of SWCs, it is everything in playerglobal/airglobal. So > Sprite, > > > DisplayObject, other flash.*.* packages. For JS versions of > SWCs it > > is > > > HTMLElement and other stuff in js.swc or other typedefs. > > > > > > If you are suggesting that somehow the compiler will know that > some > > SWCs > > > on the external-library-path are typedefs vs a framework class > from > > > Core.swc or Basic.swc, that might be possible, but I don't > know how > > > efficient that will be (or accurate) to determine that, plus > > portions of > > > the compiler have a test for "isExternal()" that we'd have to > make > > sure we > > > get right. > > > > > > That's why I suggest that we add some new option that lists > classes > > that > > > shouldn't be linked into library.swf without marking them > > "isExternal()". > > > There is already a similar option that does mark classes as > > "isExternal()" > > > that we might be able to leverage. > > > > > > HTH, > > > -Alex > > > > > > > > > On 7/9/19, 3:43 PM, "Josh Tynjala" <joshtynj...@bowlerhat.dev> > > wrote: > > > > > > > 3) code that should not be in the output SWC that doesn't > > support > > > goog.require/goog.provide > > > > > > Is there anything other than a typedef SWC that could be > > classified as > > > #3? > > > It seems like we have an extra category that doesn't exist > in > > > practice, but > > > we're giving it priority over a category that is more > common. > > > > > > Not just with framework SWCs either. Third-party SWCs that > > include > > > custom > > > components would need to set the framework SWCs on the > > > external-library-path too. > > > > > > -- > > > Josh Tynjala > > > Bowler Hat LLC < > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451&sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3D&reserved=0 > > > > > > > > > > > > > On Tue, Jul 9, 2019 at 3:33 PM Alex Harui > > <aha...@adobe.com.invalid> > > > wrote: > > > > > > > I'm not sure why Jewel CSS is winding up in non-Jewel > apps, > > but the > > > issue > > > > of whether SWC dependencies should be on the > library-path or > > > > external-library-path isn't so much as a bug > (functionality > > that > > > isn't > > > > working as expected) but rather, a problem we've had > "forever". > > > > > > > > With only -library-path and -external-library-path > options, > > that is > > > only > > > > two categories to categorize: > > > > > > > > 1) code from another library you want included in the > output > > SWC > > > > 2) code that should not be in the output SWC but supports > > > > goog.require/goog.provide > > > > 3) code that should not be in the output SWC that doesn't > > support > > > > goog.require/goog.provide > > > > > > > > When we build the framework, we rarely ever want #1. So > we've > > been > > > using > > > > -library-path for #2 and -external-library-path to be #3 > and > > somehow > > > got > > > > this far by ignoring the fact that code that shouldn't be > > duplicated > > > in the > > > > SWCs are. I think it has been like that "forever", so > no idea > > why > > > it is > > > > breaking now unless folks are using the JS versions of > the > > SWCs more > > > these > > > > days. > > > > > > > > I didn't think the duplication was causing problems but > since > > it > > > > apparently is, I think the compiler would need a way to > know to > > > exclude > > > > certain classes from the output SWF. I think there is > already > > an > > > -externs > > > > option but that requires listing every class which would > be > > painful > > > to > > > > administrate. And I think that might re-categorize the > class > > as > > > being on > > > > the -external-library-path which we don't want either. > So > > maybe a > > > new > > > > compiler option to exclude all classes from a SWC in the > output > > > library.swf > > > > is best. > > > > > > > > HTH, > > > > -Alex > > > > > > > > On 7/9/19, 3:06 PM, "Josh Tynjala" < > joshtynj...@bowlerhat.dev> > > > wrote: > > > > > > > > I have confirmed that these SWCs are defined on the > > library-path > > > in the > > > > compile-js-config.xml used to build JewelJS.swc. > Instead, > > it > > > should be > > > > using the external-library-path or > > js-external-library-path. > > > > > > > > In compile-swf-config.xml for Jewel.swc, the > dependencies > > are > > > correctly > > > > defined on external-library-path so that they aren't > > included in > > > > Jewel.swc. > > > > > > > > Unfortunately, my initial attempts to use > > external-library-path > > > or > > > > js-external-library-path are running into issues. I > worry > > that > > > it may > > > > be > > > > related to this comment in compile-js-config.xml > where the > > SWCs > > > were > > > > added > > > > to the library-path: > > > > > > > > <!-- asjscompc won't 'link' these classes in, but > will > > list their > > > > requires > > > > if these swcs are on the external-library-path > then > > their > > > requires > > > > will not be listed --> > > > > > > > > I could be wrong, but I interpret this comment to > mean that > > > > goog.require() > > > > is not added if something is on the > external-library-path. > > That > > > sounds > > > > like > > > > a bug in the compiler, and this was more of a > workaround > > than the > > > > correct > > > > way to fix things. > > > > > > > > -- > > > > Josh Tynjala > > > > Bowler Hat LLC < > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451&sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3D&reserved=0 > > > > > > > > > > > > > > > > > On Tue, Jul 9, 2019 at 2:35 PM Josh Tynjala < > > > joshtynj...@bowlerhat.dev > > > > > > > > > wrote: > > > > > > > > > It looks like JewelJS.swc includes some classes in > the > > SWC that > > > > probably > > > > > shouldn't be there. One example (but there are many > > more): > > > > > org.apache.royale.states.State. > > > > > > > > > > These are core classes that should be from > dependencies, > > and I > > > > suspect > > > > > that something might be on the library-path > instead of > > the > > > > > external-library-path. Because the compiler found > the > > class in > > > > JewelJS.swc, > > > > > it assumes that it needs defaults.css from > JewelJS.swc > > too. > > > > > > > > > > To try to reproduce this issue, I created a sample > app > > that > > > uses only > > > > > Basic components. I'm seeing that the compiler is > trying > > to use > > > > > defaults.css from Basic, Express, Jewel, and > > > MaterialDesignLite. > > > > > > > > > > I'll take a look at the compiler options for some > of the > > other > > > SWCs > > > > to see > > > > > if anything catches my eye. > > > > > > > > > > -- > > > > > Josh Tynjala > > > > > Bowler Hat LLC < > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451&sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > On Tue, Jul 9, 2019 at 3:21 AM Harbs < > > harbs.li...@gmail.com> > > > wrote: > > > > > > > > > >> I have no jewel components in my app, but I’m > suddenly > > seeing > > > TONS > > > > of > > > > >> jewel css in my app. > > > > >> > > > > >> Similarly, I’m seeing Basic CSS (such as Button) > which > > did > > > not used > > > > to be > > > > >> included (and is messing up the visuals in my > app). > > > > >> > > > > >> Has something changed with the logic which > includes CSS? > > > > >> > > > > >> Harbs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
