I would have to look at the code but I am pretty sure it just uses either some utilities(classes) or there are some dependencies in the tests.
There should be nothing in the code that is tied to any classes in compiler.jx. If there is, it should be removed because when I wrote it, I had nothing in mind with AS->JS transformations. I even wrote a small little Reference framework so I could keep the code abstract from the rest of the project. Mike On Mon, Mar 14, 2016 at 6:42 PM, Alex Harui <aha...@adobe.com> wrote: > Let me try to make sure everyone has the same information. > > As I understand it, ExternC doesn't have its own parsing code. It relies > on the Google Closure Compiler to parse .js files and build an AST. That > is why I put forth the idea that ExternC could be separated out from the > compiler.jx folder. Mike, can you tell us more about what ExternC uses > from compiler.jx? > > I would imagine that independent of whether we separate ExternC or not, > there will be some number of existing tests that have dependencies on > other repos and thus should be separated out. But IMO, just about every > test is going to want some set of default definitions, even if it is just > Number and String. Currently, we get those definitions from > playerglobal.swc via some environment variable (or I guess some Maven > default), but it turns out the js.swc we build with ExternC/CompC could be > a source of definitions for Number and String and not require playerglobal > or other dependency outside of the flex-falcon repo. Although, I suppose, > one could argue that the "extern" SWCs generated by the flex-falcon build > should be in a separate repo from the actual compiler. > > So, it could be possible for Maven to build ExternC, then a js.swc, then > FalconJX and run most of its tests and have those tests use js.swc. And > some other test suite could then bring in a dependency on playerglobal, > FlexJS, and/or the Flex SDK. > > I don't know what the right answer is, I just want to make sure everybody > has a better understanding of the factors involved. > > -Alex > > > On 3/14/16, 2:50 PM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote: > > >Well I am not planning on doing anything atm so it was just a question to > >Josh. > > > >The thing is, EXTERNC is not just a generator and actually, the generation > >of the AS is not that complex. Remember it's using the GCC compiler to get > >the AST ree of the JS file and that is the major reason I created it, was > >for the JS parsing of GCC. > > > >I think creating a generator from antlr would be over kill. > > > >The issue here is symantic analization of JS AST to create AS code, not > >the > >other way around. > > > >Mike > > > >On Mon, Mar 14, 2016 at 5:44 PM, Christofer Dutz > ><christofer.d...@c-ware.de> > >wrote: > > > >> HI, > >> > >> well I'm not talking about taking EXTERNC out of compiler.jx into a > >> dedicated, package. I'm talking about taking the Integration-Tests that > >> rely on parts of compiler.jx being built into a dedicated testsuite > >> artifact. I think EXTERNC is ok to be kept where it is. > >> > >> I am worried about yet another tool that has to be installed, yet > >>another > >> packaging system and all the integration problems that come with it. I > >> would probably be able to integrate things into the Maven build, but we > >>are > >> not making things simpler but adding another technology stack for > >>creating > >> simple AS code. I think it should be easier to crate such a generator > >>using > >> a JavaScript grammar and Antlr4. But I would really like to start > >>working > >> on something like this AFTER finishing the migration to Maven. Otherwise > >> it's shooting on moving targets. > >> > >> Chris > >> > >> ________________________________________ > >> Von: Michael Schmalle <teotigraphix...@gmail.com> > >> Gesendet: Montag, 14. März 2016 18:02 > >> An: dev@flex.apache.org > >> Betreff: Re: AW: AW: AW: AW: AW: AW: AW: LAST CALL] Release > >> FlexJS/FalconJX 0.6.0 > >> > >> Yeah lets not get started on the whole parsing js files. :) > >> > >> What I liked about gcc is it abstracted the AST and took care of the > >> parsing irregularities of JS. > >> > >> The problem is the AST walking like I did in ExternC, I had to template > >> that as though I knew I was parsing prototypes as the extern definition > >> says. > >> > >> It also relies on jsdoc tags so add another layer. JS is just a pain in > >>the > >> ass to deal with, plain and simple. Years ago I was able create a > >>grammar, > >> parser and a read/write framework for ActionScript using ANTLR only > >>because > >> it closely followed a spec, I hate JS for this reason. :) > >> > >> I just hate duplicating work and that is why I asked Josh what I did, I > >> totally wasn't asking him to donate anything. > >> > >> Mike > >> > >> > >> On Mon, Mar 14, 2016 at 12:13 PM, Alex Harui <aha...@adobe.com> wrote: > >> > >> > > >> > > >> > On 3/14/16, 8:34 AM, "Michael Schmalle" <teotigraphix...@gmail.com> > >> wrote: > >> > > >> > >On Mon, Mar 14, 2016 at 11:29 AM, Alex Harui <aha...@adobe.com> > >>wrote: > >> > > > >> > >> > >> > >> > >> > >> On 3/14/16, 8:19 AM, "Michael Schmalle" <teotigraphix...@gmail.com > > > >> > >>wrote: > >> > >> > >> > >> >That said, there is only "so much" that compiler can do because I > >> > >>hacked > >> > >> >it > >> > >> >together in about a month. Thinking about a way to create > >>something > >> > >>that > >> > >> >can support a yriad amount of definitions that are supported by > >>the > >> > >> >current > >> > >> >TS community is definitely something to think about. > >> > >> > >> > >> Yes, but when last discussed, Justin called the licensing > >>integrity of > >> > >>the > >> > >> TS files into question, so it may be less work for us to have any > >>code > >> > >> that generates extern SWCs from those files come from a non-Apache > >> > >>project > >> > >> unless someone wants to take the time to sort through it all. Of > >> course > >> > >> Apache is interested in all sorts of things like dts2as to be > >> > >>open-sourced > >> > >> at Apache, but the reality is that it won't always be the case. > >> > >> > >> > >> > >> > >Yeah, Yeah yeah :) I remember that conversation and that is why I > >>made > >> the > >> > >compiler. But, I forgot that it was never resolved. > >> > > >> > It is really up to Josh as to whether he wants to bring dts2as to > >>Apache. > >> > He has every right to keep it outside of Apache and maybe even make > >>some > >> > money off of it. > >> > > >> > > > >> > >Ok I ask this, is there anything it doesn't do right now for the core > >> > >stuff > >> > >you are working? > >> > > >> > Are you asking about ExternC? It works well enough for good extern > >>.js > >> > files. The problem is that there are a few libraries (Google Closure > >> > Library and CreateJS and probably Cordova) were there is no externs > >>files > >> > so we are asking ExternC to try to process the actual code, which it > >> > doesn't do so well, so we've fashioned other ways of skipping ExternC > >>or > >> > batch modification of the .js files to get ExternC to work and that is > >> > making more work for Chris' Maven stuff since the 8 SWCs have at > >>least 3 > >> > or 4 different recipes. > >> > > >> > IMO, it would be awesome to see ExternC grow into a tool that could > >> > generate the SWCs from the actual library code so folks don't have to > >> > maintain d.ts files or extern .js files, but I think that's a ton of > >>work > >> > especially given that some JS libraries are written with different JS > >> > patters like the IIFE pattern. > >> > > >> > Also, Chris and I are wondering if ExternC could be its own folder > >>like > >> > compiler and compiler.jx. It might simplify the Maven work. > >> > > >> > -Alex > >> > > >> > > >> > > >> > >
