Since Dart should scale from small scripts to full applications it is nice to see support for generics from the start, optional typing and functions as first-class citizens.
However that makes Dart look more like a better Java than JavaScript.

What makes Dart more of a web language is how you perform concurrent computations. This is done by shared-nothing message passing. The same way you do it with workers in JavaScript, actors in Erlang or Scala and hopefully quite soon in the Flash Player. We should not forget Go in this equation since it was also an effort to try out concurrency via channels that can send and receive messages. If we look a little bit more into Dart we can see some of the same ideas.

A worker in Dart are called Isolate [1]. This makes sense since it runs completely isolate from the rest of your program. What is nice about the Dart approach is that you do not have to deal with files anymore when using an Isolate. JavaScript requires you to perform the task of having some special file lying around somewhere that adheres to the Worker protocol. When I write my application, I do not want to think about files that have some special top-level logic in them. Especially, I do not want to write a custom file at runtime using a blob-builder.

Dart embeds this from the start just like Go does. You will have a lot of Isolate objects communicating via a SendPort [2] and a ReceivePort [3]. The Promise<T> [4] is just like Java’s Future<T> a holder for a value that can be computed later. I just wonder why they did not implement a read-only and write-only view on them. It would be nice if Promise<T> would be extended with methods like map, flatMap etc. because your code would be less spaghetti.

With no further ado I would like to explain some code now that you know how Dart works. Basically we calculate the n-th Fibonacci number with a very expensive approach. You would never do this in reality. Let us define fib(x) = fib(x - 1) + fib(x - 2) with fib(1) = 1 and fib(2) = 1. So fib(3) is fib(2) + fib(1) which is 1 + 1. Sorry for to bore you to death.

If we implement this in pseudo-code we get something like this:

int fib(int x) {
  return x < 3 ? 1 : fib(x - 1) + fib(x - 2);
}

If you would like to make this multi-threaded with Scala you could wrap the calls to fib into a Future[Int] like this:

def fib(x: Int) =
  x match {
    case 1 | 2 => 1
    case _ =>
      val n1 = future { fib(x - 1) }
      val n2 = future { fib(x - 2) }
      n1() + n2()
  }

We want to do the same with Dart. Since it is a language targeted for the web we get no access to blocking calls. The Scala code blocks when n1() or n2() is called. In layman's terms: we wait until the value has been computed.

Since there is no support for continuation passing style like C#'s async we have to write a lot of callbacks now.

This is the entry-point for the Dart version of this:

main() {
  int n = 7;

  print("Computing fib($n) ... ");

  new FibIsolate().spawn().then(
    (port) =>
      port.call(n).receive(
        (value, port) => print("fib($n) = $value")
      )
  );
}

First of all we see string-interpolation which is nice. Then we create a FibIsolate which I will show you in a second. When you create an Isolate it does not do anything so we have to call spawn() to perform the actual computation. However spawn returns us only a Promise<SendPort> which we can only use when available. This is done with the then method. then takes a function as an argument.
There are multiple ways we could do this. then((x) => ...) is the same as then((x) { ... }). You are only allowed to use the first form for a single expression but you do not need to write all that boilerplate. In fact you are even allowed to omit a semicolon. Hell Yeah!

So when we get a SendPort which happens to be the case when our function is called we can send some value via the call method. Why use call and not send? call returns a ReceivePort which allows us to wait for the result. We do this by calling receive on the ReceivePort with a closure to print the value we get back.

Now let's have a look at the implementation of FibIsolate.

class FibIsolate extends Isolate {
  main() {
    port.receive((n, replyTo) {
      switch(n) {
        case 0:
          replyTo.send(0); break;

        case 1:
        case 2:
          replyTo.send(1); break;

        default:
          Promise<int> n1 = new Promise<int>();
          Promise<int> n2 = new Promise<int>();

          new FibIsolate().spawn().then(
            (port) =>
              port.call(n - 1).receive(
                (n, port) => n1.complete(n)
              )
          );

          new FibIsolate().spawn().then(
            (port) =>
              port.call(n - 2).receive(
                (n, port) => n2.complete(n)
              )
          );

          n1.then(
            (x) => n2.then(
              (y) => x + y
            )
          ).flatten().then(
            (x) => replyTo.send(x)
          );
      }
    });
  }
}

