Today, I have been finally able to fix a bug which had already taken my some hours to trace down. Basically, mouse-over and -off events would not work properly on certain MovieClips. After some digging through my custom code managing these events (which I needed to come up with because there is no way to let hover events bubble up the display hierarchy in ActionScript 2), I found that hitTest() wouldn’t work properly on these clips.

Now the fun part began. I meticulously checked every aspect of the MovieClips for anything special, I even considered that it might have something to do with the fact that they were positioned right behind some TextFields, which could have triggered some Flash player bugs (given that they are already surrounded by a cloud of weirdness in AS2). Nope, nothing.

It wasn’t until I had already pretty much given up that I noticed that the name of the clips in question contained a period. After I removed it … hitTest() worked fine – thanks a lot for wasting my time, Adobe! Not only that this really should not happen, at least not without a runtime warning, the fact that you cannot use periods in MovieClip names is apparently undocumented.

Oh well…

The text was written by Scott Meyers almost ten years ago, but in my eyes, it is still a very good read on the topic. Highly recommended!

However, all of these issues, as annoying as they may be, do not pose a serious problem, they can all be worked around. But there is another one, and it has seven letters: OPTLINK. OPTLINK, courtesy of Digital Mars, is the linker which comes with DMD. There are quite a number of issues with it:

First, it is proprietary closed-source software. Apart from some people’s idealistic worries, this is also a serious problem to more pragmatically coders because there are no alternatives for OMF, at least no decent ones. This means that if you stumble upon a bug, you can do nothing more than to wait for Walter Bright to fix it.

Second, even if the source code was available, it would probably still be hard to fix bugs, since, according to Walter himself, large parts are written in really complex outstandingly smart assembler – a maintainer’s nightmare. This might also explain why it took him so long to fix some serious bugs in the past…

Third, there are bugs. Lots of bugs, compared to other linkers and with the pretty high version number (8.00.2) in mind. If you want to know what I am talking about, just search the D newsgroups; projects which make extensive use of templates seem to be affected more often than others. Until yesterday, I personally had been spared from this kind of issues, but the OPTLINK bug I encountered yesterday almost drove me crazy, because it is just plain … stupid:

After I had worked quite some time on Linux exclusively, I needed to compile a Windows version of a project of mine. So I went ahead and rebooted, updated DMD, Tango and a few other tools. Everything worked fine, the project even built fine, until I needed to build debug symbols into the binary. Every time I just added the -g flag to the compiler invocation, OPTLINK would abort with »Error 118: Filename Expected«. Because I had also upgraded my build tool, my first thought was that the linker commands could really be broken, but on closer inspection, it turned out that the invocation was generated perfectly fine. So I went on and downgraded all of the tools again, but to no avail – again the same error, although debug builds had worked flawlessly in the past.

After having searched for about an hour, I finally found the cause, and I could not really believe it at first: Compared to my previous D/Windows setup, I had added the Notepad++ installation directory to my PATH. You might ask yourself now, »Um, what? How should that break the linker?« Well, it turned out that OPTLINK apparently has problems with handling plus signs in all the lookup paths it uses, including not only the ones passed at the command line, but also those from the environment variables.

I was really tempted to just drop DMD altogether, but unfortunately, there currently is no other D compiler of comparable quality for Windows. After my anger about this went away (you become quite fast at relaxing after you work with D for a while, I suppose), one question remains: If Walter wants D to become popular, why does he ignore widely used standards (read: COFF) for the reference compilers? Being able to easily switch out OPTLINK would really help, since the maturity of the tool-chain is the number one problem of D, at least in my opinion.

However, there has been an effort started to resurrect GDC recently. Development takes place over at bitbucket (you can also find building instructions for GDC there) and the project has been able to celebrate some first success: The reasonably recent front-end versions 1.040 and 2.015 (for D2) are working with GCC 4.3. This seemed enough of a sign of life for me to decide to give GDC another try. After some initial problems (some of which resulted from bugs which have already been fixed in the official Mercurial repository) I managed to compile a GDC binary (frontend version 1.040 against GCC 4.3.1) which happily compiles the Tango standard library and a personal project of mine. This is what I did (silently omitting quite a few hours of searching and fixing bugs):

