Sprouts now supports Flex Debugger (FDB), Flex Compiler SHell (FCSH) and Continuous Integration (CI)!

Posted by Luke Bayes Wed, 07 Jan 2009 19:32:00 GMT

Today brings a major set of improvements to the Sprouts ActionScript 3 bundle (and related gems).

We have introduced three major features that you can retrieve by opening a terminal and entering:

First there was the Flex Compiler SHell

There is a new FCSH rake task available that will change your life if you’re living outside the comfy confines of Flex Builder. This feature is still beta quality and could use your help putting it through it’s paces.

FCSH is a long-lived process that caches compilation data and allows for incremental builds as we work. This is a huge deal for even the smallest projects simply because the entire compiler stays in memory between rake builds.

To take advantage of FCSH:

• Open up a new terminal

• cd to your project directory

• run: rake fcsh:start

• Open up your rakefile, locate your ProjectModel (or custom mxmlc tasks), and add the following to the relevant blocks: use_fcsh = true

At the time of this writing, there may still be issues with the implementation. So if your compilations are questionable, simply kill the FCSH process (with CTRL+C), restart it, and send us an email.

Then there was FDB

The Flex Debugger is just a humble, simple, command-line debugger. What it allows us to do though, can be quite beautiful. Within the confines of it’s text-based interface, you’ll find all the features you’ve come to love in the GUI debugger found in Flex Builder. You can set breakpoints with a file name and line number. You can step through your code and inspect your application at any time. You can break on exceptions and ask for local variables and their values. You can change or set values all over the place. You can basically get a window into your running SWF file.

There are some drawbacks to the trusty FDB though…

Firstly, it doesn’t allow us to define a specific instance of the Flash Player to execute – it uses whatever application your system has defined as the default executor of SWF content.

If you’ve recently installed Flash CS3, this happens to be the Flash Authoring tool – which is indisputably the choice for me – Flash Authoring is exactly what I want to launch when double-clicking a SWF file!

At any rate, you may need to manually configure your system to launch the Flash Debug Player to handle SWF content. Sprouts will likely have one installed here:

Windows: $USER_HOME/Local Settings/Application Data/Sprouts/cache/0.7/sprout-flashplayer-tool/archive/....

OS X: $USER_HOME/Library/Sprouts/cache/0.7/sprout-flashplayer-tool/archive/....

*nix: $USER_HOME/.sprouts/cache/0.7/sprout-flashplayer-tool/archive/....

Or you can of course go get a debug player from Adobe and run their installer.

You can use FDB with our task helpers by setting use_fdb = true in your project model, or you can create custom FDB tasks something like this:

fdb :debugger do |t|
  t.file = 'bin/SomeProject-debug.swf'
  t.run
  t.break = 'SomeProject.as:6'
  t.continue

More info can be found in the rdocs .

Finally, with great FDB comes great Continuous Integration

Admittedly, most of us won’t find a whole lot of use for the old command-line debugger but that shouldn’t stop us from using it for our own benefit. FDB happens to be the only way I know of to avoid getting those nasty GUI dialogs to pop up with uncaught runtime exceptions. If you’re running Cruise Control or some such continuous integration server with your ActionScript or Flex project, you may have been forced to create some kind of ridiculous and arbitrary task timeout that crushes your whole x session.

Or maybe you just never check in code that has uncaught runtime exceptions? You tricky devil. Oh, to bask in the glory of your brilliance.

So here are the rest of us peasants. Standing at the foot of the very first, viable, real ActionScript/Flex project that can be instantly integrated with any industry standard continuous integration server. I use the words ‘first, ‘viable’ and ‘real’ because my understanding is that anything that’s been done before today was busted by these damn exception dialogs.

If you want to integrate your Sprout project with a continuous integration server, you’ll need to do the following:

• Log into the server using the same user account that executes the CI services
• Following the instructions for your server platform (usually *nix), get a new, phony Sprout project compiling and running.
• Ensure that your CI process has access to a windowing environment
• Set up your CI server exactly how you would for any other technology and ask it to execute rake cruise on your Rakefile.
• Set up your CI server to collect and display AsUnitResults.xml as a test results artifact next to your Rakefile.
• Pat yourself on the back for being a maverick, a trailblazer, a veritable man’s man (or woman’s woman as the case may be) – because you are now part of a historic moment!

In closing, big thanks go to Dru Nelson of BrightRoll who helped finance these features and bring them to fruition many months before I would have actually gotten around to it!