First of all we have to extend from Isolate. The main() function of an Isolate is its entry-point. Now something that really bugs me is the amount of indentation. Nearly every second Isolate which you are going to write has this form. Your actual logic starts at the fifth indentation level.

In the main method we immediately start listening for messages via the Isolate's ReceivePort. Then we need to react on the message via a switch case. Now although it might look simple in this case it is very sad that Dart does not come with proper pattern matching since you will need to write a lot of switch-case in Dart code. If you have ever seen pattern matching in action using Scala you never want to go back to a dumb switch statement.

In the default case it gets a little bit more interesting. We need to spawn two new instances of FibIsolate since we want to do this recursive. We need to receive their result and when we have both results we want to perform the addition and send our value back to the caller.

Since there are no blocking calls we create a Promise<int> for each FibIsolate. When can complete the Promise<int> once we receive a value from an isolate. This allows us to combine both Promise<int> objects and wait on their results. Why do we not nest the FibIsolate you might ask. Because we want to spawn both at the same time so the computation can happen in parallel.

The actual nesting happens in the n1.then((x) => n2.then((y) => x + y)) construct. However the return type of n1.then((x) => n2.then((y) => ...) is no longer Promise<int> but Promise<Promise<int>>. Fortunately someone thought about this case and there is a flatten() method which turns the Promise<Promise<int>> into a Promise<int> we just have to await and the finally reply with the computed value.

However remember the definition of fib(x)? The case for 1, 2 and 0 is quite simple because we can reply with the value immediately. And we do this by calling send on the SendPort which I named replyTo.

You can take a look at the full example running in the browser here.

What I like about Dart is that someone thought about workers and made them first-class citizens. Pattern-matching is on the road map and they will hopefully copy Scala. There are however a lot of things that I dislike.

1. Semicolons are required but optional for shorthand (x) => x
2. The return keyword is required but optional when used with (x) => x
3. No control about concurrency. Are my isolates CPU or I/O bound?!
4. No syntactic sugar for writing an Isolate
5. Not DSL friendly like Scala or maybe even Kotlin
6. int disguises itself as a primitive but is an object instead
7. Missed the opportunity to embed continuation passing style into the language from the start
8. Function is the only function-type

The type-system can be argued as well. I did not find anything about type erasure yet. Personally Dart feels much more like Java and Go than JavaScript. But in the end I would be quite happy if Dart could replace JavaScript since it is a step in the right direction from my personal point of view.

[1] http://www.dartlang.org/docs/api/Isolate.html#Isolate::Isolate
[2] http://www.dartlang.org/docs/api/SendPort.html#SendPort::SendPort
[3] http://www.dartlang.org/docs/api/ReceivePort.html#ReceivePort::ReceivePort
[4] http://www.dartlang.org/docs/api/Promise.html#Promise::Promise

When understanding Scala it is sometimes important to have a look at some real-world examples — especially when it comes to functional programming. When I first started using Scala I had a hard time understanding some of the constructs used by other people. In this blog post I want do explain some of them. The first example is a classic one. You want to debug some structure and output all elements which have a condition set.

Printing Elements of a Collection

You will find this in every first-steps guide for Scala. What I like about it is the fact that you have only little amount of code to write if you want to inspect a certain structure.

list filter { _.condition } foreach println

Flattening a Collection

Convert a collection of collections to a flat collection. For instance you have a List<List<String>> in Java and want to get a List<String> instead.

final List<String> newList = new LinkedList<String>();
for(final List<String> innerList : oldList) {
  newList.addAll(innerList);
}

A lot of code for a common operation. Probably the reason why the Google Guava library supports Iterables.concat(oldList) to get the same result. So how is this done in Scala?

val newList = oldList.flatten

A simple operation which is very powerful. Let me give you another example. Suppose you have a List[Option[T]] for some T. Before understanding Scala very well and before reading this excellent article about monads I once wrote shameful code like this.

val listOfOptions: List[Option[Int]] =
  List(Some(1), None, Some(3), None, Some(5))

// don't do this!
val listOfDefinedValues: List[Int] =
  listOfOptions filter { _.isDefined } map { _.get }

println(listOfDefinedValues) //List(1, 3, 5)

When encountering such a construct an alarm should raise in your head, telling you there must be a better way to do this. flatten to the rescue. println(listOfOptions.flatten) would do the job.

val listOfOptions: List[Option[Int]] =
  List(Some(1), None, None, Some(2))

println(listOfOptions.flatten) //List(1, 2)

Using flatMap for good

Although flatMap might sound esoteric at first it is a very helpful operation. So first of all you know there is the map operation which is extremely useful in a sense like this.

"hello world" map { _.toUpper }

So what is the deal with flatMap? It would not work in this case and the compiler would raise a type error. That is because a collection is expected as the result.

flatMap makes a lot of sense when you have a collection and need to pass every element into a function that would then again return a collection.

val list = List(1,2,3,4)

def intToListOfChars(i: Int) =
  i.toString.toList

val listOfListOfChar: List[List[Char]] =
  list map intToListOfChars

As you can see calling map with intToListOfChars creates a list of lists and we could later flatten that list agin. Or we simply use flatMap which does all of this in one step.

val listOfChars = list flatMap intToListOfChars

Still this example is pretty awkward. But imagine you have a method like trimToOption(value: String): Option[String] which trims a string and returns None if the string is empty or null (for whatever reason).

If you write a webapplication which expects user input you are probably working with a lot of Option[T] values (or Box[T] in case of Lift). For example like this:

val description: Option[String] = extractDescription(request)

Now you also want to trim that description. Here are a couple of ways on how to do it using trimToOption.

// not so nice
val trimmed1 = trimToOption(description getOrElse "")

// ugly as hell
val trimmed2 = description match {
  case Some(desc) => trimToOption(desc)
  case None => None
}

// kind of ugly
val trimmed3 = (description map trimToOption).flatten

// yey! :)
val trimmed4 = description flatMap trimToOption

So you see that flatMap is actually a pretty usable function.

Passing a Tuple to a Function

Sometimes you have to pass a tuple to a function and instead of the tuple you would like to pass each value of the tuple as a parameter.

val listOfStrings =
  List("Hello", "World")

val withIndex = listOfStrings.zipWithIndex

println(withIndex) //List((Hello,0), (World,1)))

So now imagine you have a method like this:

def printStringWithIndex(value: String, index: Int) =
  println(index+": "+value)

In this case withIndex foreach printStringWithIndex would not work because we pass a tuple to that method. Scala has a nice built-in method called tupled which takes a function and converts it to one accepting a tuple.

withIndex foreach (printStringWithIndex _).tupled

Using the Compiler

Imagine you have a class with a type parameter like CustomList[T] and now you want to have a method which is implemented only for some kind of T. Obviously one way would be to use traits and mix them in on demand. But it gets more and more complex.

Fortunately we can let the compiler proof the evidence of a type at a position in our code.

class Foo[T](bar: T) {
  // only allow this method if T is a String
  def length()(implicit proof: T =:= String) =
    bar.length
}

val foo1 = new Foo(123) //works just fine
foo1.length //does not compile.

val foo2 = new Foo("hello")
foo2.length //5

This is great because it allows us to introduce phantom types and to write less code for certain structures. For instance we have a Connector[A] in Audiotool. This connector accepts connections to other connectors. It is either an input or an output and it transmits an abstract signal. You can only connect an output with an input. A Connector accepts only connections of its own type and virtual connections. This means the following example would be uber-cool code. Unfortunately we did not write Audiotool in Scala ;)

