Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <20121128172210.82245u7k4xt18x3m@teotigraphix.com>
Date: Wed, 28 Nov 2012 17:22:10 -0500
From: Michael Schmalle <apache@teotigraphix.com>
To: flex-dev@incubator.apache.org
Subject: Re: FalconJS "Demo" checked in
References: <CCDBC926.492D2%aharui@adobe.com>
In-Reply-To: <CCDBC926.492D2%aharui@adobe.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=ISO-8859-1;
 DelSp="Yes";
 format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.11)

No, I'm not getting confused here, remember I wrote an ASDoc clone  
based off the MXMLC in about 2 weeks. I completely understand what the  
difference between Falcon and FalconJS is.

Basically, the MXMLJSC class is the class that does what I listed  
below. It almost loads like MXMLC does.

The algorithm is;

- main()
- mainNoExit(args)
- configure(args)
- compile()
   - setupJS()
   - buildArtifact()
     - buildSWFModel()
       - buildSWF()
         - target:JSTarget.build(mainCU)


JSTarget.build()
   - getRootedCompilationUnits() Gets all units
   - initializeSWF() creates the ISWF from the compilation unit
   - swf.addFrame(mainFrame)
   - addToFrame(cu, mainFrame) add unit to frame

buildSWFModel() will return the ISWF to compile()

------------------------------------------------

Everything up to this point was falcon, we have the dependency graph  
and compilation units created, now FalconJS impl kicks in.

- loop through all reachable compilation units
   - JSWriter writer (JSWriter)swfWriter
   - writer.writeTo(output)

The above is the extent to which the whole emitter framework is  
exposed within the MXMLJSC compiler.

I know everything up to this point, I used around the same pattern to  
make ASDoc. The problem is, when you head into the JSWriter you get  
1444 lines of code, then
the JSGenerating reducer has 11,630 lines of code with comments of course.

The problem is, you can't just go into the generating reducer and  
writer and change code from js to java. The sematics are all different  
for the languages. That is where the custom jburg cmc emitter comes  
in. It uses js language specific rules to determine is reducing route.

--------------------------------------------------

Now what I was saying was to reimplement new visitor/emitter code  
right at JSWriter writer (JSWriter)swfWriter. To a manageable hand  
written visitor emitter.

So basically I am going to create a new writer with my own impl for a  
test Java case.

Well, anyway, just writing this out for myself I understand where the line is.

I'm going to do a prototype of something just to answer my own curiosity.

Mike


Quoting Alex Harui <aharui@adobe.com>:

