Tuesday, April 17, 2012

Android Emulator: How to compile ICS x86 system-image with KVM support

If you've ever tried the Qemu-based Android emulator which ships with the SDK, you probably know the painful poor performance and slow response time caused by ARM emulation.

Thus just recently Intel decided to port the existing ARM-specific Android kernel to their x86 architecture. The next logical step was to add hardware-assisted virtualization (KVM) - which they did.

Fortunately, both Intels Kernel and the Android ICS sources are open source. It took me some time to get Android Ice Cream Sandwich up and running from ASOP sources, but finally it worked out.





The following article describes how to compile ICS for the x86 platform and how to plug in Intels Kernel. The result is a hardware-accelerated ICS system-image for the emulator-x86 with blazing fast performance:

http://blog.testobject.org/2012/04/giving-your-android-emulator-boost.html

If you dont want to get your hands dirty, the article refers to a precompiled system-image which can be downloaded and installed in a few simple steps.


Sunday, November 27, 2011

The hidden mechanics of humor?

Humor is the embodiment of a latent method that discovers false inference in the brain. What an intriguing thought! Does this imply that a logician and a comedian never mix up? I simply couldn't resist to re-quote the Slashdot post [1]:

"The sense of humor is a ubiquitous human trait, yet rare or non-existent in the rest of the animal kingdom. But why do humans have a sense of humor in the first place? Cognitive scientist (and former programmer) Matthew Hurley says humor (or mirth, in research-speak) is intimately linked to thinking and is a critical task in human cognition because a sense of humor keeps our brains alert for the gaps between our quick-fire assumptions and reality. 'We think the pleasure of humor, the emotion of mirth, is the brain's reward for discovering its mistaken inferences,' says Hurley, co-author of Inside Jokes: Using Humor to Reverse-Engineer the Mind. With humor, the brain doesn't just discover a false inference - it almost simultaneously recovers and corrects itself. For example, read the gag that's been voted the funniest joke in the world by American men. So why is this joke funny? Because it is misleading, containing a small, faulty assumption that opens the door to a costly mistake. Humor is 'when you catch yourself in an error, like looking for the glasses that happen to be on the top of your head. You've made an assumption about the state of the world, and you're behaving based on that assumption, but that assumption doesn't hold at all, and you get a little chuckle.'"

[1] http://science.slashdot.org/story/11/11/27/037237/the-science-of-humor

Monday, November 21, 2011

Get a taste of Stanford: Online lectures 2012

These days I'm having too many irons in the fire. To give you some hints, there's more coming which sheds lights on turning non-negative matrix factorization into an embarrassingly parallel problem (plus avoiding the painful hadoop overhead [1]) and something new which hopefully combines machine learning methods with agile development methodologies to solve a well-known ancient problem in software engineering.

Anyhow, to keep this blog alive, here's the latest from Stanford. Anyone who has listened to the initial three courses (Database System, Machine Learning and Artificial Intelligence) surely has enjoyed their quality and will enlist again. They are back with an incredible list of free interactive video lectures on machine-learning:


There is also a set of basic introductions to CS, SaaS and Entrepreneurship. The lectures are splitted into weekly video sessions and optional quizzes or programming exercises.

The offerings will start this January, so don't miss your spot and sign up now!

[1] https://mpi-inf.mpg.de/~rgemulla/publications/rj10481.pdf

Saturday, October 29, 2011

A giggly polymorphic view on stereotypes

Did you ever wonder why developers are so slow? How project managers can spend a day doing nothing? Or, why designer is a job title?

I guess most of you have a specific stereotyp in mind. But does this generalize to a broader crowd? Are stereotypes typical singleton objects by definition? Or should we introduce "conditional" stereotyps depending on the point of view ...

Let's put this literally into perspective:


I hope you did not expect something deep here ... :)

In a sense, this reminds me of Brave New World ... "I'm really awfully glad I'm a Beta, because I don't work so hard. And then we are much better than the Gammas and Deltas. Gammas are stupid."

Wednesday, October 26, 2011

How to avoid try/catch blocks

As I'm running low on time these days, but want to keep the steady flow of Scala buzz alive, here's another simple trick. Dealing with Java I/O you probably know the unavoidable burden of exception handling:
import java.io.*;

public final class CatchMeIfYouCan {
  public static void main(String ... args) {
     BufferedReader reader = null;
     try {
        reader = new BufferedReader(new FileReader(...));
        String line = null;
        while((line = reader.readLine()) != null) {
             ...
        }
     } catch(IOException e) {
             ...
     } finally {
        try {
            if(reader != null) reader.close();
        } catch(IOException e) {
             ...
        }
     }
  }
}
Ouch! It takes 16 lines of code to read some lines from a file. In an ideal world we would be able to factor out this reoccuring pattern of nested try/catch blocks.
What we could do in Java is to simply put the logic which operates on the "line" string into another class and pass it to a factorized version of the code above:
public final class StillNotThere {
 interface Read { void line(String str); }