class Connector[A] {
  add[B](conn: Conn[A, B])(implicit proof: A =:= B)
    { ... }

  add(connection: VirtualConn[_, _])
    { ... }
}

Note: This is in fact not a real example since it would not work. You could only connect an output with another output but I think you might get the idea and it is easier to follow.

Conclusion

Functional programming might seem weird. Constructs like =:= or flatMap are awkward at first but make complete sense. Using Scala and picking some of the functional idioms which you think are right and well understood in your team can increase productivity and lead to less bugs.

Lift is very nice because of its excellent Ajax and Comet support. My main problem getting started with Lift was the lack of documentation and real world examples. E.g. if you want a custom 404 page without a redirect your only source of information is a thread in the mailing list. Lift also comes with its own terminology and a lot of custom DSLs.

Cricitcs aside: I am absolutely happy that Lift exists. You simply have to start using it. The documentation has also improved a lot. Simply Lift and Exploring Lift are available for free and the Wiki contains a lot of useful information too.

I want to give you a simple example of why I think that Lift is simply awesome and what sold me to the framework. You probably know those endless scrolling pages.

Let’s see how to develop something similar with Lift and Scala. First of all we have to prepare a little template.

<div class="lift:surround?with=default;at=content">
  <div class="lift:endless">
    <ul>
      <li>item0</li>
      <li>item1</li>
      <li>item2</li>
    </ul>
  </div>
