However the Apparat version is much better. First of all we have put a lot of work into Apparat to make such transformations rock-solid. AS3C had its issues and was never a reliable tool. But there are a lot of new great features Patrick implemented. You can mix AS3 in your bytecode as well. __as3 is the best friend of __asm. Because sometimes writing pure bytecode is very verbose and not necessary.

A simple trace('Hello World!') with pure bytecode would look like this. Please note the FindPropStrict and CallPropVoid operations which reference trace.

__asm(
  FindPropStrict(AbcQName('trace', AbcNamespace(NamespaceKind.PACKAGE, ''))),
  PushString('Hello World!'),
  CallPropVoid(AbcQName('trace', AbcNamespace(NamespaceKind.PACKAGE, '')), 1)
);

Finding the object in the correct namespace is often a very cumbersome task. Thanks to __as3 we can also write this in a much more conciese way.

__asm(
  FindPropStrict(__as3(trace)),
  PushString('Hello World!'),
  CallPropVoid(__as3(trace), 1)
);

Note that the ASM compiler will try to guess the required name once it is requested by an operation. You can use __as3 also for other tasks.

var x: int = 1;
__asm(
  FindPropStrict(__as3(trace)),
  __as3(x < 10),
  CallPropVoid(__as3(trace), 1)
);

This would trace "true" for instance. If you are curious about the ASM syntax I can recommend you using the dump tool. It produces code which is nearly __asm-ready. We will probably write another output so you can directly transform existing code to __asm calls.

If you are interested in some more examples the Apparat Math replacements make use of __asm now as well. IntMath is a good example for an inlined class where you are using maybe a simple method like IntMath.abs and the heavy lifting is done behind the scenes using inline assembler. To use the ASM expansion you have to process your SWF file with TDSI. It is by default turned on.

I have released Apparat RC5 at GoogleCode. It contains a really cool feature which is called LZMA compression.

Reducer has advanced a lot during the last couple of weeks. It is now also a strong SWF compression tool even if you do not have any PNG files it can compress. You may ask: “What is that Matryoshka doing there? And why the hell the top hat?” The top hat: I do not know. The Matryoshka: I can explain.

The Flash Player does not understand LZMA. SWF files are compressed using good old DEFLATE. So what happens? Apparat extracts your original SWF. It compresses it again using the LZMA algorithm. The compressed SWF is injected into another SWF that contains an LZMA decoder. Size, background color, frame rate, etc. get adjusted. Finally you get a new SWF that contains your old SWF and a decoder to extract it at runtime. The overhead of the decoder is currently at around 5kb and I hope I can get it even smaller.

When you open that SWF with the Flash Player it will extract your original file and load it. Another nice feature is that I created different versions of the runtime decoder. One is using a classic preloader which is great if your SWF is a little bit bigger. And hey: it is a preloader for free so you do not have to deal with the [Frame] hassle. But here is the catch. We at audiotool.com always write our SWF files in the same style and I can just hope you do the same or use the great InitInjector by Valentin Simonov.

Your main SWF class or the so called DocumentClass must make sure that a stage is available before accessing it. This is really easy:

public function Main() {
  addEventListener(Event.ADDED_TO_STAGE, init)
  if(null != stage) init()
}

private function init(event: Event = null): void {
  removeEventListener(Event.ADDED_TO_STAGE, init)
  // your original constructor code goes here ...
}

Stick to that rule or InitInjector can automate it for you. Otherwise you will get a runtime exception that the stage is null. So this is one new feature. The other one is actually pretty standard. If you compile and link against a SWC file all classes will come in their own ABC file. Each ABC file has a constant pool. So if you link against 1000 classes you get 1000 constant pools. Reducer can merge all those files into a single one with some minor exceptions. It can also sort the constant pool so that constants which are used frequently consume less bytes when accessed. The funk-as3 test runner which links against FlexUnit and the Flex framework is only loosing 3.01% of its weight with the old Reducer. The new version reduces it by 17.81% already thanks to the ABC merging. Combine that with some LZMA love and we get 35.34%.

