Stop Coding!

The Unofficial Flex Compiler Blog

Posts Tagged ‘Flex SDK

–tools-locale in Flex 4.x.x is very useful, but…

with 11 comments

There is a new compiler argument in Flex 4.x. It’s –tools-locale. For example, specifying –tools-locale=en would instruct the compiler to output errors/warnings in English. The following is the output of “mxmlc -help tools-locale”:

-tools-locale <string>
specifies the locale used by the compiler when reporting errors and warnings.

Of course, the compiler, by default, uses Locale.getDefault() (i.e. most of the time, JVM -Duser.language). Having this compiler argument is useful for tool integration because a tool could use the OS default language but the compiler could output English errors/warnings.

But why wouldn’t developers choose to read compiler errors/warnings in their native languages and would like to have a way to configure the compiler to output in e.g. English? Is it because the translations are not good? Can someone please comment on the qualities of the non-English compiler error/warning messages?

Written by Clement Wong

July 21, 2010 at 3:46 pm

It’s Time To Hit The Road!

with 2 comments

I’m going to present at the Flex User Group meetings in Toronto and Ottawa this month (2010/06) and in Washington DC next month (2010/07).

Title: In-depth look at the Flex compiler and HFCD


  1. Basic architecture of the Flex compiler
  2. Compiler extensibility
  3. Overview of the Flex compiler API
  4. HellFire Compiler Daemon(HFCD)

Toronto (June 10th, 2010):

Ottawa (June 23rd, 2010):

Washington DC (July 7th, 2010):

If you don’t live there but want me to give a talk, please contact me or your Flex UG organizer.

See you there.

Written by Clement Wong

June 2, 2010 at 9:58 am

HFCD 4 Is Now Officially Available.

Hi, I’m pleased to announce that HFCD 4 is now officially available.

HFCD 4 for Flash Builder achieves better Flex (full and incremental) build performance than Flex 3 and Flex 4 by utilizing:

  1. all of the Flex 4 compiler performance improvements
  2. multicore processor technology
  3. techniques to build Flex apps in the background.

and allows builds to be distributed to multiple machines on a local network. The HFCD ant tasks also make it easy to integrate HFCD with custom build systems or popular build systems like Hudson CI, etc.

To learn more about HFCD, please visit

Those who purchased HFCD 3 before today will receive their FREE copies of HFCD 4. Sorry, this special offer ends today.

But don’t be disappointed. If you find a HFCD bug and file it and I can reproduce it, you will get a HFCD license for free. Click here for details. The offer ends by the end of this month (2010/04) but I’m going to extend it until further notice…

Download HFCD:

How -omit-trace-statements Works… Or Does NOT…

with 18 comments

Flex 4 introduces a new compiler option, –compiler.omit-trace-statements. The purpose of this compiler option is to remove trace() calls from your code when compiling in release (not debug) mode.

How does this work? Well, let’s take a look at the compiler code. First of all, where should you start? Usually, when trying to track down how a compiler option works, one would start from where the compiler option is set. If you have the compiler code, look for a method called 'cfgOmitTraceStatements' in Basically, the fully-qualified compiler option name kinda gives you the hint!

From there, you can search for all the references to 'omitTraceStatements' in the compiler code and eventually, you should end up in a file called in the actionscript compiler.

The callExpression method is responsible for constructing a syntax tree node that represents a function call in your code. In fact, almost all methods in are helper methods, responsible for syntax tree constructions. You can see in the code that if –omit-trace-statements is true and if the function call is trace(), the callExpression method simply skips the syntax tree node creation and return an empty statement.

Now, this implementation puzzles me!

The problem I have with this implementation is that it is done too early in the compilation. When constructing a syntax tree, the compiler has not yet done any analysis on the code and has not yet resolved the trace() call to the player built-in trace() function. To test my theory, I use a simple example:

When compiled with –omit-trace-statements=false, the test case changes the label text from 'Label' to 'foobar'. That means, the compiler resolves the trace() call to the local function, not the player built-in trace(). Now, turn on the trace statement omission:

The compiler skips over the syntax tree node generation for the click event handler.

I set a breakpoint on the green line above and verified what is being skipped over is in fact the trace() call in the click event handler.

As a result, the compiler generates an incorrect SWF. The label text does not change from 'Label' to 'foobar' when the button is clicked…

Conceptually speaking, I consider the –omit-trace-statements implementation totally busted!

In my opinion, the implementation should be done during code generation. Everything should be resolved right before code generation, so when the compiler traverses the tree one last time, it can use the compiler option there to skip the bytecode generation.

Practically speaking though, the current implementation maybe okay because no one does anything like I did in the trick test case above.

Hope you enjoy the trip down the compiler lane… 🙂

Written by Clement Wong

April 21, 2010 at 1:18 pm

HFCD: File A Bug Report And Get A License For FREE!

