Thank you to all of you who came out to my talk, it was a lot of fun giving it and I hope you took something useful away. I’ve posted my slides and demo code to BitBucket mercurial here:

https://bitbucket.org/benbarefield/kinectcm2012

The HoverBugz code will be available on the SRT website in the next couple of days. If it’s not there yet, check back soon.

What is the debugging story for Scala.Net?

A pdb file is required for debugging in Visual Studio, just like with C#. The pdb file contains all of the debugging symbols that Visual Studio uses to track the run of the program. A pdb file can be generated when running ilasm:

ilasm /PDB <MSIL file>

After running ilasm, open Visual Studio and create a new Blank Solution (found under Other Project Types –> Visual Studio Solutions.) Then right click the Solution and click Add –> Existing Project. Change the filter to show executable files and add the executable generated by ilasm. Now the executable can be run through Visual Studio in various ways; for example, right click the executable –> Debug –> Start new instance.

Before running the executable, make sure that “enable address level debugging” is set by going to Debug –> Options and Settings.

A break point can be set in any of the Scala files associated with the executable by opening the file in Visual Studio (File –> Open) and setting a break point as if it was any other .Net language file.

If you don’t need a using statement, does that mean that all the Scala code goes into the global namespace?

In my Calling Scala from C# post, I said:

… [it] surprisingly doesn’t require any extra using statements

The reason a using statement was not required was because I did not put the Scala code I wrote into a package. If I had, a using statement would have been needed for the package.

For example, if my Scala code has been:

package Speaker

class ScalaSpeaker {

    def Speak() {

        println("Hello");

    }
    def Speak(name: String) {

        println("Hi, " + name + ", glad you could join us!")

    }

}

Then my C# would need “using Speaker;”

After a short email exchange with Miguel, I was able to get Scala compiling against some of the XNA assemblies. This allowed me to extend the Game class and open an XNA window. The problem I was having was compiling the Scala against multiple dependent dlls. I expected the “Xassem-path”argument to take multiple parameters, one for each of the assemblies. Instead, the solution was to add another –Xassem-extdirs path that contained the XNA assemblies (and mscorlib.) My compile looks like:

<Scala.Net directory>\bin\scalacompiler.exe 
–target:msil 
–Xassem-extdirs <Scala.Net directory>\bin
-Xassem-extdirs <directory with XNA assemblies>
-Xshow-class <Scala class with main defined>
-Xassem-name <Name of MSIL file to output>
<scala files>

After running ilasm on the MSIL file generated, corflags needs to be run on the resulting executable to put it into 32 bit mode. Running the executable opens the game window.

This is certainly a proof of concept; unfortunately that is as far as I could reasonably get. Miguel seems committed to getting Generics support in Scala.Net, so it should be possible to build a full game soon.

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly […]. An attempt was made to load a program with an incorrect format…

After a bunch of internet searches, and some help from Bill Wagner, I got this working. The executable needs to be set to run in 32 bit mode. This can be done with the corflags tool. corflags will exist in your path from a Visual Studio terminal. The trick is:

corflags <Executable name> /32Bit+

After that everything worked.

First, I built a class in Scala similar to my C# class from yesterday:

class ScalaSpeaker {

    def Speak() {

        println("Hello");

    }

    def Speak(name: String) {

        println("Hi, " + name + ", glad you could join us!")

    }

}

Just like before, the Scala needs to be compiled to MSIL. There are fewer arguments needed because the Scala is not referencing any other dlls and does not contain the entry point for the executable:

<Scala.Net directory>\bin\scalacompiler.exe

–target:msil

–Xassem-extdirs <Scala.Net directory>\bin

<scala files>

Where:

• <Scala.Net directory> is the directory where the Scala.Net SVN repository was checked out to

After the MSIL has been generated, it can be turned into a dll:

ilasm /DLL <MSIL file>

Notice the /DLL flag for ilasm, this is where the magic happens.

After running ilasm, the new Scala dll can be referenced in a .Net application. I created a console application and added a reference to the dll. For the application to run propertly there are a few more dlls that need to be referenced, all of which can be found in the bin directory of the SVN repository:

CSharpFilesForBootstrap.dll

IKVM.OpenJDK.Core.dll

jfisl.dll

scalalib.dll

scalaruntime.dll

The C# is very straight forward, and surprisingly doesn’t require any extra using statements:

using System;

namespace CallScala

{

    class Program

    {

        static void Main(string[] args)

        {

            var speaker = new ScalaSpeaker();

            speaker.Speak();

            speaker.Speak("Jim");

        }

    }

}

The Scala.net compiler is in an SVN repository located at: http://lampsvn.epfl.ch/svn-repos/scala/scala-experimental/trunk/bootstrap

I started by writing a small C# class library. I created one class with a couple of methods. This is pretty standard “getting up to speed” stuff:

using System;

namespace Echidna

{

    public class Speaker

    {

        public void Speak()

        {

            Console.WriteLine("Hi there.");

        }

        public void Speak(string name)

        {

            Console.WriteLine(string.Format("Hi, {0}, glad you could join us.", name));

        }

    }

}

Next, I dove into the Scala. For this experiment all I needed was an object whose Main created an instances of my C# class and called its methods:

import Echidna.Speaker

object Test {

    def main(args: Array[String]) {

        val speaker = new Speaker()

        speaker.Speak

        speaker.Speak("Joe")

    }

}