</div>

That is all the HTML we need. In fact we need even less but if you are going for designer friendly templates you could extend it with your usual page chrome.

There are two calls to Scala code in this template. lift:surround will trigger the SurroundSnippet and insert the current template into the default template at the content position.

Our duty is now the implementation of lift:endless. Lift comes with a dynamic convention-over-configuration lookup for the so-called snippets. I am not a fan of COC so I will stick to the manual mechanism of binding endless to a snippet. Lift offers the DispatchSnippet in this case.

You will have to add this line to Boot.scala:

LiftRules.snippetDispatch append Map("endless" -> EndlessSnippet)

It tells Lift to invoke the dispatch method of the EndlessSnippet object whenever a snippet named endless is encountered.

So the only missing piece is the implementationof the EndlessSnippet and this is where Lift really shines.

import net.liftweb.common._
import net.liftweb.util._
import net.liftweb.http._
import net.liftweb.util.Helpers._
import net.liftweb.http.js.jquery.JqJsCmds
import net.liftweb.http.js.JsCmds
import net.liftweb.http.js.JE
import scala.xml.{NodeSeq, Unparsed}

object EndlessSnippet extends DispatchSnippet with Loggable {
  def dispatch = {
    // If you want to execute render only when "embed.xyz" is called
    // you would match on "xyz" here.
    case _ => render
  }

  def render =  {
    // Generate a random identifier
    val containerId = nextFuncName

    // The page which we are currently looking at.
    var page = 0

    // Method to be called by JavaScript.
    def process(in: Any) = in match {
      case id: String if id == containerId =>
        page += 1
        logger.debug("Generating page "+page+".")

        // Generate new markup and append it to the list.
        JqJsCmds.AppendHtml(id, getItems(page))
      case _ =>
        logger.error("Illegal data has been sent.")
        JsCmds.Noop
    }

    // Here we marry the template with our code.
    // "*" is a CSS selector that matches anything and #> binds it to the content
    // we specify.
    // The most interesting part here is the JavaScript  which we bind to the process
    // closure. Lift does all the magic for us and calls the server-side method once the
    // user scrolls to the bottom of the page.
    "*" #> (<ul id={containerId}>{getItems(page)}</ul> ++ JsCmds.Script(JE.JsRaw(
"""$(window).scroll(function(){
  if($(window).scrollTop() == $(document).height() - $(window).height()) {"""+
    SHtml.jsonCall(containerId, process)._2.toJsCmd+"""
  }
})""").cmd))
  }

  def getItems(offset: Int): NodeSeq = {
    val count = 100
    val start = offset * count
    val end = from + count

    // We generate a couple of <li> elements here.
    for(i <- start until end) yield {
      <li>{"item"+i}</li>
    }
  }
}

This little amount of code really shows the power of Lift. Simply write a closure and bind it to your JavaScript. Lift does all the plumbing for you. Then you only have to implement some logic on the server. In most cases you do not even have to write any JavaScript since Lift offers Ajax links, forms etc. already. SHtml.a(...) generates a link which will trigger a function on the server for instance.

But please beware: I am not sure if SHtml.jsonCall is actually the way how you should do this. There might be a better way of calling a server-side method via JavaScript.

