MiniBuilder tutorial: DebuggerConsole

This ActionScript debugger console is not a specific feature of MiniBuilder. It is just a swc library that you can use in any Flash/AIR project, no matter the IDE you use.

For MiniBuilder, it comes as a default, one reason for this being that MiniBuilder doesn’t come with an embedded debugger.

To make a short digression here, actually few developers in the real world use a debugger. But first, let’s clear a little bit the terms:

  • Debugger: a tool that, working together with (sometimes a special version of) the code interpreter (VM), can stop the program in predefined points (breakpoints), execute the code step by step and has other abilities like whatching variables, etc.
  • Tracer or logger: a tool that allows code to execute “trace” commands that output values from the runtime environment. These trace statements have to be compiled with the application. Oftentimes, providers of such tools name them “console” but this is not appropriate. See next:
  • Console: a tool that allows entering text commands to be executed against the running environment of the application. Take a look, for example, at the ubiquitous FF Firebug, or Developer Tools in Chrome browser. They both come with various tools including a real javascript console.

Without underestimating the power of a real debugger, I have to admit that on all the large Flash projects I’ve been part of during the years, none of the programmers did use the debugger regulary. Instead, most just used trace and even throw (funny, isn’t it?).

Now, what’s this thing that I’m presenting you under the name of DebuggerConsole? First of all, it is not a debugger. But indeed, it is a console in the proper meaning of the term. And a tracer. Although, I did not embed a real ActionScript interpretter (for reasons of size), DebuggerConsole can deal with assigns, simple binary opperators, method execution with parameters that can be references, all in the real running environment. And it even provides some code completion! Towards the running environment. How cool is that? Of course, it records previous commands in a history, similar to unix shell. The history is stored locally across sessions.

It’s been years since I can’t work without this console, and right now, I find little use in the debugger. It started back in the AS2 times and now it is much more powerful. You can make it show at startup, you can trigger it programatically or you can trigger it at runtime using javascript. In any case, it starts recording the traces right at the application start, no need to have it turned on. In case a problem shows up, just turn the console on using javascript and start inspecting the variables, or run code rigth there. Next time you might not be able to reproduce the bug!

One of the latest features we found useful to have is the ability to create trace namespaces. When several programmers work at the same project, the trace log gets quite big and you forget where traces come from. Using this feature you can associate your traces with a particular namespace, a simple string that the developer uses for a certain module. If, at runtime, you use the console to set a current namespace, you only see traces from that namespace. If you then turn namespace off, you can see all traces again. The current namespace is stored locally across the sessions.

Init the console in your application entry point:

Debugger.setParent(this, true);

The first param should be a display object that will be added to stage
The second param, tells the console to show right away. If set false, you can still show the console using javascript. You will need to call the function “debug()” on the object dom instance.

The trace command for DebuggerConsole is “debug”. Example:

debug('myVar=' + myVar);

to use a namespace, you need to issue something like this in your code:

debug(['module1', 'myVar=' + myVar]);

Here’s a video with a more detailed example. Forgive me for not adding the voice, I’m probably not such a good speaker anyway. Things to check in the video:

  • Setting up the console
  • Tracing, tracing with a namespace
  • Setting a local reference in the compiled code to have it available in the console
  • Using the console: print variables, assigning, running methods, code completion


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

AddThis Social Bookmark Button

7 Responses to “MiniBuilder tutorial: DebuggerConsole”

  1. It’s funny that you don’t use break points. I and all the programmers I work with use them on a daily basis. Is there any chance of this functionality being added into MiniBuilder? I also just wanted to say that I’m very impressed with what I see so far. Keep up the good work.

  2. thanks for the nice words. the short answer is: it’s possible, we have all the tools. but i have no idea if and when i’ll be able to do it.

  3. First off, I’ve been waiting for something to come along like this for a while. Good initiative! I hope it continues strong.

    Second, I beg to differ with the initial opinion that “actually few developers in the real world use a debugger”. I’ve been programming for 5+ years on various projects from C, C++, and ActionScript. Many of those projects have 3+ programmers on them, and are 6,000+ lines long. I’ve found that having a good debugger is /essential/ for making efficient use of your time. Yes, it is typical in the WWW world not to use a proper debugger, but that comes from lack of ability rather than preference. Just look at Firebug that has the ability to have breakpoints in JavaScript. How many years did that take? When it takes 5+ minutes to recompile your app, being able to stop on an error and investigate is very nice.

    Anyway, I don’t mean to troll on about programming practices. I do agree with Domrein that an integrated solution would be nice.

    Keep up the good work!

  4. @Mantic
    again, thank you for the encouraging words ;)
    it matters to me, it matters for the project. it’s so easy to just drop it somewhere in the middle. in fact, that happens to most projects out there.

    about the debugger, i still backup my opinion. at the company that i’m part of, the main project is about 50,000+ lines. modules, libs, lots of stuff brought by years of development. only small, middle size projects have couple of thousand. even startup time is a killer, not to mention the compilation.

    therefore, playing with the application in real time, being able to, not only watch values but also call methods, set values, etc, can prove productive.

    people coming from c/c++ background have the debugger as a second nature. in c++ it’s the only real alternative. but in scripting it’s different.

    oftentimes, i write a brunch of classes, compile and refresh the app and all works as intended. then i take the console and look deeper for results inside to check if it’s really ok. why start the debugger?

    the debugger is great for algorithms. for sure, game programmers would benefit. but let’s face it, even in games, a lot of it is design, interfaces, content.

    also, in applications that are strongly asynchronous, breakpoints can sometimes even be misleading.

    i do not necessarily advocate console versus debugger. this article just presents an alternative. one that is actually used by people, functional and productive.

    the reason that i affirm that “most programmers” use debugging tools other than a debugger is that nowadays, with this huge spread of easy to learn scripting languages, we have lots of new programmers that have no background at all. ask them about debugger! and some of them are the ones that build lots of the widespread web apps that we all use.

  5. I will take a closer look at your console for sure.

    We use FDT-Enterprise on a daily basis and don’t want to miss the debugging features. Currently we are developing a rather large server / client application — and setting breakpoints in such an asynchronous situation is quite a hassle.

    Also calling testing / validating functions as you go by seems to be great thing. No need to add a button to display the app status in a custom popup.

    But if you could enable setting breakpoints … that surely would be nice(r)

    Thanks for all the time and effort you put into this.

    Best regards, Christian.

  6. I explain to my pals that linux Operating system is so much superior to Windows but it’s unlikely that any of these folks have yet changed!

  7. >Instead, most just used trace and even throw
    That’s how I learnt too, while putting code in the timeline! It was only years later when trying to get my head around c++ that I found out about the stack window and stepping through code.

    I found out about this through wonderfl.net, looking forward to getting my teeth into this!

Leave a Reply

Powered by WP Hashcash