Stop Coding!

The Unofficial Flex Compiler Blog

Posts Tagged ‘Flex Compiler

Flex 4.5.1 source merged to trunk. Thanks Jim!

with 4 comments

Two months after the official Flex 4.5 release, we finally see the code merged to trunk.

http://forums.adobe.com/thread/871350?tstart=0

 

Written by Clement Wong

July 6, 2011 at 9:32 pm

What’s New in the latest HFCD Build (2010-09-18)?

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…).

Written by Clement Wong

September 19, 2010 at 11:28 pm

Guest Post: HFCD 4 Review

with 2 comments

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!

–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:

http://bytecode-workshop.com/hfcd/3/download/hfcd_3.2.0_full.zip
http://bytecode-workshop.com/hfcd/3/download/hfcd_3.3.0_full.zip
http://bytecode-workshop.com/hfcd/3/download/hfcd_3.4.1_full.zip
http://bytecode-workshop.com/hfcd/3/download/hfcd_3.5.0_full.zip
http://bytecode-workshop.com/hfcd/4/download/hfcd_4.0.0_full.zip
http://bytecode-workshop.com/hfcd/4/download/hfcd_4.1.0_full.zip

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:

http://bytecode-workshop.com/hfcd/doc/HFCD-Ant-Task-Language-Reference.pdf

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 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:

http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/CompilerAPI.java

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

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

Agenda:

  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): http://www.torontoflex.org/torontoflex/index.html

Ottawa (June 23rd, 2010): http://www.eventbrite.com/event/704014727

Washington DC (July 7th, 2010): http://www.dc-flex.org/index.cfm

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 http://bytecode-workshop.com/.

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: http://bytecode-workshop.com

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

with 17 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 CompilerConfiguration.java. 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 NodeFactory.java 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 NodeFactory.java 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

Follow

Get every new post delivered to your Inbox.