Ulf Wiger

Those of you who couldn’t come to Palo Alto, please sign up for the Factory in London. It is going to be a great conference.

I had great fun at QCon.

Just having returned home from QCon in London, where there were some great talks about, and significant interest in, functional programming, I’m reminded of my own keynote from the ACM SIGPLAN Erlang Workshop in Tallinn 2005. It was called “Sourdough and Erlang”, and as much as I would like to flatter myself by calling it “prophetic”, I’m sure it would just tempt others who were there to propose some other, more fitting descriptions.

Clocking this with timer:tc() in coLinux/Vista on my 2.17GHz dual-core Pentium laptop (not using SMP erlang, though), I achieve 1450 article fetches/second. That’s a lot better than I had expected. Erlhive, apparently, is not so slow after all.

My thirteen-year sojourn at Ericsson is now at an end.
I will join my old friend Francesco Cesarini as the new CTO of Erlang Training & Consulting.

While it’s not immediately obvious why industry representatives ought to attend POPL (which is, after all, a very academic conference), I’d like to suggest that it’s worth your while. You can expand your horizons and your network, and improve your intuition about where the programming community appears to be headed. Especially as we are experiencing a major paradigm shift, I’d expect that the first indications of trouble (or hope) might well come at conferences like POPL.

I was invited to give a tutorial at the Declarative Aspects of Multicore Programming (DAMP) workshop, in conjunction with POPL 2009.

Not that I spend much time compiling erlang code in Windows (unless I’m using cygwin or coLinux), but the issue does pop up from time to time. Here are a few minor tricks that can help a bit.

Starting Erlang in the current directory
For a unix user, it’s of course odd that this should be a problem.

John Hughes used a nice trick that’s so simple that I slap myself for not having thought of it: Right-click on a .beam file, select “Open With…” and locate werl.exe. Now you can open an erlang shell in the current working directory by double-clicking a .beam file.

Modifying the Windows context menu
So what if you don’t have any .beam files, and you’re trying to get to an erlang shell
in order to create some?

I did some googling and found this tutorial on youtube on how to add custom entries to the context menu.

It seemed simple enough, but Vista still served me a few hours of utter confusion since it took what I inserted, and then copied it to another place in the registry (without letting me know)… but only the first time. My changes and additions were simply ignored. The solution? Search the registry for the key you inserted, and you’ll figure out where Vista wants it to be, then make your changes there.

What I’ve experimented with so far is to add under Computer\HKEY_CLASSES_ROOT\ErlangSource\shell\ the following entries:


Compile with erlc
- Command = "C:\Program Files\erl5.6.3\bin\erlc.exe" "%1"
Make all
- Command = "C:\Program Files\erl5.6.3\bin\werl.exe" "-make"
Erlang shell
- Command = "C:\Program Files\erl5.6.3\bin\werl.exe" "%1"


A problem with running erlc this way is that the window is destroyed immediately upon completion. I’ve poked around a bit for good workarounds. One option is of course to write an erlang function that compiles the file, then either sleeps a short while, or waits for input.

Another graph courtesy of Bjarne Däcker. Interest in Erlang seems to increase at an exciting rate. The monthly hit rate at www.erlang.org now for the first time touches the 2 million mark.

Requests/month to www.erlang.org

Pleased with my initial success with coLinux, I set out to add the finishing touches.

I’ve gone back and forth on the network configuration, trying e.g. to carefully follow Bebbo’s config example. It didn’t work for me. There seem to be issues running TAP on Vista, and bridging with my Wireless LAN interface caused the WLAN connection to start acting up. I also tried the Microsoft Loopback adapter, but no joy. I finally figured out that just using slirp with the following (recommended) setting:

(upate: I made a last minute change that proved wrong. This is what works.)
eth0=slirp
eth0=slirp,,tcp:5901:5900

worked just fine. The only problem was that I thought I had to set the DISPLAY variable to the (dynamically configured) IP address of my laptop. But looking at the auto-generated setting for eth0 in /etc/network/interfaces, I realized that slirp had assigned an IP address for my laptop, as seen from the coLinux end:

iface eth0 inet static
address 10.0.2.15
broadcast 10.0.2.255
netmask 255.255.255.0
gateway 10.0.2.2

The “gateway” address was the one I needed, so I could just hardcode the following in my .bashrc:

export DISPLAY=10.0.2.2:0.0

Xming is said to be a lighter and better X-Windows server than Cygwin X, so I set out to change. No major issues, except that I had a very hard time figuring out how to get it do display Swedish characters. I’d suffered this in the coLinux console too, but that was ok, since I intended to jump into X as soon as possible.

Fixing the language support in the console was … uhm, not so easy, but I’ll attribute that to my being sorely out of practice on linux admin chores. Googling indicated that the cure was

apt-get install locales
dpkg-reconfigure locales
apt-get install console-data
dpkg-reconfigure console-data

Close, but no cigar. I also had to do
apt-get install kbd

Now, I had Swedish characters in the console, but not in X. Finally, I found this post (in Swedish), suggesting that it’s a bug in Xming’s definition of the Swedish layout. Specifying Finnish layout instead solved the problem.

The command line for Xming now looks like this:

exec0="c:\Program Files\Xming\Xming.exe -multiwindow -clipboard -silent-dup-error -xkbmodel pc105 -xkblayout fi"

I also switched to PulseAudio. Following the instructions on the coLinux wiki worked for me.

I also tried setting the environment variable COLINUX_NO_SMP_WORKAROUND=Y, to get coLinux to use both cores. I was disappointed to see that erl -smp still only saw one CPU. Apparently, coLinux makes internal use of SMP, but makes it look like a single-core system for the linux applications. My win32 version of Erlang does see both CPUs, though.

Also, it seems as if erlang under coLinux suffers from the same problem as under Win32 - erlang:now() doesn’t have sufficient resolution:

Eshell V5.6.4 (abort with ^G)
1> [erlang:now() || _ <- lists:seq(1,10)].
[{1224,77892,229402},
{1224,77892,229403},
{1224,77892,229404},
{1224,77892,229405},
{1224,77892,229406},
{1224,77892,229407},
{1224,77892,229408},
{1224,77892,229409},
{1224,77892,229410},
{1224,77892,229411}]

Note how it increments by 1 usec each time? On my other laptop running Ubuntu, the diff is ca 12 usec between each (by definition, erlang:now() always steps up at least 1 usec). I wish I could say that my Vista laptop is ~10x faster, but that’s not it. Apparently, coLinux doesn’t offer a gethrtime(). gethrvtime() also seems to be missing, and configure reports clock_gettime() as “not stable”. No disaster, perhaps, but a good erlang:now() is often useful.