In the past couple of months, I managed to fix a few issues and add some enhancements to HFCD. They are now in the latest HFCD build (2010-09-18). Let me briefly describe what they are:

Exclusion Filters

The default behavior of the HFCD plugin is to upload all of the files in a Flex project to HFCD. This obviously is not ideal because a lot of these files are unnecessary for Flex compilations. So now there is a “Exclusion Filters” preference panel under “HellFire Compiler”. You can specify files and directories that you don’t want to be transferred to HFCD there. The default value is “.svn”, which you all know, is a directory created by Subversion. You could add a few more, e.g. .settings, bin-release, etc.

Launch Server

In order to use HFCD, a developer must start HFCD from Terminal (Mac OSX) or Command Prompt (Windows) before he/she starts Flex/Flash Builder. This is one extra step that some developers would like to skip. They would like to see Flex/Flash Builder to launch HFCD automatically. Well, as you know, the HFCD installer automatically setups a launch configuration in Flex/Flash Builder:

The HFCD plugin could simply launch HFCD based on this launch configuration. So now there is a “Launch Server” preference panel under “HellFire Compiler”. You could specify the name of the launch configuration in this preference panel. The HFCD plugin will take care of starting HFCD when the workbench loads and shutting down HFCD when the workbench closes. If you don’t specify a launch configuration name in this preference panel, it’s okay… that means you prefer to launch HFCD manually.

New <property> Tags in Auto-generated build.xml

Developers can use the “Generate Apache Ant build.xml” function to generate build.xml for their workspaces. It’s great for using such build.xml in CI. The paths in build.xml come from the compiler and therefore they are all fully-qualified paths. Usually, before you can use the build.xml file in your CI environment, you need to fix the paths. But the paths are everywhere in build.xml… making it quite cumbersome to fix. Now, there are 3 new <property> tags (${fb.workspace.dir}, ${user.home} and ${flex.sdk.dir}) for three of the most common paths. Hope this consolidation helps.

Turn Off HFCD Background Build During Debugging

Some developers like to make code changes while debugging. As you know, code changes trigger HFCD background builds. If you’re debugging, the background builds might slow down debugging. Now, the HFCD plugin detects whether debugging is in progress and instructs HFCD not to run background builds after receiving code changes.

HFCD “References” View

The primary function of the Flex compiler is to generate SWF output. But there are so many things that the compiler knows about. For example, given a definition, the compiler knows about its dependencies and its references. The dependencies are not difficult for developers to figure out because one can pretty much see that in the import statement list. However, it’s quite challenging to manually and accurately locate all of the references given a definition. One could use Flash Builder’s “References –> Workspace” feature but it takes extremely long time to execute at times. Now there is a new HFCD “References” View.

You simply open a file (MXML or AS). Set the editor active and open the “References” view. The view would ask HFCD for the dependencies and references for the definitions in the active editor window.

HFCD “ABC” View

And of course the compiler knows the bytecode it generates for the classes in your projects. One way to learn ABC bytecode is to look at what the compiler generates for the code you write. Now with HFCD, if you highlight a few lines of your code in the active editor and open the HFCD “ABC” view, the HFCD plugin would ask HFCD to return the bytecode that corresponds to the code on the highlighted lines.

The screenshot below shows the bytecode for the AS code on line 1445-1451 in UIComponent.as.

The HFCD “ABC” view is work in progress (the output could be better though…).

Hello, my name is Jeremy Petersen. I’m the Vice President of Technology at School Improvement Network, and I wanted to take a moment to write a review of my experiences with HFCD 4.

Let me start with a little background. The School Improvement Network http://www.schoolimprovement.com provides the solutions, products, and services that help teachers and educators increase student achievement. Our flag ship product is a large Adobe Flex application called PD 360. PD 360 is an on-demand professional learning system for teachers and educators, with a series of tools built around a library of video segments.

PD 360 started out as a simple on demand video player application back with Flex 2.0 in the fall of 2006. The application has followed the maturing of the Flex platform with a full Flex 3 rewrite, and is now in the process of a full Flex 4 rewrite. Along with the obvious advances and growth inherited in keeping up with latest versions of Flex/Flash Builder, the application has also grown exponentially in complexity, size, and features. In fact, our Flex 4 rewrite has a (insert expletive) 42 modules! The project has also gone from a couple of developers that tinkered on it in their spare time to team comprising of 4 full time Flex engineers, and 2 full time ColdFusion engineers.

Let me start out by saying that we love Flex 4, but after making the switch from Flex 3 and having rearchitected our application from the ground up (enter the 42 modules), we definitely noticed a HUGE hit in compile times. All of our engineers have very capable hardware (Corei7 etc). But to even change the text on a single button in the application would result in a 4-5 minute compile time. Talk about a drop in productivity.

Now, enter HFCD 4. One of our engineers read about it on a blog and decided to try it out. His results were too good to be true. After waiting a couple of weeks to make sure he did not have any issues, the rest of the team changed over on 30 day trial licenses to test things out. Remember that 4-5 minute compile time from before? With HFCD 4 , making changes to a single module, that compile time is down to 4-5 seconds! Granted changes to code that is linked in to multiple modules (say our controller etc) still take a couple of minutes to compile, but for most of the work our team is doing we are officially back in business of writing code and not reading blogs or firing up World of Warcraft in between every single run/ compile.

So it goes without saying that we love this product! But my review does not stop here. I have one other thing to comment on. The support of Clement Wong (HFCD creator). Clement went above and beyond our expectations in support and answering questions. For some reason my personal install had some issues (it ended up being Eclipse problems). Clement not only helped me via email, but even offered to do a phone call to get me up and running. In addition, he is very responsive to feature requests and suggestions.

HFCD comes with a free 30 day trial, so grab a copy and try it out. You have nothing to lose and everything to gain!

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?

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:

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!