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
