I think you missed part of his long message… ;-) > 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!
On Jan 20, 2013, at 6:35 AM, Alex Harui wrote: > Hi Frank, > > I won't be able to look at this for at least a couple of days. > > BTW, how's it going with the ICLA/CCLA? Or did I miss seeing the > notification for it? > > -Alex > > > On 1/19/13 1:08 PM, "Frank Wienberg" <fr...@jangaroo.net> wrote: > >> 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... >> >> 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/ja >> ngaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerat >> or.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- > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui >
