TextMate/MTASC/XTrace Revisited

A couple of months ago I switched over to TextMate as my full-time AS editor. Previously I’d been using XCode with the PixelConsumption AS 2 framework. Although Textmate doesn’t have the nice code-hinting of that XCode framework, it does have an Actionscript bundle and autocomplete for strings already present in your document. TextMate’s snippets have also proved useful, allowing me to set up skeleton code for common things like private/public methods. There’s even the ever-useful Command-Enter hotkey to kick you over to the Flash IDE for compiles. The only thing that drives me batty is the well-documented project drawer refresh issue with mounted drives (a nifty workaround is described here).

I came upon this post at Wimer Hazenberg’s Monokai blog describing a TextMate/MTASC/XTrace workflow a while back, tried it, and shelved it when I couldn’t get XTrace to work with files I’d placed on a webserver. I’ve since worked out the XTrace issue (a crossdomain policy served from my Mac’s localhost did the trick) so I decided to take some time to re-investigate the workflow. So here are two Textmate Actionscript commands that I whipped up based on that Monokai post. My goals were not to do project-level compiles, but instead incremental syntax checks with MTASC and simple single-swf compiles. These commands assume that you have MTASC and XTrace installed and working (see the Monokai post for more on both of those). Note that I placed the MTASC folder in /Users/domanistudios/opt/, which you can see from the variable declarations in the commands.

The first command calls MTASC with no output swf, and dumps the first error to an HTML ouput window (I believe mtasc only reports the first error it encounters during a compile). Using the built-in TextMate url functionality, clicking on the error will return you to the document you were editing, at the line where the error was encountered (so far haven’t figured out how to get it to go to the proper character, though). Note that you can also modify the actual line that does the compile to add/delete arguments (like -strict).

I’ve set it up this way:

Save: Current File
Input: None
Output: Show as HTML
Key Equivalent: Control-Command-M (scoped to source.actionscript)

[code]

FLASHPLAYER=SAFlashPlayer
MTASC=/Users/domanistudios/opt/mtasc/mtasc
CLASSES=/Users/domanistudios/Library/Application\ Support/Macromedia/Flash\ 8/en/Configuration/Classes/
SOURCE=”$TM_FILEPATH”
OUTPUT=test.swf
HEADER=550:400:40:ffffff
VERSION=7
TRACE=-trace\ com.mab.util.debug.trace
TMPFILE=/tmp/domanistudios.err

compileResult=$( $MTASC 2>&1 -cp “$CLASSES” -main “$SOURCE” -header $HEADER -wimp $TRACE -strict)
echo ”


if test -n “$compileResult”
then
errorLine=`echo $compileResult | sed ‘s/.*:\([0-9]*\):.*/\1/’`
echo “$compileResult“;
else
echo “”
fi

[/code]

The second one is essentially the same, except that it allows you to enter the name of the output swf you want to generate. As an added bonus you can add on any additional arguments not contained in your “base” compile command, so you could enter “tuto.swf” or “tuto.swf -strict”, for instance.

I’ve set it up this way:

Save: Current File
Input: None
Output: Show as HTML
Key Equivalent: Shift-Control-Command-M (scoped to source.actionscript)

[code]

FLASHPLAYER=SAFlashPlayer
MTASC=/Users/domanistudios/opt/mtasc/mtasc
CLASSES=/Users/domanistudios/Library/Application\ Support/Macromedia/Flash\ 8/en/Configuration/Classes/
SOURCE=”$TM_FILEPATH”
HEADER=550:400:40:ffffff
VERSION=7
TRACE=-trace\ com.mab.util.debug.trace

res=$(CocoaDialog inputbox --title “Output SWF Name” \
--informative-text “Please name your output swf:” \
--button1 “OK” --button2 “Cancel”)

[[ $(head -n1 <<<"$res") == "2" ]] && exit_discard OUTPUT=$(tail -n1 <<<"$res") #echo "You entered: $OUTPUT" compileResult=$( $MTASC 2>&1 -swf $OUTPUT -cp “$CLASSES” “$SOURCE” -wimp -keep $TRACE)

echo ”


if test -n “$compileResult”
then
errorLine=`echo $compileResult | sed ‘s/.*:\([0-9]*\):.*/\1/’`
echo “$compileResult“;
else
echo “”
osascript -e “tell application \”$FLASHPLAYER\” to quit”
open -a $FLASHPLAYER $OUTPUT
fi

[/code]

If there’s an error, it does the same thing as the first command -- displays the error which can be clicked to bring you back to the document. If no error is reported, it compiles the swf and opens it up in the standalone Flash player.

One issue with both commands is that if the error is in an imported class, clicking on the error will not take you to that class -- I suppose I could do more path-munging to get this to work, but for now I’ve just made a not of which class generated the error, and then I go to that class before resuming debugging.