I’d like to note here that the import is a Scala import statement (not a C# include), so the class name needs to be included. I could also have written “import Echidna._” to get everything from the Echidna namespace. The compiler error did not make it especially obvious that I had messed this up.

With all my code built I could start compiling. Currently, there are two steps to create an executable, but there are plans to get rid of the second step. First, MSIL is created using the Scala.Net compiler:

<Scala.Net directory>\bin\scalacompiler.exe

-target:msil

-Xassem-extdirs <Scala.Net directory>\bin

-Xshow-class <Scala entry class>

-Xassem-path <Dependent Assemblies>
<Scala files>

This is the bare minimum required to compile the Scala into MSIL. I inserted the new lines for ease of reading and to make it more obvious what is going on. Notes:

• <Scala.Net directory> should be the directory that you pulled the SVN repository into
• <Scala entry class> is the Scala class that should serve as the entry point for your program. In my case it was “Test”
• <Dependent Assemblies> are the .Net assemblies your Scala program relies on. In my case this was “Echidna.dll”
• <Scala files> are your Scala source files. In my case it was “simple.scala”

Next, the MSIL needs to be turned into an executable using ilasm. I opened a Visual Studio command prompt so that ilasm was in my Path:

ilasm Test.msil

The last problem I ran into was that the executable couldn’t find scalalib.dll, so I copied it out of the directory where the compiler is (the same as <Scala.Net directory>.) After this, my executable ran perfectly.

More information on the compiler and it’s capabilities (for example, it does not currently support .Net generics) can be found at: http://lamp.epfl.ch/~magarcia/ScalaNET/2011Q2/PreviewScalaNET.pdf

The API documentation is fairly comprehensive and the getting started guide is a quick read (on the Kinect SDK website, not included in the download). The two samples are large and cover all the major points of the API. I think I would have preferred smaller, more targeted samples, but they are still good for figuring out how to use pieces of the API.

The Kinect hardware does quite a bit of processing, so the API is fairly easy to work with. Pulling color image data off of the device is almost trivial:

var kinect = new Runtime();

kinect.Initialize(RuntimeOptions.UseColor);

kinect.VideoStream.Open(ImageStreamType.Video,

   2, ImageResolution.Resolution640x480, ImageType.Color);

kinect.VideoFrameReady += HandleNewColorVideoFrame;

This is all the code needed to start receiving video from the Kinect. Every time there is a new frame available the “HandleNewColorVideoFrame” method will get called. The EventArgs has a property that contains the image data of the new frame.

The really revolutionary part of the Kinect is the depth map it provides of the scene it can see. For each frame of the depth map video it can create detailed skeletal information about two people in the scene. This skeletal information gives the (X, Y, Z) absolute position of 20 points on the body and the confidence of that absolute position. The confidence is mostly for points that the Kinect cannot directly see. For example, the Kinect will still try to track my hand if I put it behind my back. It is just as easy to get the skeletal data as it is to get the color video image:

kinect = new Runtime();

kinect.Initialize(RuntimeOptions.UseDepthAndPlayerIndex | 

   RuntimeOptions.UseSkeletalTracking);

kinect.DepthStream.Open(ImageStreamType.Depth, 2,

  ImageResolution.Resolution320x240, ImageType.DepthAndPlayerIndex);

kinect.SkeletonFrameReady += ProcessSkeletonFrame;

ProcessSkeletonFrame will be called every time the Depth video has a new frame. The EventArgs contains a list of all of the skeletons the Kinect has information about.

This is all the code you need to get up and running with a Kinect. It’s pretty awesome that it takes so little to start working with it; however, working with it is by no means easy. There are a lot of considerations that need to be made to make the Kinect a good user experience. In my next post I will go over a couple gotchas that I encountered while building my sample.

I think Git’s idea of tracking changes instead of files is a really cool way to think about source control. Change tracking instead of file tracking allows us to create much more granular commits, giving even more control over multiple versions of our source.

However, I think the way this is implemented in Git makes using it a bit more of a burden. Needing to add each change to a staging area does not feel like  Git “getting out of the way until you need to deal with source control”. I have to either be constantly adding changes to my source control as I make them, or I have to figure out how everything should be committed after I’ve written the code. It also means that every time I want to add changes to source control I have an additional step to take over a more “traditional” source control system. I would much rather see an “opt-out” model of change tracking than an “opt-in” model. Most of the time, all of my changes should be taken together as a single commit. When I do have changes that should be separated into their own commit they are in the minority of the changes that I have made.

Currently, Git has not convinced me to convert from Mercurial, especially since I currently have a few repositories on BitBucket, but I think it is very worth while to know all of the options out there.

Turns out it doesn’t! Classes get disposed just as you would expect them to. It’s nice that at least one of these platforms doesn’t have this bug, but I think it’s too bad that we can’t expect consistency between WPF and Silverlight.

The basic idea is that when the source of a binding is a(non-Dependency) property on a class that does not implement INotifyPropertyChanged, WPF creates a ReflectPropertyDescriptor to facilitate the binding. The Microsoft page seems to suggest that this should allow for updating the binding value when the backing property changes, but this doesn’t actually work. The ReflectPropertyDescriptor gets added to a global table and does not get removed, creating a memory leak.

At first glance, it looks like your view model needs to have a reference to the View because of the second condition:

Object X contains a direct reference or an indirect reference to the target of the data-binding operation.

Later there is a note that says that the binding can cause this “indirect reference” to the view:

The reference between object X and the data-binding target is caused by the first condition that is listed in the "Cause" section.

I have created a simple test bed application that shows the problem. Setting a break point in the Finalizer of ViewModelOne shows the memory leak. When INotifyPropertyChanged is not implemented, the Finalizer never gets called. Adding the implementation of INotifyPropertyChanged allows the Finalizer to get called.

The take-away? Make sure you implement INotifyPropertyChanged on view models. Microsoft calls this behavior “by design”. It sounds an awful lot like a bug to me.