First, go to some temporary directory and checkout the GDC sources from the Mercurial repository (at the time of writing, revision 53 was current):

cd ~/tmp
hg clone http://bitbucket.org/goshawk/gdc

Then, download the core of GCC 4.3.1 from a mirror near you (version 4.3.2 should also work, but builds against 4.3.4 are currently known to be broken) and extract it inside the GDC sources:

wget ftp://gd.tuwien.ac.at/gnu/gcc/releases/gcc-4.3.1/gcc-core-4.3.1.tar.bz2
mkdir gdc/dev
cd gdc/dev
tar xjvf ../../gcc-core-4.3.1.tar.bz2

Now, link the GDC sources into the extracted directory and use the provided setup-gcc.sh script to patch GCC to enable D version 1:

cd gcc-4.3.4
ln -s ../../../d gcc/d
gcc/d/setup-gcc.sh --d-language-version=1

After that, you are ready to build and install GCC with D support. For this, go to some build directory and configure and make. You can, of course, choose an arbitrary directory for the build files (for instance, I personally prefer having the build files completely outside the source direcotry):

mkdir build
cd build
../configure --enable-languages=d --disable-multilib --disable-shared --prefix=/opt/gdc
make
sudo make install

Note that I configured GCC/GDC to be installed in /opt/gdc. As the build also includes the C compiler, this avoids any interference with the »normal« GCC installed probably in /usr. After the build has finished – this takes quite long, since GCC is built three times to bootstrap itself – you should have a working GDC executable in /opt/gdc/bin. Now for the second part, Tango:

Start off by fetching the Tango sources from the SVN to a temporary working directory (I worked with revision 5023):

cd ~/tmp
svn co http://svn.dsource.org/projects/tango/trunk tango

Unfortunately, Tango currently does not compile with GDC out of the box, you have to apply a couple of minor changes: The first change adds build/arch files for GDC/Linux:

diff --git a/build/arch/linux-i686-gdc-dbg.mak b/build/arch/linux-i686-gdc-dbg.mak
--- /dev/null
+++ b/build/arch/linux-i686-gdc-dbg.mak
@@ -0,0 +1,6 @@
+include $(ARCHDIR)/gdc.rules
+include $(ARCHDIR)/linux.inc
+
+# -Wall breaks the compilation with wrong errors
+DFLAGS_COMP=-g
+CFLAGS_COMP=-g

diff --git a/build/arch/linux-i686-gdc-opt.mak b/build/arch/linux-i686-gdc-opt.mak
--- /dev/null
+++ b/build/arch/linux-i686-gdc-opt.mak
@@ -0,0 +1,5 @@
+include $(ARCHDIR)/gdc.rules
+include $(ARCHDIR)/linux.inc
+
+DFLAGS_COMP=-O2
+CFLAGS_COMP=-O2

diff --git a/build/arch/linux-i686-gdc-tst.mak b/build/arch/linux-i686-gdc-tst.mak
--- /dev/null
+++ b/build/arch/linux-i686-gdc-tst.mak
@@ -0,0 +1,5 @@
+include $(ARCHDIR)/gdc.rules
+include $(ARCHDIR)/linux.inc
+
+DFLAGS_COMP=-g -fdeprecated -fdebug=UnitTest -funittest
+CFLAGS_COMP=-g

diff --git a/runtime/compiler/gdc/Makefile.am b/runtime/compiler/gdc/Makefile.am
--- a/runtime/compiler/gdc/Makefile.am
+++ b/runtime/compiler/gdc/Makefile.am
@@ -18,7 +18,7 @@
 # AUTOMAKE_OPTIONS = 1.9.6 foreign no-dependencies

 OUR_CFLAGS=@DEFS@ -I.