HFCD 4 beta period is going to end and it will be officially released very soon. In order to make HFCD as stable as possible before the finish line, I would like to ask for more participations. If you file a HFCD bug report this month (April, 2010) [Update (2010/04/26) This offer will continue after April, 2010… until further notice) and I can reproduce the bug, you will get a HFCD license for free!

Here are the rules. You must:

  1. File against the latest HFCD build.
  2. Use the online Bug Report Submission Form.
  3. Include a detailed bug description, steps to reproduce and a Flash Builder project test case.

If multiple bug reports are filed against the same issue, only the first submitter will receive a HFCD license.

Rules are subject to change without notice.

Written by Clement Wong

April 14, 2010 at 11:49 am

[2010/04/02] Stop Coding! Did you know…

leave a comment »

Stop Coding! Did you know that Flex incremental compiler performance  varies based on what you change in a class? (Of course! What am I smoking!?) In both Flex 3 and 4, when you make a code change in an ActionScript class, the incremental compilation invalidates the build data (CompilationUnit) for the class you touched and all of its subclasses (or boardly speaking, its dependents) and compile them again. However, if your code change does not involve API changes (e.g. additions or deletions of public functions or variables), the build data for the subclasses and dependent classes stay.

Let me use the HFCD output to illustrate this. It takes about 6.7s (CPU time) to do a full, clean compile of framework.swc.

[Fri Apr 02 10:35:38 EDT 2010] compile(framework.swc) result=1 time=6695
[Fri Apr 02 10:35:46 EDT 2010] link(framework.swc) size=2013668 time=483

Then I add a function, doSomethingMeaningless() in The function has an empty body.

public function doSomethingMeaningless():void

Since this is a public function so it definitely changes the public API of The rule says at least all of its subclasses (a lot!) must be invalidated and compiled again in the incremental compilation. Okay, it takes about 4.5s (CPU time) to incrementally compile framework.swc.

[Fri Apr 02 10:36:03 EDT 2010] compile(framework.swc) result=1 time=4463
[Fri Apr 02 10:36:10 EDT 2010] link(framework.swc) size=2013907 time=467

Now, add something to the function, e.g. a trace() statement.

public function doSomethingMeaningless():void
trace("do something meaningless");

Again, UIComponent should be invalidated in the next incremental compilation. However, there is no public API change. All of its subclasses and dependent classes stay. The result? It takes only 1s (CPU time) to incrementally compile.

[Fri Apr 02 10:36:20 EDT 2010] compile(framework.swc) result=1 time=1088
[Fri Apr 02 10:36:21 EDT 2010] link(framework.swc) size=2013972 time=467

Of course, if you add 10,000 lines of code into the function, that’s a different story!

Note that this rule applies to ActionScript classes only. There is no API signature checking for MXML components. Yes, I know it would be nice to have that for MXML components. But it’s a lot more complicated to achieve than doing that for AS classes. Plus, MXML components are rarely deep in some foundation class hierarchies.

So what does this mean to you? Well, this “API signature checking” strategy in incremental compilations should help improve the flow of your daily coding activities if you group your API changes in a single “Save All” and avoid mixing API changes and function body changes. I’d say that this is a “good-to-know”, but don’t plan meticulously a few steps ahead what you want to save. Your brain should focus on coding… 🙂

Now, Start Coding!

Written by Clement Wong

April 2, 2010 at 11:10 am

HFCD 4 Now Supports Flex and Flash Builder 4 Final!

Last week was an exciting week. Flex 4 and Flash Builder 4 were out FINALLY! I had HFCD 3 going final as well… actually, one business day before the Flex 4 official announcement!

Now that Flex 4 and Flash Builder 4 are available, it’s time to upgrade HFCD 4 from supporting Gumbo beta 2 to the Flex 4 final release. I spent some time last week porting and testing some codes and I’m pleased to announce that HFCD 4 (remains in beta) now supports Flex 4 and Flash Builder 4.

It’s true that HFCD 4 currently remains in beta. I just want to hear some more feedback and work out some more kinks before upgrading its status. If you ask me, I’d rate this update closer to release candidate than early beta w.r.t. quality.

As I mentioned in my previous post, HFCD is now a product of Bytecode Workshop, Inc. You can download the installers there. Several useful links are below:

After using the compiler in Flex 4 for a few days, I can see that the compiler is faster than its Flex 3 counterpart. Congrats to the folks at Adobe on this achievement. But since HFCD uses whatever is improved in Flex and it’s architected differently (and of course, with the use of multi-core technology), HFCD continues to outperform Flex in most medium-to-large project workspace situations. The build performance when combining Flash Builder 4, Flex 4 and HFCD 4 is truly amazing and I had already talked about it awhile back.

My plan is that HFCD 4 will not stay long in the beta status and will move aggressively towards the final release, so please help me by trying it when you get a chance. Thanks!