flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Date Sun, 20 Jan 2013 11:16:25 GMT

Quoting Frank Wienberg <frank@jangaroo.net>:

> Hi folks,
> I have been rather quiet for a while, but that's because I have been busy
> implementing JavaScript code generation according to the Runtime prototype
> I posted some weeks ago. However, I started off implementing this in the
> Jangaroo compiler, not in Falcon. I am far quicker implementing this in the
> context I know, it would have taken me much longer getting started with
> Falcon first. So of course now I hope that you guys help me porting this
> solution to FalconJx...

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.

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. :)

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. ;-)

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?


> I'm about 80% finished implementing all the AS3 language features I started
> documenting in the Flex Wiki and already have a demo of a large
> application, namely the Open Flash Charts demo, recompiled with the new AMD
> approach.
> Background on the demo:
> Open Flash Chart 2 <http://teethgrinder.co.uk/open-flash-chart-2/> is a pure
> ActionScript 3  
> project<http://sourceforge.net/projects/openflashchart/files/open-flash-chart/Version%202%20Lug%20Wyrm%20Charmer/>,
> and I only had to make very few changes to the original AS3 code to make
> the JavaScript version generated by the Jangaroo compiler work in the
> browser, without a Flash plugin. This has been working with Jangaroo 1 and
> 2, and now I got it to run with the new runtime format proposed for
> FalconJx.
> The demo comes in two flavors:
> The "production" version <http://jangaron.net/ofc5/data-files/joo.html>,
> where the whole application is a minified single JS file of about 380 kb
> (unzipped, the original SWF has 320 kb, and that is zipped and of course
> does not contain the Flash classes, because they come with the
> FlashPlayer!):
> *http://jangaron.net/ofc5/data-files/joo.html*
> Or load the "debug"
> version<http://jangaron.net/ofc5/data-files/joo.html#joo.debug>,
> where the JS equivalent of every AS class is loaded as a single request,
> simply by adding hash joo.debug to the URL:
> *http://jangaron.net/ofc5/data-files/joo.html#joo.debug*
> This demonstrates the real benefit of the AMD approach: RequireJS is
> capable of loading all needed scripts one by one (debug mode) as well as
> optimize them into a single JS file for production. It can use Uglify,
> Uglify2 or Google Closure for minification.
> Loading every AS class as a single request is still astonishingly fast,
> especially when using local deployment, which is what you usually do for
> debugging. Note that the demo uses over 200 classes.
> Have a look at the generated JavaScript, and you'll see that Jangaroo keeps
> the original ActionScript code either as comment (if there is no JavaScript
> counterpart, like for "package", "class", type annotations), or as
> executable code in the exact line where the original AS code was. That
> means if you want to debug say line 20 of AS class "Foo", you open script
> "Foo.js" in the JavaScript debugger and find the code and set the
> breakpoint in that same line: 20. 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?
> What I think we do need in any case is the ability to load AS classes by
> single requests, as otherwise they are really hard to find when debugging
> in the browser. And this is what you get for free when using RequireJS. In
> Alex' prototype, the only way to achieve this behavior was to list all
> needed single class scripts in the HTML (see FlexJS Wiki page). Of course,
> such HTML could be generated, but I think RequireJS' approach is more
> elegant.
> Another thing you can see in the Open Flash Chart demo is how I implemented
> static code execution. ActionScript executes all static code of the whole
> "compilation unit" the first time its "primary declaration" (usually a
> class) is accessed.
> Consequently, not (only) an ActionScript class, but an ActionScript
> "compilation unit" is put into a JavaScript AMD module definition. Thus,
> the module's value is not the class itself, but a compilation unit
> containing the class. I use the property "_" for the class or any other
> primary declaration, which in AS3 can also be a function, variable or
> constant. The static code of the compilation unit is *not* executed when it
> is *loaded*, but when the "_" property is *accessed* for the first time.
> (Because code has to be loaded asynchronously in the browser, we cannot
> load the module when it is accessed synchronously, but have to load all
> static dependencies in advance.) This is equivalent to the original AS3
> behavior, and only introduces the minimal overhead of accessing Foo._
> instead of just Foo.
> If you want to play with the new Jangaroo compiler to see what JavaScript
> output is generated for your ActionScript input, the simplest way is as
> follows.
> You need to have Java, Git and Maven installed and properly set up.
> Clone the jangaroo-tools repository and switch to branch jangaroo-3:
>> git clone git://github.com/CoreMedia/jangaroo-tools.git
>> git checkout jangaroo-3
> Then run the integration tests via Maven:
>> cd jangaroo-tools
>> mvn install -pl :jangaroo-compiler-itests -am
> This should result in a BUILD SUCCESS.
> The jangaroo-compiler-itests module is under
> jangaroo/jangaroo-compiler-itests:
>> cd jangaroo/jangaroo-compiler-itests
> For the intergration tests, all *.as files under src/test/joo/ are compiled
> to target/temp/joo/classes/, respecting their package sub-directory. So if
> you add an *.as file under the src/test/joo/ directory, the corresponding
> *.js file will appear under the target/temp/joo/classes/ directory after
> the following Maven command:
>> mvn test-compile
> Note that you cannot use Flash API here (will result in compile error, as
> classes are not found), only basic classes like String, Array, and built-in
> functions like trace().
> Another good news is that my employer signed the CCLA, and it has been
> confirmed by Craig, so now I am all set to contribute Jangaroo code to
> Apache Flex!
> The code that generates the new JavaScript runtime format is in  
> jangaroo-tools
> on the "jangaroo-3"
> branch<https://github.com/CoreMedia/jangaroo-tools/commits/jangaroo-3>
> (see
> above), especially class
> JSCodeGenerator<https://github.com/CoreMedia/jangaroo-tools/blob/jangaroo-3/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java>(Michael
> Sch. knows this already!) is interesting for porting code to
> FalconJx and has changed substantially for Jangaroo 3 / AMD runtime format.
> I am also working on another demo, which is written in AS3 and MXML (!),
> but instead of Flex components, uses "native" Ext JS JavaScript components
> through an AS API. It does not use the Jangaroo Flash library
> re-implementation (JooFlash), so this sounds similar to Alex' approach to
> not use the display list to render MXML components. More update on this to
> follow.
> Would really be great if we could consolidate our solutions!
> Can't wait for your feedback,
> -Frank-

Michael Schmalle - Teoti Graphix, LLC

View raw message