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.