Automata Studios has worked closely with engineers over at Adobe for the past few months testing Alchemy and preparing some public samples. We were very happy to help present the public release at the day 2 keynote of Adobe MAX 2008 earlier this week. You can also see some video of me talking about our work porting Ogg Vorbis using Alchemy on Adobe Labs.

There is currently quite a bit of confusion about Alchemy and this article is a quick attempt to answer the most common questions about the technology. First, let’s look at what Alchemy really is and what it is doing.

One of the main pieces of Alchemy is a new backend to the LLVM compiler infrastructure. LLVM is short for Low Level Virtual Machine. The big idea behind LLVM is that the core LLVM compiler will take code in many different languages and compile it into simple RISC-like instructions that are platform neutral. Then, anyone can write a backend to LLVM that can take LLVMs simple instructions and turn them into actual executables for a given platform. Platforms include x64, ARM, PowerPC, and now ActionScript.

You may notice how much ActionScript stands out in that list. All of the rest of the members are CPUs - not programming languages. In fact, if you manage to stop Alchemy mid-compile (when it has created the ActionScript, but not yet compiled it into a SWF) and look at the ActionScript that it creates it will look like some odd hybrid of ActionScript 3 and assembly language. In fact you’ll even see sections that looks suspiciously like inline assembler. This is because the ActionScript compiler that ships with Alchemy does in fact allow for inline AVM2 byte codes.

Essentially when you compile some C or C++ code with Alchemy the end result is a class that is basically a virtual machine written in ActionScript and AVM2 bytecode. This is also why Alchemy generated SWCs are on the large side - they include everything that C or C++ may need such as the C standard library and POSIX support. For example the stringcho example that ships with Alchemy takes 54 lines of C and spits out 27415 lines of ActionScript. This is also why Alchemy can do things like its built-in “green threads” that let’s you run synchronous C asynchronously inside of the Flash Player.

In addition to the LLVM backend, Alchemy includes a set of scripts that are drop-in replacements for standard development tools like make and autoconf. This allows you to use the standard UNIX-style tool chain to create SWFs and SWCs (and thus easily recompile most existing source with Alchemy). The alc-on and alc-off scripts that ship with Alchemy are in fact swapping the standard tools for the Alchemy tools and vice versa.

The output you get from Alchemy is generally a SWC (you can get just a SWF if you want, but usually it won’t be terribly useful on its own). SWCs created from Alchemy can be used in Flex 3 (as long as the build can target FP10), Flex 4 (”Gumbo” - in public preview) and Flash CS4. While I believe there are some switches to make Alchemy compiled code target Flash Player 9, this should be avoided as there were specific changes made to Flash Player 10 that greatly increase runtime speed.

As you may have guessed by now, once C and C++ code is compiled with Alchemy into a SWF it is subject to all of the rules and limitations of a normal SWF. That means you’re still in the security sandbox, all visual output goes through the display list, and all network and file access goes through the existing classes. Under the surface, when you instantiate your Alchemy compiled library, the code is allocating a nice chunk of memory into a ByteArray. This is how Alchemy takes pointers, malloc, free, etc and makes those concepts work in ActionScript.

Knowing that Alchemy is just spitting out the same AVM2 bytecode that Flash and Flex spit out it is pretty confusing how Alchemy code could be faster than standard ActionScript. In fact, it is not faster across the board - just in specific types of operations and when the length of a task can be used to overcome Alchemy’s intrinsic overhead. Now, that’s not to say that Alchemy compiled code is slouchy by default. In fact, because LLVM does a lot of optimizations, whereas Flash and Flex have no optimization step built into their compilers, Alchemy code manages to overcome a lot of it is overhead just on its own.

Now, what are these operations that Alchemy does so well? Memory access and function calls. Alchemy compiled code utilizes new bytecodes added to FP10 for working with ByteArrays - which as you’ll remember are what make up the “RAM” in Alchemy. Function calls are faster because in ActionScript function calls require that their parameters be “boxed” and “unboxed” into and out of objects for each call. Alchemy code doesn’t have to do this.

All of this speediness can be undone though by jumping back and forth between Alchemy code and regular ActionScript. This process is called marshaling and you’ll want to keep it to a minimum. Marshaling is expensive so you’ll want to try to create calls that stay in the C code as long as possible. You’ll also want to try to limit the number of parameters you’re passing back and forth (it’s actually best to work directly with Alchemy’s “RAM” if possible).

As you can see, Alchemy is very powerful, but it is not some magic bullet. More than anything else Alchemy has the potential to drastically speed up the process of bringing existing C/C++ code to the Flash Platform - something that had to be done line-by-line by hand previously. If the ActionScript wrapper around an Alchemy compiled library is well written to take advantage of Alchemy’s strengths it is even possible to get significant speed improvements (up to an order of magnitude or so) over hand-written ActionScript.

That’s it for now, but I plan on writing more about compiling with Alchemy, using GlueGen (a special language you can use with Alchemy to somewhat automate the task of writing C-to-ActionScript glue code), and utlizing Alchemy-compiled libraries within Flash and Flex.