 private static void read(Read read) {
    BufferedReader reader = null;
    try {
       reader = new BufferedReader(new FileReader(...));
       String line = null;
       while((line = reader.readLine()) != null) {
            read.line(line);
       }
    } catch(IOException e) {
            ...
    } finally {
       try {
           if(reader != null) reader.close();
       } catch(IOException e) {
            ...
       }
    }
 } 

 public static void main() {
   read(new Read() { public void line(String str) { ... } });
 }
}
Looks better! But still feels clumsy to define an anonymous class and ... nah. In Java 7 the try / catch syntax was enhanced to support the java.lang.AutoClosable interface. This effectively removes most of the boiler plate code, but at the same time reflects how limited the expressive power of Java is. We don't want to touch the syntax of a language just to get some minor things right.

So, let's see what we can do about it in Scala! We introduce a function named "using" which takes an I/O handle (using duck-typing to ensure the type defines a close() method) and in turn passes it to a given function f.
object IO {
  def using[R, S <: { def close() }](s: S)(f: S => R): R = {
    try {
      f(s)
    } finally {
      if (null != s) {
        try {
          s.close()
        } catch {
          case _ => {}
        }
      }
    }
  }
}
Equivalent to the Java code above:
object Better {
  def main(args:Array[String]) = using(new Reader(...)) {
    reader => reader.getLines.foreach(line => ...)
  }
}
I hope your brain screams "DAMN!". Doesn't "using" almost look like a first-class citizen?

Tuesday, October 18, 2011

Calling a set of n-ary functions ... in a weird way

Here's another brain teaser. It just happened that I needed a weird construct for my tiny graph-rewriting framework.

What I'm looking for is something similar to this:
val r1 = Rule(
   left = Graph(Node("a")),
   right = Graph(Node("a") ~> Node("b")),
   bind = ( (Node("a"), Node("b")),
      { (a:Node, b:Node) => b.foo = a.foo } ) )
To put it in words, the left-hand side of rule r1 looks for an arbitrary node (here "a" is just an symbolic id within the scope of the rule). If the graph contains such a node (or: it is not empty), the right-hand side extends the graph by a new node "b". Finally, the binding step assigns free variables of "b". The tricky part here is the signature of the "bind" argument. The first argument is a n-ary tuple identifying a set of nodes which are in turn passed to the second argument (a function).

Now lets put on the glasses of "abstraction and genius" and have a second look. Actually what we really want is to call a n-ary function given a n-ary tuple of arguments. Of course these arguments can be transformed prior to passing them to the function, but our glasses hide these details from us ...

Okay then lets get into the specifics here. This is what our magical method which calls a set of n-ary functions should look like:
val f = { (a:Int, b:Int) => println(a+b) }
val e = { (a:Int, b:Int, c:Int) => println(a+b+c) }

call( ( f, (1, 2)), (e, (1, 2, 3) ) ) // prints 3, 6
The function 'call' simply takes an arbitraty set of 2-tuples (function, args). But how the heck can we express this in Scala?

Well, it turns out Scala provides the means implement this without much hassle:
  • Tuples: Yes! Tuples as first-class citizen in Scala e.g. ("a", "b", "c")
  • Kleene closure T*: Not so sure the term really fits, basically it's the n-ary cartesian product or var-args of type T
  • Implicit conversions: If a type conversion A -> B is required to e.g. match a function signature, Scala tries to call a user-defined f : A -> B (known from C++)
It still requires some more backgrounds to put this together. Tuples are represented by TupleN types where N denotes the number of arguments the tuple holds. Product is the base trait of TupleN.
Accordingly functions are represented by FunctionsN types. Note that the function tupled() turns Function2[A,A,R] into Function1[Tuple2[A,A],R] where Tuple2 <: Product.

What we end up with is:
def call(p: Tuple2[Function1[Product,Unit], Product]*) = 
{ p.foreach(f => f._1(f._2)) }

implicit def func2tupled2[T](f:(T,T) => Unit) = 
{ f.tupled.asInstanceOf[Function1[Product,Unit]] }
implicit def func2tupled3[T](f:(T,T,T) => Unit) =
{ f.tupled.asInstanceOf[Function1[Product,Unit]] }
      
val f = { (a:Int, b:Int) => println(a+b) }
val e = { (a:Int, b:Int, c:Int) => println(a+b+c) }

call( ( f, (1, 2) ), (e, (1, 2, 3)) ) // prints 3, 6
I hope your brain screams "WOOT!". Read it from the bottom up. The function 'call' takes e,f which signatures are converted from Function2[Int,Int,Unit] and Function3[Int,Int,Int,Unit] to Function1[Product,Unit] by func2tupledN. At last, 'call' invokes each function f and passes a tuple holding the arguments.

