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 <aha...@adobe.com>:
On 11/28/12 1:06 PM, "Michael Schmalle" <apa...@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 <apa...@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 <aha...@adobe.com>:
On 11/28/12 11:27 AM, "Michael Schmalle" <apa...@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