Finally, let me just give a public “THANK YOU!” and “OMFG U RULEZ!” to Scott Petersen(the father of alchemy), Joe Steele, and all of the other employees at Adobe that made Alchemy happen - it’s simply an awesome tool!

Then I started to think about a weird edge case… what if the creators of these SWFs accidentally does something spectacularly bad like get stuck in an infinite loop? I had a few ideas for a solution, and so I decided to spike them and see if any of them worked (The link explains what spiking is - but in a nutshell it’s a quick-and-dirty end-to-end solution that tests out an idea).

To test my solutions I made two SWFs - one with a simple spinning animation (spinner.swf) and another that, with the push of a button, would lock up for 5 seconds (greedy.swf). My first idea was to put the SWFs on the same HTML page and have them talk via LocalConnection. The spinner would monitor the greedy SWF (when ever the greedy one started, it would tell the spinner) and if the greedy SWF went on too long the spinner would talk back out to Javascript and tell it to replace the Flash Player instance.

That didn’t work in the slightest.

As soon as the greedy SWF started getting greedy, the spinner would lock up too. I even tried putting the SWFs in separate HTML files and loading in one via an iframe - same result.

The next solution was to have Javascript do the monitoring. So now the greedy SWF would call out to Javascript before it started getting greedy and the Javascript would then start a timer. If that timer wasn’t reset by the greedy SWF finishing it would unload the Flash Player running the greedy SWF. Pretty decent idea, yeah? Nope.

It seems like (at least in the browsers I tested, Safari and Firefox), when Flash is locked up the rest of the browser, including JS is locked up too. The timer would only first AFTER the greedy SWF stopped on it’s own accord.

So where does that bring us? Well, these solutions or something like that may work in IE, particularly since it’s running on a whole different plugin architecture. It may also work in Chrome since it’s whole architecture is based on isolating processes. That being said, a real cross-browser solution remains elusive. I guess I’ll just have to hope the 3rd party SWFs don’t suck and maybe do a bit of testing on them before I roll them out to the public.

It didn’t take us long to remember that SOAP was just XML, and that Flex’s web service API was just a nice class that makes it easy to speak that language.  After deciding to nix the Flex solution (we were only using Flex for the WebService API), we moved to an all Flash solution.  We created a connector class to act as a web service API, and simply sent XML packets directly to the server using URLLoader.  One note about this solution is that it will only work if you have knowledge of the web service you are trying to use.  In our case, we had the entire schema at our disposal, so we knew the exact format of the service operations.

The connector class contains public methods to call the individual web service operations.  Additionally, we created individual request classes for each of the operations that extended a class called Abstract Request.  AbstractRequest provides a method send(uri:String, headers:Array) that uses URLLoader to send the request to the server.

The “uri” parameter of send() is the full path to the web service, with the “http://” attached.  The headers are the HTTP headers that you need to send to the web service for such things as authentication.  In our code, these are set in the Connector class, and passed to each request as it is needed.  The “_request” property holds the XML object that you will pass to the server.  This XML is formatted as an XML packet specific for this web service.  The value for this property is defined in the AbstractRequest sub-classes.

The _request property is an XML object that defines the format, and uses Flex-style binding to add the actual data from the constructor parameters.  This is a little-known XML trick you can do in AS3.  Branden found it in the Help section of the Flash CS3 IDE.  Pretty neat if you ask me.

Back to the AbstractRequest class, we simply set the data property of the URLRequest intstance to be the string representaton of the request XML, and call URLLoader.load(), passing in the URLRequest instance.  This sends the XML packet to the server.  The handler for Event.COMPLETE will receive the XML returned from the server.

Our connector class has methods like:

1
2
3
4
5
6

public function addGroup(groupId:String, groupName:String, flag:String):void {
	var request:AddGroupRequest = new AddGroupRequest(groupId, groupName, flag);
	request.addEventListener(ISYResultEvent.EVENT, onResult);
	request.addEventListener(ISYFaultEvent.EVENT, onFault);
	request.send(_uri, _headers);
}

This actually executes the web service call.

And just like that, you’ve build your own web service class.  While it’s quite specific to the web service you are using, you could certainly expand it to consume a WSDL file so you can use it for any web service.

This is my first foray back into world of hardcore IT after spending three years working in higher education for a local university.  Prior to that I worked for a colocation facility, hence the homecoming for me.  I’m especially excited to be at a place where interesting ideas are valued over maintaining the status quo.

Branden and Keenan do simply amazing work here, and I have learned something new each day I’ve been here for the last two weeks.  I am looking forward to contributing all I can to Automata.

Oh, and now that I’m here, this site is going to be updated more frequently.

Now, on to the actual topic of this post - finite state machines. What is a finite state machine you ask? Well it’s just a construct that lets you track the states within a piece of code and ensure that you only do what you’re allowed to do when you’re allowed to do it.

