jEdit Flex Compiler Shell Integration

Last night I stumbled across a great little hack that's really been a missing piece of the Flex action for me. Flex Builder's zippy compilation is one of the best features of the commercial Flex product, and one I sorely missed. But now I've figured a way to integrate the Flex Compiler Shell into jEdit, and so now my text editor of choice works very well with my compiler of choice.

jEdit's Console plugin allows you to integrate a shell into the interface. This shell is scriptable via jEdit's quite extensible macros. So we have two macros, one to initialize the compiler shell, and another to re-compile once initialized.

First macro:

//Initiate the compiler
runCommandInConsole(view,"System","/path/to/fcsh");
runCommandInConsole(view,"System","mxmlc ... very long list of arguments for your compile :P ...");

Recompile macro, bound to Ctrl-Enter:

runCommandInConsole(view,"System","compile 1");

This makes me a very happy boy! I have verified that these instructions should work on Windows, too (as I'm doing this on Linux).

Trace Output on Linux with Flash Player 9

I just spent about 45 minutes getting my flash player to trace to a text file. So as of this writing, here are the current things that you should watch out for when attempting to trace() out with flash on linux:

Make sure that you have the debugger version installed. If you are using Ubuntu, or another distro that uses package management, remove the flash player package. On Ubuntu Feisty Fawn, this is the flashplugin-nonfree package. Open synaptic and uncheck the package. It will warn you that you are removing the ubuntu-restricted-extras package also. Don't worry about this, as its a dummy package.

Install the debugger version from the adobe site. This is pretty straightforward.

Once installed, you must turn on the trace reporting by creating a file in your home directory called mm.cfg with the following contents:

TraceOutputFileEnable=1
ErrorReportingEnable=1
MaxWarnings=1

So what exactly will these three lines do? Well the first says that we should print out all trace() function calls to the file ~/.macromedia/Flash_Player/Logs/flashlog.txt. The second option says that we should also print out our stack traces and exceptions to the log file. Lastly MaxWarnings is how many lines the log file will contain until the player stops. This page goes more in depth.

A couple important points: The documentation is incorrect, and the output file is NOT ~/macromedia/Flash_Player/Logs/flashlog.txt but ~/.macromedia/Flash_Player/Logs/flashlog.txt . This is important because files with a '.' in front are hidden, so you won't see a 'macromedia' folder pop up in your home dir.

Secondly, the flash player is smart enough to create the ~/.macromedia/Flash_Player/Logs/flashlog.txt path, directories and all. So you do not need to create this path manually.

Ok, so now you've installed the debug version, and you've created your mm.cfg. Your logging to the file, and now you want to watch the output! Well, you have many options at your disposal. A favorite option is the FlashTracer extension for FireFox. Here is a special version that works on Linux.

Another option is to use 'tail' a basic command line program that displays the tail end of files:

tail -f ~/.macromedia/Flash_Player/Logs/flashlog.txt

As with all command line programs, you can pipe them to do fun interesting things :)

tail -f ~/.macromedia/Flash_Player/Logs/flashlog.txt | grep DEBUG

To just get all the lines with DEBUG on them.

tail -f ~/.macromedia/Flash_Player/Logs/flashlog.txt | grep -C 3 DEBUG

Get the lines that have DEBUG on them, and the lines around them (useful for seeing what happened before and after the line in question).

And here is a simple script that encapsulates the above tail usage into a simple program:

#!/bin/bash
if [ -z "$1" ] 
then
        tail -f ~/.macromedia/Flash_Player/Logs/flashlog.txt
else
        tail -f ~/.macromedia/Flash_Player/Logs/flashlog.txt | grep $1
fi

Flex Builder vs. The Other Guys

So I was attempting to think of good topics within which to blog about. In my current position I'm implementing processes more than writing code sometimes. But writing code is very dear to my heart. So the process of writing code, and writing quality code is something very blogworthy. There are lots of great blogs about this kind of thing. I really enjoy Paul Graham's work. Joel on Software is also fun sometimes.

Another topic is tools. Which tools to use for the job are something that coders get downright nasty about. Because using the wrong tool for the job is possibly the biggest faux pas a coder can make. Coders are, among other things, toolbuilders. Everyone at some point says to themself 'there has got to be a better way to do this mind-numbing repetitive task. Perhaps I can build some sort of machine to do it for me.' And so coders do mental backflips massaging code to create new tools that do these tasks. If you're a coder and you are doing mind-numbingly repetitive tasks, then you're doing something wrong.

Adobe (and when I say Adobe I really mean Macromedia) has done the world a great favor with Flex and Flex Builder. They have built tools that are modular, understandable, fast, and stable. So many props for so many great design decisions:

The choice of java for their sdk gives it portability, reliability, and the headroom to focus on getting it right.
The mxml specification is easy to read, easy to work on, and easy to love.
The framework is great. Well documented. Very consistent. Great usage of constants, interfaces and strongly typed events make the framework a joy to work with. Data binding is fantastic.

I started out writing AS3 in Flex Builder 2. This was ok for a while. I appreciated the crutches that Macromedia created to get you started. The code completion worked fairly well. The automatic compilation is straightforward. Things only became more hairy when I really started to want more control.

So what are the options? Well, Adobe does tout their Flex 2 SDK. Well, how does this measure up to the commercial product? The SDK is simply a command-line compiler, meaning you really need to know about build software and how to use build tools. The natural fit for eclipse for building is Ant. This works quite well for flash too. So what about an editor? jEdit is a fantastic option for development that not only integrates with ant, but has syntax highlighting, and many, many features and customization, including a MUCH better search than Eclipse.

So how smooth is development of projects without Flex Builder? Well, its a give and take. I've found that using ant, jEdit and the Flex Compiler shell has given me a ton of freedom. Its also made setting up the same project on different computers very easy. The real price comes at the loss of code completion and compilation speed.

Flex Builder offers the slick 'Design View', too. This is probably not that useful for most programmers after about 3 weeks of use. I end up coding the final look anyway. Plus the faster compilation means its always compiling, which means I get random errors and popups when I'm typing. The interruptions and the sometimes not-so-responsive user interface is what really made me move on from Flex Builder back to jEdit.