Sunday, October 16, 2011

Scala the next Java: What is the Buzz All About?

Have you ever wondered what the entire Scala buzz is all about? What you may already know:
"Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application." [scala-lang]
To put it short: Scala is a hybrid object-oriented and functional programming language, runs on top of the JVM and is equipped with an expressive static type system.

So, Scala is the next Java, you say ... are you nuts? Probably yes, there's a disturbing "Scala is too complex for the average programmer" conspiracy. I'm not eager to trigger a war of the worlds, but if you are one of these folks, don't panic and try to give it a different perspective:
  • Scala is a superset of Java: It does not force you to use fancy syntax, but rather gives you the freedom to expand your arsenal gradually
  • Progress requires change: You want a statically typed language with improved expressiveness and powerful idioms, but by no means touch complexity! Oh boy ...
If you are willing to learn and want to advance, then Scala is your best bet for a long term replacement of Java. Probably, the most obvious question is: How does Scala compare to its (other) direct competitors?

Why would I choose Scala over Java?
  1. Expressiveness improves readability and reduces code size (see features below)
  2. Sophisticated type system and type inference leads to robust and compact code
  3. Extensive support for internal/external DSLs
Why would I choose Scala over Python?
  1. Static typing system catches most of your typos at compile-time
  2. Superior performance due to JVM byte-code (yes, there's PyPy, but ...)
  3. Large collection of third-party libs / Java interop (although there are countless Python bindings)
Why would I choose Scala over Haskell?
  1. Haskell's learning curve is steep (but worth it)
  2. Sometimes Haskell's purity-by-default is a PITA (io monads, no "real" imperative code)
  3. Lack of third party libraries
Now you are thinking, that's all he's got in his little arsenal? Nah!
  • Groovy:  "I can honestly say if someone had shown me the Programming Scala book by Martin Odersky, [...] back in 2003 I'd probably have never created Groovy." [James Strachan creator of Groovy]
  • Clojure: Lisp, urgh. I never liked it (yes, a very scientific statement)
  • F#: We don't want .net / mono ... do we? Although the language is nice ...
  • C++: boost gives you unlimited freedom ... and unmatched error complexity, compile times (even with pre-compiled headers), ...
Open for discussion!

To back this up with something concrete, let me give you an (incomplete) overview of some very basic syntactic features of Scala:

Here we go:
import scala.collection.mutable.HashMap

// io
println("Hello World!")      
    
// containers
var l1 = List(1,2,3) ++ List(4,5)
var l2 = (1 to 5 toList)
var l3 = List(1,2,3).filter(_ > 2)
var l4 = 1 :: 2 :: 3 :: Nil    
    
// tuples
val pair = (99, "balloons")
println(pair._1)
println(pair._2)
    
// traversal
val s = for ((k, v) <- HashMap(1 -> "a", 2 -> "b")) yield (k + v)
println(s)    
    
// factory companion
class Pojo(greeting: String, count: Int)
object Pojo { def apply(greeting: String) = new Pojo(greeting, 1) }
var p = Pojo("ops")    
    
// type (alias) definition
type T = HashMap[String, Int]
val m = new T    

// implicit conversion
class RichString(str: String) {
   def shrink = str.toCharArray.foldLeft("") { (t, c) =>
     t + (if (c.isUpperCase) c.toString else "")
   }
}
implicit def str2RichString(str: String) = new RichString(str)
println("HyperText Transfer Protocol".shrink) // HTTP
    
// operator overloading
val treasure = HashMap(1 -> "Go to island.")
treasure += 2 -> "Find big X on ground."    
    
// lambda
l1.foreach(i => println(i))
l1.foreach(println(_))    
    
// higher order functions
// def foldLeft[B](z: B)(f: (B, A) => B): B
var str = (1 to 3 toList).foldLeft("X")((str,num) => str+num)
println(str) // X123    
    
// currying
@inline def plus(a:Int) = (b:Int) => a+b
var 3 = plus(1)(2)
    
@inline def plus2(a:Int, b:Int) = a+b
val plus2Curried = Function.curried(plus2 _)
var 3 = plus2Curried(1)(2)    
    
// binding
val plus5 = plus(5)(_)
var 6 = plus5(1)
    
// multiple inheritance with order
trait Friendly { def greet() = "Hi" }
trait Dog extends Friendly { override def greet() = "Woof" }
trait Cat extends Friendly { override def greet() = "Meow" }
val dogCat = new Dog with Cat
println(dogCat.greet()) // "Meow"
    
// duck typing (upper type bound on "greet()")
def f[G <: { def greet() : String }](g:G) = println(g.greet())
f(dogCat)    
    
// pattern matching (conditional down-cast)
abstract class A
case class B(i: Int) extends A
case class C(s: String) extends A
 
val c = new C("C") match {
 case b : B => b.i
 case c : C => c.s
}
println(c)