Besides you can call the LZMA compression as often as you want for some basic obfuscation. The LZMA compression alone is already a (weak) obfuscation of your bytecode.

Last but not least: Good news everyone! Scala 2.8 arrived so this is the last time you will have to update it for a while.

You can download the latest Apparat version at GoogleCode. Scala 2.8.0 is required.

You might ask what the hell this is about. So in the current state you can download Apparat from Google Code. Then you have to have a working Scala installation which has been used to build Apparat. Whenever Scala is updated, I have to updated Apparat, and you will have to download Apparat again and install a new Scala version. This is absolutely cumbersome. This will change of course when Scala 2.8 is officially released.

I know that some people will always require command line access for Apparat. I am sorry for you at the moment that we have to play this game until 2.8 is out.

For the rest this is good news. If you have a working Maven 3.x version you can use the Apparat plugin and get automatic updates. This means you have to configure your project only once and do not bother with Scala and Apparat anymore. In fact if you want to you could also use the Apparat snapshot repository and get live updates.

Project configuration and setup is something one should not have to deal with. Therefore you can use the archetypes. I have built one for TurboDieselSportInjection.

mvn archetype:generate \
  -DarchetypeRepository=http://oss.sonatype.org/content/repositories/snapshots \
  -DarchetypeGroupId=com.googlecode.apparat \
  -DarchetypeArtifactId=apparat-archetype-tdsi \
  -DarchetypeVersion=1.0-SNAPSHOT

This terminal command is all you need to do to create a new project that is ready to compile — with TurboDieselSportInjection enabled. And it will automatically use the latest Apparat version.

Shawn Pucknell is obviously raising the bar. This will be a tough time for an ordinary speaker like me. However I have no other intentions than giving a lecture that proves itself worthy of this event.

A big thank you goes out to the organizers and the Flash community. It really shows that the opensource work I do is appreciated and not meaningless.

Part of the prize I already received has been donated to Eugene Zatepyakin. I think he is doing great work on ASSURF and was in desperate need of an FDT license ;)

Thank you. I hope I will be able to surprise you with some new stuff later this year.

Use the inline feature with care. Apparat does not try to optimize your code and performs nothing but dead simple inlining. This can lead to slower code due to the creation of lots of local registers. Your code gets also much bigger and will require more space in memory. I am actually not a fan of manual inlining at all. I think it makes only sense to inline code if you have a powerful optimizer available that will cleanup the whole mess.

The fun story about this example is that the inlined version is slower using the lastes Flash Player release candidate if you have only 40.000 particles. That is why I increased the number of particles to 80.000 ;). I developed the example using an old standalone player and the inlined version was nearly twice as fast. However when I watched the example in the browser with the latest release candidate the game was completely different. Kudos to Adobe for significantly improving the Flash Player performance!

• AS3-only Version
• Inline Version
• Source

So if you want to have quick and dirty inlining capabilities: this is for you. It is an easy fix for a feature a lot of people have asked for. I will continue working on TAAS to implement this much better in the future.

However when deploying you can spend some extra time compressing your SWF files with the best tools available. 7-Zip is for instance such a tool and achieves a great compression ratio.

If you have the 7z executable on your PATH Apparat will make use of it to achieve the best compression for your SWF files. More configuration options are available here.

This feature is currently only implemented for SWF files and not SWCs. However every tool will make use of it by default. So if you are running Reducer and have no graphics in your SWF files you can still get a better compression.

An example is straight from the sources:

reducer -i as3\Apparat.Tests.AS3\bin\Test07.swf
[i] Apparat -- http://apparat.googlecode.com/
[i] Launching tool: Reducer
[i] Waiting for 7z ...
[i] Compression ratio: 18.224573%
[i] Total bytes: 310
[i] Completed in 547ms.