-D_EXTRA_DFLAGS=-nostdinc -pipe -I../../.. -I../shared -fversion=Posix
+D_EXTRA_DFLAGS=-nostdinc -pipe -I../../.. -I../shared
 ALL_DFLAGS = $(DFLAGS) $(D_MEM_FLAGS) $(D_EXTRA_DFLAGS) $(MULTIFLAGS)

 host_alias=.
diff --git a/runtime/compiler/gdc/Makefile.in b/runtime/compiler/gdc/Makefile.in
--- a/runtime/compiler/gdc/Makefile.in
+++ b/runtime/compiler/gdc/Makefile.in
@@ -228,7 +228,7 @@ target_vendor = @target_vendor@
 top_builddir = @top_builddir@
 top_srcdir = @top_srcdir@
 OUR_CFLAGS = @DEFS@ -I.
-D_EXTRA_DFLAGS = -nostdinc -pipe -I../../.. -I../shared -fversion=Posix
+D_EXTRA_DFLAGS = -nostdinc -pipe -I../../.. -I../shared
 ALL_DFLAGS = $(DFLAGS) $(D_MEM_FLAGS) $(D_EXTRA_DFLAGS) $(MULTIFLAGS)
 toolexecdir = $(phobos_toolexecdir)
 toolexeclibdir = $(phobos_toolexeclibdir)

diff --git a/user/tango/math/internal/BiguintCore.d b/user/tango/math/internal/BiguintCore.d
--- a/user/tango/math/internal/BiguintCore.d
+++ b/user/tango/math/internal/BiguintCore.d
@@ -516,7 +516,7 @@ static BigUint pow(BigUint x, ulong y)
             }
             y0 = y/p;
             finalMultiplier = intpow(x0, y - y0*p);
-            x0 = intpow(x0, p);
+            x0 = intpow!(BigDigit)(x0, p);
         }
         xlength = 1;
     }

After you have applied these patches, you should be ready to build Tango (make sure that you have a cc somewhere in your PATH, if not, create a link to your system’s gcc):

sudo PATH=$PATH:/opt/gdc/bin DC=gdc build/build.sh --lib-install-dir /opt/gdc/lib

A quick tip for DSSS users: You probably have to modify your gdc-posix-tango profile to omit the -version=Posix switch (see above) on gdmd calls and add -L-ltango-base-gdc to the linker flags since Tango was not installed via DSSS in the above instructions.

Edit: Since I originally wrote this post, Tango’s build system was modified yet another time (at least, things are much simpler now). Instead of fiddling around with the makefiles, just use the bob tool from the build directory now which should work with GDC out of the box.

This post describes an installation routine that should provide you with a working D development environment containing DMD, LDC, Tango and DSSS on (K)Ubuntu Jaunty. Please note that it assumes your system to be »clean« – if you have already installed any D-related software, it is probably advisable to remove it completely to prevent any problems with, for instance, stale files.

mkdir -p ~/tmp
cd ~/tmp

wget http://ftp.digitalmars.com/dmd.1.050.zip
unzip dmd.1.050.zip
cd dmd/linux/bin/
chmod +x dmd dumpobj obj2asm rdmd
sudo cp dmd dmd.conf dumpobj obj2asm rdmd /usr/local/bin/

cd ~/tmp
svn co http://svn.dsource.org/projects/tango/trunk tango

cd tango/
sudo DC=dmd build/build.sh --lib-install-dir /usr/local/lib
sudo cp -rf user/object.di user/rt user/std user/tango /usr/local/include/d/

sudo su -c 'echo -e "[Environment]\nDFLAGS=-I/usr/local/include/d -defaultlib=tango-base-dmd -debuglib=tango-base-dmd -L-ltango-user-dmd -version=Tango -version=Posix" > /usr/local/bin/dmd.conf'

sudo su -c 'echo -e "# dsss\ndeb http://ppa.launchpad.net/d-language-packagers/ppa/ubuntu jaunty main" >> /etc/apt/sources.list'
sudo apt-get install dsss
sudo su -c 'echo "profile=dmd-posix-tango" > /etc/drebuild/default'

You should now be able to build your D/Tango programs with DMD and DSSS.