A while back I wrote a generic finite state machine (I called it PastaMachine - since every time I wrote FSM I thought of the Flying Spaghetti Monster). It is exceptionally generic - you just define states, define the allowed transitions between those states (state A can go to state B, but B can’t go back to A, etc) and the actions that each state may take (an action may trigger a transition, but it doesn’t have to). The states themselves can have attached to them an arbitrary amount of metadata and in less than 340 lines of code you have a simple finite state machine.

What can you do with it? Well, originally it was written to handle a branching logic game where depending on the users success at a simple game they went down multiple paths and were shown various different videos (yeah… it was a PG-13 strip poker game). But recently Keenan has been using PastaMachine to track the logic of an application to assist doctors in treating patients with HPV. If that’s not a nice range of usefulness, I don’t know what is!

One nice extra trick PastaMachine has up it’s sleeve is that once you’ve defined a state machine with it you can export the information about that state machine to data in DOT format. That DOT data can be loaded into the ever-so-awesome GraphViz and BAM! you have a directed graph diagram of your state machine! It’s actually really useful in debugging the state machine’s connections, but beyond that it adds a very nice “WOW!” factor when you present it to your client.

Over the next few weeks we’ll be cleaning up PastaMachine and sharing it with everyone. Then, if everything goes smoothly, there will be a number of other Automata code libraries following along behind it.

Luckily early in this process we discovered a piece of shareware called Charles, a web debugging proxy that’s available for Mac, PC, and Linux. Once you fire Charles up it acts as a proxy for all of your web traffic. This lets you capture, view, and even throttle the data that’s flowing between your machine and the web server. And best of all for us, it lets you view inside of AMF packets and see exactly what’s coming over the wire. Once we got Charles up and working we able to tackle kind of issues that used to take us hours and resolve them in minutes.

We haven’t done a done with Charles yet, but so far our only wish is that we knew about it sooner. Suffice it to say that we found the $50 registration fee to be well worth it!

You are creating tweens using the Tween class in AS3. These tweens are inside of a method (or a loop). The tweens appear to work fine, except, they stop in the middle without explanation. As it turns out, I had run into this problem before. While working on a previous project, I had a series of tweens moving around a Rectangle object inside a class method. Halfway through the tween, it stopped for no apparent reason. After using everyone’s favorite inter-web fast-food chain, Google, I determined that the issue must be due to garbage collection. I typed in “AS3 tween garbage collection”, and found that my problem had been solved and discussed by Scott Morgan. Here’s his blog post about it.

The solution, as described by Scott is to create class properties for your tweens instead of local variables. As I described this to Branden, he noted a potential problem with this solution. When you use class properties, the Flash player will allocate space for those properties, even when you are not using them. Why is this a problem? Well, imagine you can potentially have hundreds of instances of a class, where each instance contains private properties for 5 tweens. This could significantly hurt the performance of your application since you will have allocated space for all of those tweens, even though the tweens are not running. Needless to say, while this is a good solution, and great in a pinch, ultimately, you will have problems for large numbers of tweens.

So, how do you solve the secondary problem of allocating space for tweens that are not running? Is there a way to use a class property to store the tween (so it is not killed by the garbage collector), without actually allocating space until the tween is needed?

The answer: DICTIONARY!

Instead of creating a property for each tween you use, instead, create a single property of type flash.utils.Dictionary. The Dictionary class allows you to create a set of dynamic properties, without allocating the space for them until the property is actually created. Additionally, you can also use an object reference as a key in a dictionary, which can be a very powerful tool. Once you have your dictionary, inside the method (or loop) that creates the tweens, store the tween object reference as the key in the dictionary. Once your tween is complete, delete the key and your tween will be collected by the garbage collector.

Here’s an example:

• Source Code

(Thanks to Tom Pizer over at Performtech who dug up the video)

If you haven’t played with Quicklook, you just select a file and hit the spacebar - you then get a preview of the contents of the file. By default it works with iWork formats, and all the usual MS Office formats. The best part though is that third parties can write their own plugins for Quicklook - and developers have already made some for ZIP and EPS! Now I just select either file type and smack the spacebar and BAM! almost immediately I can peer inside of ZIP files or preview EPS files.

It’s times like these I *really* love the Mac developer community (and Apple ain’t half bad either, though I’m still not fully digging Stacks!).

• ZIP Quicklook Plugin
• EPS Quicklook Plugin

]]> http://www.automatastudios.com/2007/11/27/making-leopards-quicklook-feature-more-useful/feed/ http://www.automatastudios.com/2007/11/17/the-nooks-and-crannies-of-actionscript-3/ http://www.automatastudios.com/2007/11/17/the-nooks-and-crannies-of-actionscript-3/#comments Sat, 17 Nov 2007 22:21:40 +0000 Branden http://www.automatastudios.com/2007/11/17/the-nooks-and-crannies-of-actionscript-3/ The slides from Branden’s presentation at FITC Hollywood 2007, Flash on the Beach 2007, and FITC Winnipeg 2007 - “The Nooks and Crannies of ActionScript 3″ are now available for download. Enjoy - and if you have any questions or comments drop us a line.

• The Nooks and Crannies of ActionScript 3

]]> http://www.automatastudios.com/2007/11/17/the-nooks-and-crannies-of-actionscript-3/feed/