Stop Coding!

The Unofficial Flex Compiler Blog

Impressive Hardware Setup For Running HFCD

with one comment

Recently I’ve received an email from a Flex developer. He told me that his development team has been using HFCD for Flex development. What impressed me was his team hardware setup. Basically, his team of developers connect Flex Builder running on their laptops to multiple instances of HFCD running on a powerful LAN server. He is quite happy about the improved development experience.

The server we’re sharing for compilation is a Dell box with basic hardware config:

OS: Solaris 10
CPU: Dual quad-core Xeon 2.8ghz (two threads per core — OS reports 16 cores)
Memory: 32GB
Ethernet: 4 connected Ethernet connections (mutliplexed between Solaris Zones)

This box hosts a few zones that do various other things too (host db’s, app servers), however all for dev purposes so it’s never generally that busy.

As you might guess, using HFCD on this box to compile has significant advantages to the laptops we develop on.

Awesome! 🙂

Written by Clement Wong

July 27, 2010 at 4:08 pm

–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

HFCD zip Arhives for Ant Lovers

Some developers don’t use Flex Builder and wonder how they can use HFCD from the command line or with their favorite Flex IDEs.

I have just made some HFCD zip archives available:

You don’t have to download all of them… just pick the version that you intend to use.

Unzip the archive. You’ll find a build.xml inside. Edit ${flex.sdk.dir} to point to your corresponding Flex SDK installation directory. Run ant. After running build.xml, you should see the HFCD “client” directory and HFCD “server” directory.

You start HFCD by running server/bin/hfcd. If you want to use ant to call HFCD, use client/lib/hfcd-ant-tasks.jar. For more information on how to use the HFCD ant tasks, please check out the HFCD ant task language reference:

Some developers want to see Maven/Flexmojos support. I like that idea too and I’m going to investigate. Stay tuned.

Written by Clement Wong

July 21, 2010 at 10:00 am

HFCD For Flex 4.1 Now Available

Dear readers,

HFCD for Flex 4.1 is now available. Sorry for the delay. I thought it would take me a week or two to release it. But I wasted a little bit of time working on the wrong Flex SDK revision! Boo…

The good news is that there is no Flex Compiler API changes in Flex 4.1. However, there will be some new methods added to the API in the upcoming Flex 4.5.

I think the most notable fix in the compiler in 4.1 is SDK-25206. If you occasionally switch between airglobal.swc and playerglobal.swc in your Flex Builder workspace, you may run into this issue. But this is a good fix and helps build performance too.

HFCD 4ドキュメントは現在日本語で入手可能です。

このたびHFCD 4の日本語版ドキュメントが、ご利用いただけるようになりましたのでお知らせします。

Written by Clement Wong

July 5, 2010 at 6:17 pm

HFCD For Flex 4.1 Coming Soon…

leave a comment »

I started working on an HFCD update for Flex 4.1 yesterday. Looks like it will not be a lot of work for me so I plan to make it available early next week.

If you would like to know the progress, you can follow me on (@stopcoding) Twitter.

Pay Attention To compc -include-sources

with one comment

Have you ever used the compc “–include-sources” command-line option (or used this command-line option in Flex Builder Library projects) before?

If your answer is yes, you should know that this command-line option leads the compiler (compc) to use a slower and more memory-intensive algorithm. Why? Before I tell you why, take a look at the two compile algorithms:

The two algorithms are in the batch1() and batch2() methods. The batch1() method is the slower and memory-intensive one. The batch2() method is more complicated but more opportunistic; uses less memory and hence runs faster.

You can see that the algorithm in the batch1() method is more “synchronized”. Basically, the algorithm keeps all the compilation units in the same compilation phase before moving all of them to the next phase. This algorithm was first developed in the early days (pre-beta 3) of the Flex 2 development cycle. During that time, everything (including the AS3 compiler, AVM+) was a moving target. The compiler team needed to provide a relatively stable compiler for the framework team to use on a daily basis. The algorithm was therefore somewhat conservative and it was okay to use a little more memory or run slower.

But why the “–include-sources” command-line option leads the compiler to use the batch1() method?

Well, Flex developers learn from the official Flex documentation that they should put only one public, top-level definition (e.g. classes, functions, variables, namespaces are valid definitions in AS3) in a source file. This is mostly due to the fact that the compiler looks for definitions from the source path based on the names of the files in the source path.

But if you tell the compiler an explicit list of source files to compile (i.e. by using the “–include-sources” command-line option), you are allowed to put multiple, public top-level definitions in any one of those source files. Okay, what’s so nice about putting multiple, public top-level definitions in a source file? Well, I don’t know. Some developers simply want easy source file management by grouping many small classes/functions into a few files (playerglobal.swc is a prime example).

But one not-so-nice thing about these multi-definition source files is that the compiler needs to know what definitions the source files have before trying to look up missing/unresolved definitions from the source path. That means, “parsing” all of them before “analyzing” them. That sounds exactly like what the algorithm in batch1() does!

My advice? If your SWC projects are small, it’s okay to use “–include-sources”. Otherwise, stick with “–include-classes”.

Written by Clement Wong

June 17, 2010 at 12:30 pm