I would suggest giving LDC at least a short glance, a fairly young compiler project which leverages LLVM as its code generating backend. It is maturing very quickly and allows you to make use of the various features the LLVM compiler infrastructure provides, the most noticeable probably being its excellent optimization routines. Fortunately, there are current binary packages available at launchpad, so all that is needed to LDC is:

sudo su -c 'echo -e "# ldc-daily\ndeb http://ppa.launchpad.net/d-language-packagers/ppa/ubuntu karmic main\ndeb http://archive.ubuntu.com/ubuntu karmic main universe" >> /etc/apt/sources.list'
sudo apt-get update

sudo apt-get install ldc-daily libtango-ldc-daily-dev

cd ~/tmp
wget -O ldc-posix-tango http://www.dsource.org/projects/ldc/browser/ldc-posix-tango?format=raw
sudo su -c 'sed "s:ldc.rebuild.conf:/etc/ldc/ldc.rebuild.conf:"  /etc/drebuild/ldc-posix-tango'

sudo su -c 'echo "profile=ldc-posix-tango" > /etc/drebuild/default'

Note that the above commands install a daily snapshot of LDC, which I would recommend to use due to the currently fast development of LDC. In order not to break you Jaunty installation, please do not forget to comment out the official »karmic« repositories (which contain some dependencies for ldc-daily) in your /etc/apt/sources.list and run apt-get update after the installation is completed.

Both compilers are set up to use Tango, do not install Tango via DSSS! If you want to switch compilers, just activate the corresponding profile in /etc/drebuild/default and do not forget to rebuild any D libraries you might have compiled and installed with the old compiler (just run dsss net install … for the ones you installed using DSSS).

Edit: Updated instructions to work with the new folder structure of Tango’s codebase.
Edit 2: Updated instructions to install more recent dmd version.
Edit 3: Since I wrote this post, Tango received yet another big structural change to its codebase (amongst other changes, the core and user libraries have been merged). Now, you should use the supplied »bob« tool now to build tango. Additionally, Karmic is now stable so you might have to adapt the APT repository-related instructions.

The solution: Use another language setting which does not interfere with shell syntax instead, for example [sourcecode lang="css"].

I hope the WordPress.com team will fix this soon.

Edit: It seems as if the [sourcecode] tags have been fixed. However, in some of the code snippets I posted, the HTML entities for the lesser- and greater-than signs have mystically appeared in the post editor – after I removed them, the snippets are finally displayed like I want them to.

Recently, for instance, I wanted to merge an extension to the great Open Asset Import Library (bindings for the D programming language, in fact) which I developed locally in Git to the upstream repository in a way that the commit history was kept locally. However, SVN is used as SCM system for upstream development. So I started out by importing the upstream SVN repository via git-svn:

$ mkdir assimp; cd assimp
$ git svn init https://assimp.svn.sourceforge.net/svnroot/assimp/trunk
$ git svn fetch

$ git checkout -b d-bindings
$ git fetch ../dAssimp
$ git read-tree --prefix=port/dAssimp FETCH_HEAD
$ git rev-parse FETCH_HEAD > .git/MERGE_HEAD
$ git commit

As I found out later, I could have possibly done this more easy using the subtree merge strategy, but I still like, as mentioned above, Git’s feature of »just doing what you tell it to do«…

After simply trying to ignore the problem for some time, I searched and found a solution today: You have to disable the »Prevent empty clipboard« setting in Klipper’s configuration menu (which is accessible by right-clicking on the systray icon).

Intuitive? Not to me…

Edit: Disabling the mentioned option might introduce some minor glitches to general clipboard usage (sometimes, the clipboard seems to empty itself). As those occur rather infrequently, I have not been able to find out why this happens, or even if this is connected to the configuration changes described in this post.

Today, I finally had time to investigate the issue: The problem was caused by a stale .desktop file in share/kde4/services/kwin with the old name of the plugin (it was renamed from maketransparent to translucency).

I have no idea how this could happen, because I usually purge the whole /opt/kde folder everytime I svn up my qt-copy, which I happen to do quite often…

More to come soon…