There is of course more to Lift. Comet is where things get really cool and the record framework seems interesting as well. Hopefully this little excursion into Scala and Lift could quicken your appetite. Since I am usually not a frontend fan this made it interesting and fun again.

I will try to post a complete project in the next days as well. Before starting with the Audiotool website I wrote some test cases that might help other people getting started.

It is very easy to understand an implicit conversion since most programming languages do this already for you. Here are two examples (AS3/Java):

trace("Implicitly converted: "+1)
System.out.println("Implicitly converted: "+1);

We only have to care about the expression "Implicitly converted: "+1 which will result in “Implicitly converted: 1″. Why does this happen? We have a string on the left hand side of the expression and an integer on the right hand side. When the compiler of your choice needs to emit code for this kind of expression it will widen the type of both operands. In this case the resulting type would be String since an implicit conversion from integer to String exists in both ActionScript and Java. If no such conversion exists you would probably get a compile time error.

The compiler inserts this conversion for you. In this example we can make use of an explicit conversion:

trace("Explicitly converted: "+1.toString())
System.out.println("Explicitly converted: "+Integer.toString(1));

Here we specify that we really want to concatenate two strings which is of course a tedious task. We are lucky to have implicit conversions. Whenever you want to go from type A to B a compiler either inserts an implicit conversion for you or tells you that it cannot do it with an error message.

In certain scenarios you might want to use implicit conversions for your own types. In ActionScript I might want to go from Sprite directly to BitmapData.

Here is an example. Please do not do this at home. There is a of course a much better way (and less memory intensive) to do a hit test on a Sprite.

function hitTest(bitmapData: BitmapData, x: int, y: int): Boolean {
  return bitmapData.getPixel32(x, y) != 0x00000000
}

const sprite: Sprite = new Sprite()
hitTest(sprite, 1, 2)

Now this code would not compile of course since hitTest(sprite, 1, 2) is incorrect. The compiler would tell you that it expects a BitmapData as the first parameter. Let us fix the example:

function hitTest(bitmapData: BitmapData, x: int, y: int): Boolean {
  return bitmapData.getPixel32(x, y) != 0x00000000
}

function toBitmapData(displayObject: DisplayObject): BitmapData {
  const result: BitmapData = new BitmapData(
      displayObject.transform.pixelBounds.width,
      displayObject.transform.pixelBounds.height)

  const matrix: Matrix = displayObject.transform.matrix

  matrix.tx = matrix.ty = 0.0
  result.draw(sprite, matrix)

  return result
}

const sprite: Sprite = new Sprite()
hitTest(toBitmapData(sprite), 1, 2)

Now it works but every time we would want to go from Sprite to BitmapData we have to insert our new toBitmapData function.

And here is what makes Scala so special. You can tell the compiler that toBitmapData may be used as an implicit conversion.

Here is the same example in Scala without making use of implicit conversions:

def hitTest(bitmapData: BitmapData, x: Int, y: Int) =
  bitmapData.getPixel32(x, y) != 0x00000000L

def toBitmapData(displayObject: DisplayObject) = {
  val result = new BitmapData(
      displayObject.transform.pixelBounds.width,
      displayObject.transform.pixelBounds.height)
  val matrix = displayObject.transform.matrix

  matrix.tx = 0.0
  matrix.ty = 0.0

  result.draw(sprite, matrix)
  result
}

val sprite = new Sprite()
hitTest(toBitmapData(sprite), 1, 2)

Not so different. However we can annotate the toBitmapData definition as implicit and the code would look like this:

def hitTest(bitmapData: BitmapData, x: Int, y: Int) = ...

implicit def toBitmapData(displayObject: DisplayObject) =
  ...

val sprite = new Sprite()
hitTest(sprite, 1, 2)

So I think now it is time to take a deep breath. If you think that this is dangerous you should keep two more things in mind. First of all the compiler will only use implicit conversions that are in the current scope of your method. This means if you define an implcit conversion in class A and want to use it in B you have to import it. Also it could happen that you have two implicit conversions in the same scope. Since the compiler does not know which one it should pick it will give you an error message. This makes a lot of sense.

