Deitte.com

I went to the first Boston Flex User Group meeting last Tuesday, and I took some notes through Pete Farland's presentation. This is more of a ramble on the compiler than on the presentation (similar to my previous post on the compiler), although there's a few pieces from the talk below. You can find the PDF for Pete's presentation on his blog. If you want to understand some of comments about the compiler source, you should grab the SDK source from opensource.adobe.com.

The general talk about the compiler made my mind wander on to SWCs. The SWC format is centered around catalog.xml, a file you can find inside of the zip file which is known as a SWC. Using any normal unzipping tool, you can check out catalog.xml and see the components (what the MXML compiler looks for), classes (for the AS compiler), assets (used by Flex Builder mostly) and features (used by no one). All of this is processed within the flex2.compiler.swc package in the compiler source. The entry-point, flex2.tools.Compc, corresponds to compc. As an amusing aside, compc was supposed to be a placeholder name, something temporary that I submitted until a real name was chosen. So much for temporary, eh?

ASDoc was briefly talked about, and while looking at the ASDoc Java source will only given you heartburn, there's some other interesting asdoc files to feast upon. The asdoc directory contains a huge number of stylesheets and HTML files which I've never really understood myself. But they're all there for a purpose, and you can play around with these files to completely change the look of your documentation. You don't need to check the source to do this, since it's a directory in the regular SDK as well: asdoc/templates.

Pete turns off "Build Automatically", and it's always interesting to hear who keeps this turned on or off. (I turn it off.)

There was a question about native code in the Java code. There's no native code in the Flex compiler, but there is Adobe code that isn't released as open source within jar files. I know there's some font code in there, and probably other pieces as well.

Data binding does a lot under the covers and produces a sizable chuck of extra code. Joe Berkovitz has written about some potential improvements to this on the compiler mailing list.

Pete showed a little-known trick for debugging bindings.

As the discussion went on to classes getting linked in, I wondered about something that I had a discussion about last week, which is whether there is a way to rip out methods within the AS compiler. Given the node transversal in Evalutators within the compiler, it doesn't seem like it'd be too difficult to simply have specific FunctionNodes ignored. I haven't asked any of the AS compiler folks about this, though, and I have a feeling it's not really that simple. But if you could rip out the right methods, then you more-easily remove parts of the framework you know you don't use in a better way than monkey-patching. Or you could take a stab at what isn't used by using a code coverage tool and unit tests to remove methods.

Pete mentioned that turning off optimize is a way to speed up the compiler. You can do this by setting optimize=false, but I didn't noticed any real difference in the current project I'm working on. It would make sense to me that this would speed up compiles, but I just don't see much of an effect. The optimization code, for those curious, is in flex2.tools.Encoder (for merging ABC blocks) and macromedia.abc.Encoder (for ActionScript peephole optimization).

Pete went over a lot of other things that what I rambled on within this post, but that's it for my notes. After the presentation, I saw Joe Berkovitz talk with Paul Reilly about the profiler and show a preview of his fantastic code coverage tool.

The next update to Java 6 is going to include a 4 MB-ish installer for the core pieces, a JavaScript deployment toolkit, and a bunch of other improvements for Java applets and Web Start programs

It also comes with a new Swing theme with a baffling choice of scrollbars (in the second image in the link). Perhaps it looks good to everyone but me, perhaps I've been around good Flash designers for too long, or perhaps Java still can't figure out GUI development.

The overall update looks very intriguing, and it'll be interesting to see if the focus stays on the client side for Java. If the work continues, Java could end up being more useful than Silverlight to a lot of developers. But not as useful as Flex, of course!

Here's a grab-bag of links, with the first one being the most well-known on the Flex blogs. I still wanted to link to Joe Berkovitz's post on code coverage in AS3, because I'm excited to see this getting done (and someone making some interesting changes to the compiler). But I don't have much to add to the discussion. Go read Joe's blog for all the good details.

A new draft of ECMAScript 4 is out, and the mailing list is getting filled with interesting posts on the final proposals. Check out Insurrection, a thread which contains a thoughtful critique of ECMAScript 4.

I don't see anything interesting happening yet in the commit logs for Flex, but they're fun to watch again.