Note please that this SWF file does not contain any graphical assets and we got still a ratio of 18%. Our main audiotool.swf file is compressed by about 10% — about 200kb — and contains no graphical assets either.

You can download the latest Apparat on Google Code. Please note that you will need Scala 2.8 RC1 as well.

We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.

That is so right. The first thing that comes to my mind is Java on the Mac: sub-standard, castrated and broken. The second argument is even better. Intermediate layers can hinder the progress of a platform. So true. Apple, the intermediate layer between you and the iPhone, stops you from improving the platform. You have built something cool — like Unity3D — and can empower creative people with better tools? Sorry, you are out.

The only way to improve the progress of a platform is by opening it up. Yes, I think we have been there before.

Sounds strange doesn’t it? Thank god this was just a fictional interview and will never become reality.

However the current version is named Firestarter for a reason. What you see online is just the tip of the iceberg. I can not wait to start implementing all the cool features that will separate us from traditional software ;)

An important aspect is that when I am talking about modules I am not talking about “Flex Modules” but the more generic term for a part of a project.

First of all you have to make sure to fulfill some requirements. You can not assume that every developer is working on the same platform using the same IDE with the same settings. But you must assume that your project will not be built from an IDE. You must also assure that the dependencies between projects are up to date across different platforms and IDEs. Once you have figured out how to do that you might want to think about a strategy to compile your modules.

Today I want to explore the idea of parallel compilation across a cluster of machines to yield optimal compile speed for ActionScript projects. First of all, you can not assume that a developer can always keep all modules up to date. Depending on the dependency graph of your projects compilation migh take very long. For instance we have 103 modules at Hobnox. This means we have 103 different compile targets with different dependencies, each yielding its own SWF/SWC file. We also have a “standard library” that is included in nearly every project. Changing this library will require the developer to recompile all 103 modules to update them.

To illustrate this example I want to explain what we went through.

1. We used FDT to develop our project. Since FDT is Eclipse based every module was represented as a separate project with dependencies to other projects. FDT however compiles your project only once you launch it. And it does not do this automatically for your dependency graph. As a result you have to manually compile 103 modules in the correct order. This would not be the problem if FDT’s live error highlightning and code analysis would not work on a SWC basis. But since the actual source-code between projects is not analyzed we had to launch all 103 modules to propagate a possible error or change. This was for us the point when we had to make a switch.
2. Ant was our second idea to build our FDT projects automatically. However we had to keep module dependencies up to date in all the different Ant files because the FCSH requires that you include external libraries of a library also in a successor of another library. This means if A requires B and C requires A. Then C requires also B. So we had to keep 103 Ant targets up to date for each change.
3. A custom build. We started working with a custom build tool I have developed in Scala. This build tool was smart enough to figure out which modules have to be recompiled without launching the ActionScript compiler. It also figured out which projects could be compiled in parallel since the ActionScript compiler is written in a way that IO is not the only bottleneck. We had an enormous improvement in compile time and usability for the developer since module dependencies where handled automatically.
4. We switched from FDT to IntelliJ IDEA since it offered us more features that we needed. IntelliJ came also with a much better strategy to compile modules. Basically it had the feature we always missed for FDT to automatically include libraries and to compile modules in the correct order automatically. However the guys at JetBrains made a mistake by counting on FCSH. The short story is that FCSH is absolutely not capable of handling a large codebase. What happened to us was that when we started a build FCSH would take up as much memory as it could, getting much slower until it finally crashed. Then FCSH started from scratch, consumed the maximum amount of memory again and crashed. This happend until a project was finally compiled but took also more than 15 minutes for a single change we made. This was of course unacceptable. Fortunately JetBrains implemented a feature request from us into IntelliJ IDEA which comes close to our custom build. From now on projects are compiled in parallel without using FCSH and without asking launching the compiler if no change has been made. This way we are able to work again. However only if we compile just a short amount of all modules since the main bottleneck is still the compiler.
5. A continuous integration server was our last option. This is a custom build server and we are using it until today. After each SVN commit we are building the required modules and their dependencies now automatically on a dedicated server. A change in the standard library takes about four minutes to complete now on a quad core. But the good thing is that we have set our main project to exclude a lot of libraries. The custom build takes care of that and we are loading now modules from the server. That way we can still compile local and include libraries we frequently change. Other libraries are loaded from the server and included at runtime.

