Stop Coding!

The Unofficial Flex Compiler Blog

Flex Compiler SHell (fcsh)

with 5 comments

In early summer 2005, the Flex development team was busy working on Flex 2. The new Flex compiler redesign and implementation were finally gaining traction (well, you have no idea how frustrating it was when you had to build a new compiler that integrated with some unstable AS3 compiler pieces and had to run those resulting SWFs in an unstable VM). Anyhow, Dan Smith and I believed that it was the right time to discuss with the Flex Builder team about integrating the Flex compiler into FB2.

FB2 is an Eclipse-based IDE for Flex application development. Similar to other IDEs, FB2 should be able to compile Flex applications incrementally. Back then, the new compiler could barely generate good SWFs and the compiler’s full compile performance was not something we were proud of. But you know, things will get better over time, so I decided to switch focus and work a little bit on the incremental compilation support.

Now that the Flex compiler is open source, you should be able to trace how incremental compilation is done. But it might be difficult to identify the code that is responsible for incremental compilation – there is nothing like incrementalCompile() or something like that. One reason is that the compiler algorithms (API.batch1() and API.batch2()) are actually designed for incremental compilations. They treat full compilations as special cases, i.e. a full compilation is a case where everything needs to be recompiled.

Frankly, it wasn’t that hard to nail the basic incremental compilation support as long as you were dealing one unified algorithm for full vs. incremental. But FB at that point did not have any code in it that would invoke the compiler. Well, for testing, I had to write a tool (not just some test cases) to prove that incremental compilation worked.

To simulate how the compiler works in an IDE, what could be better than doing it in some sort of shell environment (Well, writing an Eclipse plugin as a simulator is straightforward too, but that’s not the point!). Yup, a shell. That’s what I built – Flex Compiler SHell (fcsh). Note that it’s SHell, not Shell. Some official Flex documentation are still using ‘Shell’ – I don’t like that. 😛

It took me a couple of days to get fcsh up and running. There are so many upsides using fcsh than mxmlc and/or compc. One of them is that you eliminate JVM startup time and those 2000+ compiler classes that JVM needs to load for even typical Flex applications. Those overhead could add up to 2 seconds. Another advantage is of course, what it’s built for – incremental compilation. I wasted no time dumping mxmlc and compc and used fcsh exclusively for my daily development work.

Soon after its availability, other folks on the team found good use of it. The QA and doc team dramatically cut their time for building their applications by using fcsh to batch-process their apps.

Due to the nature of my work, i.e. compiler development, I needed to be able to get to data that I couldn’t find in a SWF, e.g. dependency info, bytecode sizes, etc. For this reason, I added a slew of fcsh commands:

  • abc – outputs abc bytecodes given a definition name
  • dependency – displays a list of dependencies given a file name
  • files – lists all the source and SWC files that contribute to the resulting SWF
  • sizes – lists the bytecode size of all the definitions in the resulting SWF
  • lines – displays the number of ‘debuggable’ lines in the resulting SWF
  • memory – displays memory usage (when using JDK 1.5)
  • mm.cfg – displays settings in mm.cfg
  • trace – turns tracing on/off in mm.cfg
  • exportorder – displays the export order of the definitions in the resulting SWF

At first, product management and engineering management weren’t warm to the idea of adding a new tool to the SDK without getting requests from our customers. That’s why you don’t see fcsh in the Flex 2 SDK release.

But the Flex product management reversed their decision and shipped fcsh in Flex 2.0.1. That was great news. But the bad news was that the above-mentioned fcsh commands must be removed.

If you still have Flex SDK 2.0.1 installed, you can check out fcsh.jar. I think it points to flex2.tools.SimpleShell. If you change the manifest to point to flex2.tools.Shell, you will get the full version.

If you only have Flex SDK 3 installed, you’re out of luck because flex2.tools.Shell is no longer distributed. In my opinion, the Flex product/engineering management should consider adding the flex2.tools.Shell class back into the distribution.

Written by Clement Wong

April 20, 2008 at 1:33 am

Posted in fcsh, Technology

Tagged with , , , , ,

5 Responses

Subscribe to comments with RSS.

  1. […] 21, 2008 by Clement Wong In one of my previous posts, Flex Compiler SHell (fcsh), I mentioned that Flex removed the flex2.tools.Shell class from mxmlc.jar in version 3. For those […]

  2. Hi Clement,

    I’ve been trying to use fcsh version 3.0.0 build 477 but without success… now I guess I know why…. I’ve been trying to use it with our Flex 3.0 project.

    So am I right in thinking that fcsh currently doesn’t work at all with Flex 3.0?

    If so, what alternative do we have?

    We currently have an Ant script that builds our projects, and that spends most of its time reloading the JVM just to run mxmlc and compc. We need something like fcsh to run with Flex 3.0.

    Is there an intention to make fcsh run with Flex 3.0 in future?

    Thanks,

    Ed.

    Ed Syrett

    July 8, 2008 at 4:30 am

  3. Admittedly I have only scanned this long blog posting from someone who is far more knowledgeable than I am, so take that into account.

    I am looking at this page because I am starting to use amxmlc more than mxmlc — yes I know I could just type in the configname. So, after submitting an enhancement request, I started looking to see how hard it would be to fix it myself. I have not yet done that, but I just want to report that I have been happily using fcsh with FlexSDK3.x for more than 6 months — it works fine and saves me hours per day.

    Terry Corbet

    September 27, 2008 at 4:51 pm

  4. So, in for a dime, in for a dollar.

    I decided to see if I could find the source code, since this is now an Open Source project. I did, but then wasted several hours trying to figure out what to do with the code and ant targets that I downloaded. [Note to Self–Idiot, never check code out from the trunk. They are well on their way to refactoring for Flex4, and that creates a rather different environment concerning SimpleShell, now renamed Fcsh.]

    When I managed to check out the sources for 3.1.x, the build process worked better for me. So, in addition to confirming that fcsh works just fine with the latest release, I would be happy to pass along to anyone who would find it useful, some changes to make it easier to work with AIR.

    01. I added a command that you enter like this:

    ax SomeAIR.mxml

    and it fixes the command line to emit this:

    mxmcl +configname=air SomeAIR.mxml

    No, it’s not rocket science, I never said it was — but it saves you keystrokes.

    02. I added a command that you enter like this:

    adl SomeAIRApplication

    and it fixes the command line to emit this:

    adl SomeAIRApplication-app.xml

    Same comment as above, but in this case, as I am sure you have imagined, the command line it turned over to the Java RunTime. So now you don’t have to keep a second command line window open just to test what you have just compiled.

    Maybe all the rich guys at Adobe have three monitors and don’t care about screen real estate but any of us who are still using vi and mxmlc have to get by with a lot less.

    Terry Corbet

    September 28, 2008 at 2:19 am

  5. Terry,

    I’m very interested to hear that you got FCSH working with the 3.1 SDK.

    When I tried to get FCSH working with the 3.0 SDK, I got errors saying that FCSH couldn’t find flex2.tools.Shell. I hunted around the web and found this very page that says:

    “If you only have Flex SDK 3 installed, you’re out of luck because flex2.tools.Shell is no longer distributed.”

    So I guess he and I agree that FCSH shouldn’t work with SDK 3.0.

    So how have you got it to work?

    Thanks

    Ed.

    Ed Syrett

    October 6, 2008 at 7:23 am


Leave a reply to Ed Syrett Cancel reply