So in the end it is a great way to enable a specific implicit conversion for parts of your code. You are also able to use an import statement only in a method body like this:

def myComplexMethod(a: A) = {
  import ImplicitConversions.fromAtoB
  ...
}

But this is just the one part about implicit conversions. In my A Year Of Scala post I did mention that implicit conversions can be used to build domain specific languages.

Right now we get rid of our explicit casts which is nice but a true DSL needs obviously much more. For instance I might want to say 0xff00ff.toHexString instead of toHexString(0xff00ff). This can also be achieved with implicit conversions. And this is not what you might already know from Java or ActionScript.

Whenever we invoke a method on an object, and the object’s type does not support that method, but an implicit conversion to a different type containing the method exists, it is applied. So remember the Sprite and BitmapData example?

This would be illegal in ActionScript:
sprite.getPixel(x, y)

This would be legal:
toBitmapData(sprite).getPixel(x, y)

And with an implicit toBitmapData method in Scala we get:
sprite.getPixel(x, y)

In fact this is quite simple. So in case you did not notice: this is also statically typed monkey patching. And because you can omit dots and parenthesis we get code like G("vertex1" --> "vertex2"). Where is the implicit conversion? A string has no --> method defined but we could define an implicit conversion to a class VertexPair that has the --> method defined.

Last but not least there are also implicit parameters and values in Scala. In fact only an implicit value may be used as an implicit parameter.

If you are always carrying the same parameter around you, why not define it as implicit? An OpenGL context for instance. render(float t, GL11 gl) is some kind of code that might occur very often. Let us make the gl parameter implicit.

def render(t: Float)(implicit gl: GL11) = ...

Now if you do not have an implicit value available, you can still call this method via render(1.0f)(gl). But if you declare a GL11 object once as implicit it can be passed down the chain very easy.


implicit val gl = framework.getOpenGLContext()
render(1.0f)
render(1.5f)


Now if you call a method inside render that needs an implicit GL11 parameter as well you would not have to declare it as implicit again. But the same rules apply here. If there are two implicit GL11 typed objects available the compiler will complain.

I hope this makes working with implicit conversions and values a little bit easier.

However the Apparat version is much better. First of all we have put a lot of work into Apparat to make such transformations rock-solid. AS3C had its issues and was never a reliable tool. But there are a lot of new great features Patrick implemented. You can mix AS3 in your bytecode as well. __as3 is the best friend of __asm. Because sometimes writing pure bytecode is very verbose and not necessary.

A simple trace('Hello World!') with pure bytecode would look like this. Please note the FindPropStrict and CallPropVoid operations which reference trace.

__asm(
  FindPropStrict(AbcQName('trace', AbcNamespace(NamespaceKind.PACKAGE, ''))),
  PushString('Hello World!'),
  CallPropVoid(AbcQName('trace', AbcNamespace(NamespaceKind.PACKAGE, '')), 1)
);

Finding the object in the correct namespace is often a very cumbersome task. Thanks to __as3 we can also write this in a much more conciese way.

__asm(
  FindPropStrict(__as3(trace)),
  PushString('Hello World!'),
  CallPropVoid(__as3(trace), 1)
);

Note that the ASM compiler will try to guess the required name once it is requested by an operation. You can use __as3 also for other tasks.

var x: int = 1;
__asm(
  FindPropStrict(__as3(trace)),
  __as3(x < 10),
  CallPropVoid(__as3(trace), 1)
);

This would trace "true" for instance. If you are curious about the ASM syntax I can recommend you using the dump tool. It produces code which is nearly __asm-ready. We will probably write another output so you can directly transform existing code to __asm calls.

If you are interested in some more examples the Apparat Math replacements make use of __asm now as well. IntMath is a good example for an inlined class where you are using maybe a simple method like IntMath.abs and the heavy lifting is done behind the scenes using inline assembler. To use the ASM expansion you have to process your SWF file with TDSI. It is by default turned on.

I have released Apparat RC5 at GoogleCode. It contains a really cool feature which is called LZMA compression.

