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.

Debugging WPF/e in Firefox

I'm playing around with WPF/e and still haven't written a lick of code on it yet. Still learning about how to handle asynchronous events, using XAML with JavaScript, and how to piece it all together. But I did find something pretty cool already for those of you who are, like me, Firefox users.

Firefox has a full-on javascript debugger, originally called 'Venkman' that you can use to debug your javascript. And while its known as the 'Javascript Debugger' in the menu, I'm going to call it Venkman because that sounds way cooler. And since WPF/e is actually executed using Firefox's javascript engine, that means Venkman will debug your WPF/e application.

And by 'debugging' I don't mean 'crap that didn't work, I'll echo a bunch of junk to the command line' debugging. I'm talking full-on, hot javascript on javascript action. I'm not kidding, because the debugger is actually written in javascript!

Venkman supports breakpoints, variable watching, expression evaluation, profiling, and more. It is an industrial strength tool, and its actually sort of intimidating to me, because I'm more from the 'echo a bunch of junk to the command line' school.

And so how do you use this tool with your WPF/e application?

First install Venkman, which installs quite easily as a Firefox extension.

Next restart Firefox, and open the 'Javascript Debugger'. There you are. Easy, wasn't it?

As an example debugging session, let's debug the 'Sprawl' game. Open Venkman. In a tab, open up the following url:

http://channel9.msdn.com/playground/wpfe/sprawl/default.html

Click on the 'Open Windows' tab to display a list of open windows. Expand Browser Window->default.html and you'll see a list of all the javascript files used within the game. Double click on 'hex.js' and you'll see the actual javascript for each tile within the game. To the left of the line numbers you'll see dashes next to lines that have code on them. Click in this space on line 3 in order to add a 'breakpoint' to the line. You should now see a white 'B' against a red background.

Now refresh the browser. This can take a WHILE, because the debugged javascript takes longer to execute. Start a game. After entering your name and clicking 'Ok' you'll notice that the application stops, and the debugger breaks at line 3 in the hex.js file. Click the 'Continue' button a bunch. You'll notice that every time you click on the button, another tile is created.

This is probably amusing for about 30 seconds, and then you'll probably want to move on without pressing continue another 100 times. Clicking once on your break point will change it to an 'F' against an orange breakpoint. This means its a future breakpoint, and it will stop again if the app is debugged again. Clicking twice clears the breakpoint entirely. Do so, and then press 'Continue' to progress through the application as normal.

This is a really great debugger but unfortunately there seem to be a few hiccups. The worst is that when you close the debugger, you cannot re-open it. Worse still, if you try to re-open it, it will hang a process, and you'll have to manually kill firefox.exe in your Task Manager. Lastly, the time it takes to load up a WPF/e project is way too long. But considering I'm learning the platform, right now I'm just using it to step through applications and see how others do it.

Welcome!

Hey all! Welcome to my flipping sweet blog. Here you will find me jabbering about all manner of stuff and junk, but mainly flash development. Currently I work at Terralever developing interactive applications. Big love to the TL family!

So today comes the announcement of the new Adobe Flash CS3! Right now the site is getting hammered, and there is no expected launch date. But it is nice to see a listing of new features. Integration into the Adobe family is going to make life a lot easier for everyone.

I really like that they aren't shy about the prospect of using flash as a video tool:

Adobe After Effects integration

Export individual layers with transparency using the new QuickTime exporter, and import them into After Effects for advanced manipulation. Import FLV directly from After Effects.

Some things are just ridiculously simple to do in Flash that would require too much time in After Effects. I could've really used this feature in the past on dvd projects, and I'm sure it will come in handy!

Well, it'll probably take a couple blog entries before I get into a good cadence. Stay tuned, as I'll be posting little demos, source code, and giving my opinionated opinions to anyone who'll read :P.