Nearly as much fun as the commit logs is seeing random new developments in all corners of the Flex world. I don't keep up with a good fraction of the blog posts on Flex anymore, so I'm sure I'm missing a lot of things like an Emacs mode for Flex.

The Boston Flex User Group starts a week from Tuesday at the Adobe office in Newton. Find out more at the it's-just-missing-drop-shadows homepage.

There's already a lot of other groups that touch on Flex already- Boston Flash Platform User Group, Boston Design Patterns Group, Adobe Boston User Group, Flex App Incubator Group, and Boston ColdFusion Group. Until I typed them out, I had forgotten how many groups there are. But it'll be excellent to have one that's just focused on Flex, and I know there'll be a better chance for a lot of people to talk with the Flex team, given the location.

I'll miss seeing you peck at the car tires in Kendall Square.

(Sure, I could be writing something about the Flex compiler, or the recent YouTube changes, or other useful things. But it's just Mr. Gobbles today.)

When the Flex compiler was open sourced, I wanted to get my hands dirty and make a change or two myself. In the first week I dug into the source and looked to make a change to decompile (or rather disassemble) AS3. Of course, after I'd dug into things I realized that Adobe has already done this. And someone created an AIR app. And a commercial decompiler. This is what I get when I don't keep up with my blog reading.

While I didn't end up making any changes, I'm going to give a partial explanation of this code.

The entry-point for the AS3 disassembler is flash.swf.tools.SwfxPrinter. If you take a look at this class, you'll see a method for each tag that needs to be handled, with each method taking in a Tag class. These correspond to the different tags in the SWF format. The one that is of interest for AS3 decompiling is DoABC. (To be pedantic, we actually use the DoABC2 version of this tag, which is a bit confusing, but the original DoABC tag was never released.) This is the tag which contains ABC, the compiled AS3 that the Flash Player runs. Going back to SwfxPrinter, you'll see the DoABC method takes this bytecode and through the magic of AbcPrinter prints out all the operations.

I assumed that the SwfxPrinter would work by parsing Nodes and not directly work from the ABC. As explained above, the ABC is what's actually in the SWF, and it's contained within a DoABC tag. The Nodes are an abstraction of the bytecode that the AS3 compiler uses. It's what is generated within the compiler when you first compile an application, but there's also a way to get Nodes from a finished compilation. You can see this in action within the SwfxPrinter.doABC() tag. Within the showActions code, you can see how the ABC is turned into the top-level Node, a ProgramNode, which then can be printed out via the PrettyPrinter. I tried enabling this code myself, and it doesn't work very well. There's a lot of missing pieces to the output, so apparently everyone should keep using the existing path of parsing the ABC bytecode for printing.

That's a little more insight into the class used for AS3 disassembling, but it doesn't even touch the real work in decoding the ABC format, TagHandlers, etc. There's always plenty more to learn in the compiler, and hopefully I'll be able to blog more in the future about the parts that I know.

We were talking about the compiler and ideas for improvements at the last Boston Flash Design Patterns Group, where we stopped talking about design patterns for a week and instead talked about the Flex compiler and the need for more comments. People wanted to know the easiest places to make some changes, and I couldn't come up with much. There's some jumping-off points in flex2.tools.Compiler or flex2.tools.Compc. Changing a Transcoder could be interesting, or adding one to the list in flex2.tools.API.getTranscoders(). If you'd like to try something for fun, you could always alter Grammar.jj to change the core of MXML. Daniel Rinehart is looking at making a change to the compiler, and it's going to be interesting to see all the changes coming in from around the community.

Update: See Random Compiler Thoughts, Part II for more info on the compiler.

I've been looking again at Ted's post on Extending Adobe Flash Player and Adobe AIR with C and C++ via ActionScript 3 as well as the video on Quake on the Flash player. I had a long post written, giving my guesses on what's happening. And then I did one last search and realized I missed a great interview by Ryan Stewart, where most of my postulations have real answers. So nevermind.

It doesn't have the Golden Girls like the Flex behind the scenes videos, but Boston.com came by the Brightcove office a few weeks ago for a video about development hell and Paris Hilton.

In other Brightcove news, check out a new use of Aftermix, with pages to create and view mashups on snow.com. It's the first off-site use of the application.

I haven't been working on Aftermix lately, but there's a lot of other interesting Flex work going on here... just nothing I can blog about yet.