Reducer has advanced a lot during the last couple of weeks. It is now also a strong SWF compression tool even if you do not have any PNG files it can compress. You may ask: “What is that Matryoshka doing there? And why the hell the top hat?” The top hat: I do not know. The Matryoshka: I can explain.

The Flash Player does not understand LZMA. SWF files are compressed using good old DEFLATE. So what happens? Apparat extracts your original SWF. It compresses it again using the LZMA algorithm. The compressed SWF is injected into another SWF that contains an LZMA decoder. Size, background color, frame rate, etc. get adjusted. Finally you get a new SWF that contains your old SWF and a decoder to extract it at runtime. The overhead of the decoder is currently at around 5kb and I hope I can get it even smaller.

When you open that SWF with the Flash Player it will extract your original file and load it. Another nice feature is that I created different versions of the runtime decoder. One is using a classic preloader which is great if your SWF is a little bit bigger. And hey: it is a preloader for free so you do not have to deal with the [Frame] hassle. But here is the catch. We at audiotool.com always write our SWF files in the same style and I can just hope you do the same or use the great InitInjector by Valentin Simonov.

Your main SWF class or the so called DocumentClass must make sure that a stage is available before accessing it. This is really easy:

public function Main() {
  addEventListener(Event.ADDED_TO_STAGE, init)
  if(null != stage) init()
}

private function init(event: Event = null): void {
  removeEventListener(Event.ADDED_TO_STAGE, init)
  // your original constructor code goes here ...
}

Stick to that rule or InitInjector can automate it for you. Otherwise you will get a runtime exception that the stage is null. So this is one new feature. The other one is actually pretty standard. If you compile and link against a SWC file all classes will come in their own ABC file. Each ABC file has a constant pool. So if you link against 1000 classes you get 1000 constant pools. Reducer can merge all those files into a single one with some minor exceptions. It can also sort the constant pool so that constants which are used frequently consume less bytes when accessed. The funk-as3 test runner which links against FlexUnit and the Flex framework is only loosing 3.01% of its weight with the old Reducer. The new version reduces it by 17.81% already thanks to the ABC merging. Combine that with some LZMA love and we get 35.34%.

Besides you can call the LZMA compression as often as you want for some basic obfuscation. The LZMA compression alone is already a (weak) obfuscation of your bytecode.

Last but not least: Good news everyone! Scala 2.8 arrived so this is the last time you will have to update it for a while.

You can download the latest Apparat version at GoogleCode. Scala 2.8.0 is required.

Shawn Pucknell is obviously raising the bar. This will be a tough time for an ordinary speaker like me. However I have no other intentions than giving a lecture that proves itself worthy of this event.

We have release a small update of the AudioTool and included André’s ToneMatrix. Some features that have been implemented in the last weeks are online as well. Removing an effect for instance will not destroy the cables. The desktop scales now without interrupting the audio output and various other performance tweaks have been made.

Hooray! The Hobnox AudioTool has been updated. You will find the TR-808 now and also some of our new stompboxes like the Compressor and Crusher. The mixer has also been expanded to cover 16 channels.

There is a lot more stuff in the pipe and I am really excited about it. Developing the timeline and saving arrangements are the next big steps. Until then: have fun playing around and stay tuned!

Right now I am working (besides of my work) on very nice filters to synthesize textures. As always: Stay tuned!

Now about the Imageprocessing part. I wrote a program that gets structural information from an obstacle you hold into the camera. The title is “Objectrecognition of presented obstacles” and this is done using a motion-detection for the movement. A scene background-substraction is done to get only the moved obstacle. Then there is a median-colour lookup after a lof of filters have been applied. Closing, Retinex and Blobcounter to mention only some of them.
The last final part which I like most is the artificial neuronal network that recognizes the shape of the obstacle. I used a simple feed forward net and the results were also quiet good.

You can read the full article here. I am sorry but it is not written in English so you can only read if you understand German.

The protocol is based on UDP. So there can be packages in wrong order or even never reaching the target. As you can see the class should handle all possible problems with UDP. Features are for example merging of splitted packages and all that stuff.

• HLServer Class

I did not know about fabchannel before but this seems to be a great site. I am looking forward to the Bloc Party webcast :-)