Monthly Archives: October 2008

Bill Wagner recently asked me a couple of Scala.Net questions after reading my recent blog posts.

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;”

While playing around with Scala.Net today I ran into an interesting problem. I was trying to build some Scala code against an assembly built for x86 and I got an exception when I ran the executable:

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.

Reporting from the Programming Summer Camp in Crested Butte, Colorado. This has got to be one of the better places in the world to code. We had a great warm up bike ride this morning, then settled in for an afternoon of coding. I spent my time figuring out Scala.Net with the goal of calling some C# code from Scala.

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