So the question is if this is now the ultimate solution. A custom continuous integration server that takes more than 4 minutes to propagate a change after a SVN commit? I do not think so. And here comes Scala into the game again. There is a project available called Swarm. It makes use of Scala’s support for serializable delimited continuations. This means you can pause the state of your current program, send it to a different node in your cluster and continue with the program on that machine. And Swarm makes this task extremely simple. So for now a new research project is to take advantage of this feature. We can basically have one master server like Hudson or TeamCity and write a plugin for it that makes use of Scala Swarm. Swarm could be based on nodes in the office, normal computers and maybe a couple of dedicated servers to compile modules in parallel on multiple nodes. Each node would have to keep the VCS up to date. That way we should be able to compile projects much quicker and have a much better workflow in a large codebase. Besides that if you work with a CI server than you could also have the task of code analysis using FlexPMD for instance done on another machine as well.

I am really looking forward to this project when I have some time to work on it. My goal is to develop a plug-in for TeamCity that we will use internally first. I expect to reduce the time for a full rebuild from about 4min to something like 30sec. This would be a huge benefit. I also hope that we will be able to make that plug-in available to the public.

First of all we have to aknowledge that ActionScript has some great features. Those include implicit getters and setters or method closures for instance. Java 7 will have method closures finally after a lot of argy-bargy about their complexity et cetera. ActionScript developers are used to method closures and are buddy-buddy with them since Flash 4 I think.

But what is the real advantage of ActionScript? Here are my thoughts.

1. Poor Performance

   Yes. We have been educated to optimize the hell out of our code. We have been educated to think about our code and how it performs. We have been educated to be creative with our tools, to tinker around. I know that this is not something to be essentially proud of but it led to a lot of creative and astonishing experiments. If you would tell a Java programmer you are still developing object pools they will laugh at you for a good reason. This is where the poor performance is annoying but something is very important: the potential. Think with the mind of a carpetbagger. Shares on the stock-market that never have a downturn are less interesting because there is less profit potential. So why am I talking about this? It is quite simple: Flash has still a lot of potential for growth. Flash did not pass its zenith already like other virtual machines. This makes me very optimistic for the future. There is still so much potential for the growth in performance and I think that Apparat has shown this as well.

2. Forced Asynchronism

   ActionScript has no ability to perform blocking operations (despite of AIR). This makes every application responsive. If you load files from an external source like a URL your application will stay responsive because you have to add listeners that react on certain events. I know this is somtimes cumbersome but every good application should make use of asynchronous IO for instance. If people are lazy they will simply spawn a new thread to perform blocking operations which is also okay but less performant. Usually the simple example is a server where you would spawn a new thread for every client. This is the worst you can do and Java tackles this issue with its NIO. However a lot of people do not make use of NIO because they think it is hard to use for common tasks.

3. Events

   Events are a great way to achieve concurrency. Some people call this immutable message passing. If your events do not contain state or are immutable, you have a powerful system to tackle concurrency. Basically this is what the EventDispatcher is all about. You add listeners for certain messages to a dispatcher and then you react on a message when it is dispatched to you. Again we have been educated to use a system which forces us to write responsive applications that is not based on synchronization and locks like Java or C++. If Adobe decides to implement multithreading in the Flash Player I hope they will choose to implement the approach of Erlang which is all about immutable events and event dispatchers. The only difference is that Erlang programmers call them actors.

This post is not an ode to ActionScript. There are still major issues like the lack of parameterized types. But I do think that there is a lot of potential. We can grow with the language and we can tackle upcomming issues. Concurrency is one of them, limited resources on a mobile device are another one.