Hi Michael, hi Erik,
On Sun, Jan 20, 2013 at 12:16 PM, Michael Schmalle
<apa...@teotigraphix.com>wrote:
As Erik has said, he made a stub for this already and we can start
writting it once I actually understand somethings.
One thing I need to get clear, are you asking the output to be like
Jangaroo where it prints it out like AS source code "Semantically" with
line numbers etc? Or are you asking to get the output correct only.
I know you have an an opinion about how things get debugged, so just
trying to get this clear from the beginning.
Again sorry for the long post, the answer in hidden somewhere in the
"middle part":
This is a special Jangaroo feature which we do not necessarily need to
implement for FalconJx.
However, I still think it is a good feature, and since it does not slow
down the optimized version,
why not implement it for FalconJx, too?
So no, it is not my primary goal that Flex / FalconJx supports this
feature, I consider it nice-to-have.
A must-have is that JS files can be loaded one-by-one in debug mode and
linked into one or a few minified file(s) for production. This is not only
for debugging, but also for fast development turn-around, as linking /
minifying would otherwise be needed for each turn-around. And I still think
this is best achieved using AMD / RequireJS.
To keep Jangaroo's 1:1 line mapping, I introduce named functions and assign
them to the right slot in the "Jangaroo part" at the end of the JS file.
So what we would do for FalconJx (at least as the first iteration) is to
"inline" the named function into the "Jangaroo part" class definition,
resulting in what I suggested in the "as-js-runtime-prototype" git project.
The reason I implemented this for Jangaroo 3 is that, given its code base,
it was actually easier to keep the 1:1 line mapping.
The whole point of my current work is to show that AMD-based JavaScript
code generation is a) not only an idea expressed in a prototype, but an
actual solution that can handle complex ActionScript applications like Open
Flash Chart efficiently, and b) there is a migration path from Jangaroo 1 /
2 to AMD-based JS output, so that Jangaroo projects can be mirgrated to
Apache Flex / Falcon Jx sometime in the future.
I don't know if "port" is the right word here. I think implement is more
like it. Since the AST and parser API is like black and white between
Jangaroo and the Falcon parsers, there is no way there is any translation
other then some patterns you might use on leaf expressions to do fancy
things to create the javascript. Trust me, I have looked and studied your
code. :)
You are totally right, "port" is the wrong word. We'll need to re-implement
the solution for Falcon. Because of the detailed solution outline (my
Jangaroo blog posts, as-js-runtime-prototype, my unfinished Wiki page), it
took me just a couple of days with the code base I know very well, I am
sure you two could get it re-implemented with FalconJx very quickly, too!
And as said, I am now in a position where I could (with some community
help) also start working on FalconJx code.
The rest of this post is WAY over my head right now. You have to
understand Frank, you are on an implementation level of JavaScript and I am
working in the "engine" room right now that is dirty and loud. ;-)
Then I hope you got your noise protection on! Well, I thought it would help
if you can try out things with a "reference implementation". If checking
out and building the "jangaroo-3" branch sounds like a lot of work, let me
tell you it isn't if you have git and Maven installed (detailed
instructions in my original post). To make it even easier to use, I could
deploy a Jangaroo 3 pre-release to Maven central, so that you could compile
AS to JS without the need to build jangaroo-tools locally. Would that help?
Or should I rather complete the "AS language features..." Wiki page?
Whatever helps you more.
Once I get MXML going and this compiler can create Alex's prototype
project just like FalconJS is, then I can step back take a deep breath and
focus on this stuff.
Does that make sense?
Perfectly!
-Frank-
