Glider
"In het verleden behaalde resultaten bieden geen garanties voor de toekomst"
About this blog

These are the ramblings of Matthijs Kooijman, concerning the software he hacks on, hobbies he has and occasionally his personal life.

Most content on this site is licensed under the WTFPL, version 2 (details).

Questions? Praise? Blame? Feel free to contact me.

My old blog (pre-2006) is also still available.

See also my Mastodon page.

Sun Mon Tue Wed Thu Fri Sat
       
28  
Powered by Blosxom &Perl onion
(With plugins: config, extensionless, hide, tagging, Markdown, macros, breadcrumbs, calendar, directorybrowse, feedback, flavourdir, include, interpolate_fancy, listplugins, menu, pagetype, preview, seemore, storynum, storytitle, writeback_recent, moreentries)
Valid XHTML 1.0 Strict & CSS
Using fcsh as a drop-in replacement for mxmlc

Adobe Flash

I've recently been hacking a bit with Flash (or rather, with Adobe's Flex compiler. This is a freely available commandline compiler, which actually works on Linux as well.

However, out of the box the commandline compiler, mxmlc, is obnoxiously slow. It takes nearly 10 seconds to compile a simple Hello, world! example, and compiling the video player I'm working on takes over 30 seconds. Not quite productive.

This is a documented "flaw" in the mxmlc compiler, caused by the fact that it has to start up a big java program everytime, loading thousands of classes and because it always recompiles the entire source.

The official solution to get faster compile times is to use the Flex Compiler Shell (fcsh), which is included with the Flex SDK. Basically, it's a caching version of the mxmlc compiler, that keeps running in the background and caches compiled files.

fcsh is intended to be used by IDEs. The IDE starts fcsh and then communicates with it through its stdin/stdout. This means fcsh is really a simple thing, without any support for listing on sockets or properly daemonizing.

Using fcsh speeds up the build time from nearly 40 seconds to just a few seconds (depending on how many changes were made). The first compilation run is still slow, of course.

I've been trying to use fcsh with the ant build system, which makes things a bit tricky. Since there is no long-running process (like an IDE) which can keep fcsh running, this needs some way for fcsh to be run in the background, connected to some fifo or network socket so we can start it on the first compilation run and then connect to it in subsequent compilation runs.

A quick google shows that there are already a few fcsh wrappers to do this, some of which intended to work with ant as well. At a quick glance, it seems that the flex-shell-script-daemonizer seems the most useful one. It is created in Java and runs as a daemon (unlike the alternatives I saw, which were Windows-only due to some useless GUI). It has two modes: In server mode it starts fcsh and connects it to a TCP network socket and in client mode it takes a command to run and passes it over the netowrk to the running server.

There is also some stuff to integrate make ant use fcsh for compiling actionscript files. However, this requires changing the build methods and stuff in build.xml, which I don't want to do (I'm trying to minimize my changes to the sources, since I'm modifiying someone else's project).

So, I created a small shell script that can be used as a drop in replacement for mxmlc. It simply takes joins together all its arguments to a single command and passes that to the flex-shell-script-daemonize command. If the fcsh daemon is not yet running, it automatically starts it (and does some half-baked daemonization, since neither fcsh nor flex-shell-script-daemonizer does that...)

While writing the script, I also found out that the fcsh "shell", doesn't have any way to quote spaces in arguments in the command (at least, I couldn't find any and there was no documentation about it). This means that, AFAICS, there is no way to support spaces in paths. How braindead is that... I guess FlexBuilder, the official IDE from Adobe doesn't use fcsh after all and instead just includes the compiler classes directly...

Of course, just as I finished the script, I encountered flexcompile, which basically does the same thing (and includes the network features of flex-shell-script-daemonizer as well). It's written in python. However, it does require the path to flex and the mxmlc part of the path to be passed in as arguments, so it's not a 100% drop-in replacement (which I needed due to the way the build system I was using was defined). Perhaps it might be useful to you.

Anyway, here's my script. Point the JAR variable at the jar generated by flex-shell-script-daemonizer and FCSH to the fcsh binary included with the Flex SDK.

#!/bin/sh

# (Another) wrapper around FlexShellScript.jar to provide a mxmlc-like
# interface (so we can just replace the call to mxmlc with this script).

# For this, we'll have to call FlexShellScript.jar with the "client"
# argument, and then the entire mxmlc command as a single argument
# (whereas we will be called with a bunch of separate arguments)

JAR=/home/matthijs/docs/src/upstream/fcsh-daemonizer/FlexShellScript.jar
FCSH=/usr/local/flex/bin/fcsh
PORT=53000

# Check if fcsh is running
if ! nc -z localhost "$PORT"; then
    echo "fcsh not running, trying to start..."
    # fcsh not running yet? Start it (and do some poor-man's
    # daemonizing, since the jar doesn't do that..)
    java -jar "$JAR" server "$FCSH" "$PORT" > /dev/null 2> /dev/null <
/dev/null &

    # Wait for the server to have started
    while ! nc -z localhost "$PORT"; do
    echo "Waiting for fcsh to start..."
    sleep 1
    done
fi

# Run the client. Note that this does no quoting of parameters, since I
# can't find any documentation that fcsh actually supports that. Seems
# like spaces in path just won't work...
# We use $* instead of $@ for building the command, since that will
# expand to a single word, instead of multiple words.
java -jar "$JAR" client "mxmlc $*" "$PORT"
 
0 comments -:- permalink -:- 00:25
Copyright by Matthijs Kooijman - most content WTFPL