>
>
>
> On 11/28/12 1:06 PM, "Michael Schmalle" <apache@teotigraphix.com> wrote:
>
>>
>> I have experience with code emitting but it used actual AST, no JBurg
>> and no reducers etc.
>>
>> I may be getting confused to what is actually needed in a simple cross
>> compiler but to me it seems;
>>
>> - gather all sourcepaths
>> - gather libraries
>> - execute a build target that will create the compilation units
>> - create a walker/visitor/emitter framework that recursively visits
>> each compilation unit
>> - foreach compilation unit emit the correct code that will create the
>> "mirror" platform code.
>>
>> I know I must sound completely naive here but for what is trying to be
>> accomplished it seems that FalconJS is overly complicated for what it
>> is outputing.
> I think you may be confusing what Falcon does vs FalconJS.  FalconJS is only
> about 40 java files and leverages hundreds of classes from Falcon.  AFAICT,
> the entire buildup of the AST is all in Falcon code.  I believe that Falcon
> code is scanning source paths and library paths and parsing SWCs in order to
> build out the symbol table to resolve references in the .AS files and fail
> on missing references.  It won't let you cheat and write code that may
> survive in JS but wouldn't in plain AS compilation.  Then once the units are
> parsed it seems to go through the reduce/emitter/writer to create .JS files.
>>
>>  From my research, it seems the engineers just copied a lot of classes
>> over from the ABC byte code generation framework and replaced things
>> to fit a javascript impl.
> Yup, I think there is subclassing and substitution going on to replace the
> SWF/ABC output pipeline with JS output.
>>
>> I know they created a "backend" API but to me again and PLEASE some
>> one that is 100 times smarter than me tell me I'm wrong in assuming to
>> create JS or Java you could just loop through compilation units and
>> use a hand written visitor/emitter?!
> I don't know what the backend API looks like.  It appears to be that you can
> replace which Reducer/Emitter/Writer gets used.  I'm still not clear how
> Jburg fits into the mix, but I also wonder whether you can rewrite the code
> in a copy of the JS CMC emitter to emit Java constructs instead and not need
> to know Jburg.
>
>>
>> So.. really I am out of my ballpark with even trying to understand the
>> JS classes they have because they are connected to 100's of different
>> objects being passed around.
> AFAICT, the JS classes are being handed AST entities to reduce to output
> code.  If you are trying to follow code in the debugger, keep in mind that
> there is a thread for each compilation unit and they sometimes block.
>
> But it still seems like it could be as simple as changing all of the emitter
> method to generate .java instead of .js.
>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Quoting Michael Schmalle <apache@teotigraphix.com>:
>>
>>> Ok,
>>>
>>> Challenge accepted.
>>>
>>> I was just looking through the cmc-js.jbg file. I actually think
>>> this might be doable. The JavaScript impl looks very complicated
>>> but, that's because it's doing a lot of things right now as far as
>>> building the .js code.
>>>
>>> I'm going to start small and see what I get. The first order of
>>> business is just trying to hack together the base framework
>>> (emitter) using FalconJS as a template.
>>>
>>> If I can get C working we are going somwhere. That will take awhile,
>>> I'll let you know what I discover.
>>>
>>> Mike
>>>
>>>
>>> Quoting Alex Harui <aharui@adobe.com>:
>>>
>>>>
>>>>
>>>>
>>>> On 11/28/12 11:27 AM, "Michael Schmalle" <apache@teotigraphix.com> wrote:
>>>>
>>>>
>>>>>
>>>>> Are we creating just views? Are we creating business logic? As you can
>>>>> see I have confused myself here.
>>>>>
>>>>> What would be really kewl is if someone reading this says, Mike I bet
>>>>> you can go from A to B to C then D. If I saw the whole prototype flow
>>>>> in front of me I probably could make it work some how.
>>>> OK, so if you take the code I've checked in, the workflow is this:
>>>>
>>>> A) Developer had FlexJSTestMXML.mxml and MyInitialViewMXML.mxml  
>>>> and Model.as
>>>> and Controller.as
>>>> B) I hand-converted FlexJSTestMXML.mxml to FlexJSTest.as and
>>>> MyInitialViewMXML.mxml to MyInitialView.as
>>>> C) I feed FlexJSTest.as and FlexJSUI.swc to FalconJS
>>>> D) I get a bunch of JS files
>>>> E) I mimic the AS controls in FlexJSUI.swc in js/framework.js
>>>> F) I hand-create an index.html to load all of the .js files
>>>> G) I run it in the browser (FireFox).
>>>>
>>>> The parallel as I see it is that you start with B and:
>>>> C') Feed FlexJSTest.as and FlexJSUI.swc to FalconJava
>>>> D') You get a .jar
>>>> E') You mimic the AS controls in FlexJSUI.swc in java/framework.jar.  They
>>>> should be thin wrappers on native Android controls, just like framework.js
>>>> is a thin wrapper on native HTML controls
>>>> F') You package it up into an APK.
>>>> G') You run it on Android device.
>>>>>
>>>>> JBurg is just grammar, it took me about 3 months to finally learn
>>>>> ANTLR and it's rewriting syntax. So if I had a clear path of what I
>>>>> was trying to prototype with Java I would put time into learning JBurg.
>>>>>
>>>>> What would be interesting is paralleling what you are implementing in
>>>>> JS (your proto components) with Java Android. I know some people would
>>>>> say this is ridiculous but it would be a path to a prototype.
>>>> What I don't know is if it is 'ridiculous' or not.  If it isn't,  
>>>> it could be
>>>> pretty cool.
>>>>>
>>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>>>
>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com