Debugging cross-compiled ActionScript

This could be a short post: Just don’t introduce any bugs to your code, then you won’t ever have to debug. Clearly, that’s easier said than done. But seriously, how do bugs come into this world? I might address this philosophical question in a different post if there is any interest. Today I will assume that developers are not perfect beings and occasionally make mistakes, which don’t get caught by the tools they use. That’s why they have to debug their code. So how do you debug cross-compiled ActionScript?

 

Optimized versus Unoptimized Code

This might be obvious, but if you can, try to debug your unoptimized code. If your bug only occurs in the optimized version use Closure compiler’s -formatting=PRETTY_PRINT option, which generates somewhat readable optimized code. If that doesn’t help, use Closure’s -create-source-map option and their Closure Compiler Inspector. In very rare cases all of those methods don’t work and all that’s left is “printf-debugging”, which translates to “console.info-debugging” in the browser world.

 

Debugging with the Browser

At this point I always debug my cross-compiled ActionScript directly in the browser, mostly Safari on OSX. Sometimes I switch browsers depending on the task at hand.

In these days every modern browser comes with a built-in debugger that allows source-level debugging and an interactive console. I have noticed that Safari and Chrome both have difficulties when you jump out of the last expression in a function (tail calls). The debugger seems to get confused and does not stop at that last expression and jumps out to the parent scope. Microsoft’s IE10 does not have that problem. If you have to debug, i.e.  jQuery’s library code you might want to switch to IE10. It will probably save you a lot of time.

 

Debugging with Flash Builder

In a previous post about my “dreamed up” Flex SDK for JavaScript I proposed that everything should be transparent, even Flash Builder’s source-level debugging of ActionScript running as JavaScript in the browser should just work. JavaScript and HTML would just be features delivered through a specialized Flex SDK.

Now, this is also easier said than done. But it can definitely be implemented and I tell you how in a second. I just find it hard to justify adding source-level debugging of cross-compiled JavaScript to Flash Builder while existent browsers already offer excellent debug tools.

So here would be my rough idea how you could implement source-level debugging for Flash Builder…

 

FDB

Not many of you might know that every Flex SDK comes with a command line debugger called FDB. In fact, you can study the source code at Adobe’s Flex Open Source trunk. That’s actually what you would probably have to do first: Study how FDB works and transfer that knowledge over to the browser world. As far as I remember from the days when I was implementing debugging for Package For iPhone apps, FDB uses a custom protocol for exchanging data between the debugger (FDB) and the running app. This is all done using sockets on some port reserved by Adobe. I think, you could cook something up with WebSockets, where you would use that protocol and transmit debugging data from your JavaScript code.

One thing you have to keep in mind, though, is that your cross-compiler needs to emit extra debug code pretty much after each line of code of the emitted JavaScript, in order to allow the debugger, which is the driver of your JavaScript program, to intercept execution. Some features like call stacks might not be available through the JavaScript API of your browser.

If everything goes well, you will be able to hit the debug button in Flash Builder, which triggers the launch of your default browser with the HTML page associated with your project. Flash Builder will then wait patiently up to 2 minutes for your JavaScript to connect with the debugger that is baked into Flash Builder, which uses the same protocol as FDB.

Frankly, I wouldn’t do all that work just to be able to debug from within Flash Builder. This might turn out to be a feature that requires  one or more full-time developers.