I know it would be better to have it as an Eclipse Plug-in with nice little markers etc. but for that I need some more extension points in FDT. I do not know about FlexBuilder but it would be probably the same.

The file includes an example build and some test cases that show you how AS3V can detect common errors and mistakes. There is currently not that much documentation available for the rules and parameters you can specify. Putting a list online with all rules and nice descriptions is of course something I would like to do but currently the time for that is missing. I hope everything is self-explaining if you have a look at the readme and example files.

• Download AS3V

Update: The AS3V package has been updated with one bug fix and some modifications so that AS3V will produce a more interesting log output if it fails for some reason. Using AS3V with Eclipse works only if you specify fork="true" like in the Flex SDK example from the build file that comes with the zip.

You can see in the screenshot that AS3V places markers in your Eclipse code. It works as an incremental project builder which means it is pretty fast since it only evaluates all your sources that have changed independently. If you have any suggestions for possible rules, please tell me. The Flex SDK coding conventions could be interesting for instance. Right now the Eclipse plug-in has still some problems but I think that a first version might be released in the next few weeks.

This is the reason why I started writing a parser manually from scratch. But this is also not a good idea. What about Adobe changing the language or adding features? I would have to change my parser. This is for instance a problem you have with FDT. Adobe releases a feature and it will take a while until you can adopt that. Maybe that feature is only beta but you want to use it. So are you going to implement it or not? Since the Flex SDK is open source I decided to take a completly different approach. Option one is to modify the original ASC. I think this is a bad idea. On every update from the Adobe guys you would have to patch the compiler again, and release a compiled version of that. This is what flexcover does. But I do not want to replace core parts of the Flex SDK with a modified compiler. So this is the reason why AS3V links only against the ASC. This means basically I do not care about what Adobe does with the compiler as long as the API stays consistent. This means also AS3V knows only as much as the ASC. This is sometimes a problem but in most cases not so important. ASC drops for instance braces every time. AS3V does not know if you write if(true) trace('foo'); or if(true) { trace('foo'); }. But in the end AS3V is able to analyze the real compiler output which is huge; theoretically every implicit cast can be watched!

Now enough theory. Why bother using AS3V and what is it good for? Imagine a loop like this:

for( var y: int = 0; y < height; ++y )
  for( var x: int = 0; x < width; ++x )
    index = y * width + x;

AS3V is currently smart enough to analyze the statement y * width + x and to figure out that y and width do not change in the inner loop. AS3V is therefore able to warn you about unneccessary calculations. There are lot of other rules I have already implemented which help you writing better code. For instance the pattern if( expr0 ) { if( expr1 ) { foo(); } } can be reduced to if( expr0 && expr1 ) { foo(); }.

There is a lot of room for other rules. I am happy to see some progress and hope that other people will find AS3V as useful as I. In the current state I have to implement more rules and a little bit more complex ones like dead code detection with constant folding. A release is targeted once I am happy with the rule set.

Not to forget: An Eclipse plugin which will show you appropriate warnings as neat little icons is of course also planned.

Unfortunately I have not figured out yet how I could abort the launch process if mxmlc fails for instance. This is due to the fact that the fcsh process is persistent and does not return for instance a non-zero exit code when mxmlc reported an error. However, the MetaLaunch plug-in can help you in a lot of cases. For instance if you are developing a multi-client application and you want to launch every time four instances of the Flash Player etc.

The address of the Eclipse update site:

I do not know if all settings are completly correct but after trying lots of different configurations this seems the be the best for me. You can find those settings in the eclipse.ini which is located in your Eclipse installation directory.


-vm PATH_TO_JROCKIT_INSTALLATION\bin\javaw.exe
-vmargs
-Xms1024M
-Xmx1024M
-XX:PermSize=256M
-XX:MaxPermSize=512M
-XX:+UseParallelGC


So here it is: The FlashHunter Deluxe. Just for you Michael :)

• Download

FlashHunter is a neat Eclipse plug-in I wrote that allows you to kill all running Flash player instances with a single click. Two days ago I was implementing the fast Fourier transformation in Flash and I had a stupid error that caused an endless loop. Since I am testing with the standalone player the only way to get rid of it was Ctrl+Alt+Del and killing it. This is not really a nice workflow so I wrote the plug-in.

I am not a Java developer and definitly not an Eclpise platform developer so the plugin itself is very basic. I experimented a little bit with JNI and wrote most of the plugin in C++ because it still is my language of choice.

The plugin is Windows only. I think you could also do something like that as an external tool for OS X (“killall Flash\ Player”).

• Download FlashHunter