Luca's meaningless thoughts  

This is just a quick fix for yesterday's release. Now mutt-nntp depends on mutt >= 1.5.21-5. This should allow having mutt-nntp installed with the standard distribution mutt package for both Debian and Ubuntu (please report any problems).

If you have Ubuntu 12.04 (Precise) and amd64 or i386 arch, just download and install the provided packages.

For other setups, here are the quick (copy&paste) instructions:

ver=1.5.21
deb_ver=$ver-5nntp3
url=https://llucax.com.nyud.net/proj/mutt-nntp-debian/files/latest
wget $url/mutt_$deb_ver.dsc $url/mutt_$deb_ver.diff.gz \
   http://ftp.de.debian.org/debian/pool/main/m/mutt/mutt_$ver.orig.tar.gz
sudo apt-get build-dep mutt
dpkg-source -x mutt_$deb_ver.dsc
cd mutt-$ver
dpkg-buildpackage -rfakeroot
# install any missing packages reported by dpkg-buildpackage and try again
cd ..
sudo dpkg -i mutt-nntp_${deb_ver}_*.deb

Now you can enjoy reading your favourite newsgroups and your favourite mailing lists via Gmane with Mutt without leaving the beauty of your packaging system. No need to thank me, I'm glad to be helpful (but if you want to make a donation, just let me know ;).

See the project page for more details.

A new version of Mutt with NNTP support is available. This version only moves Mutt with NNTP support to a separate package in the hopes of having a smoother interaction with the distribution packages (avoiding automatic updates with less hassle). Now a new mutt-nntp package is generated.

If you have Ubuntu 12.04 (Precise) and amd64 or i386 arch, just download and install the provided packages.

For other setups, here are the quick (copy&paste) instructions:

ver=1.5.21
deb_ver=$ver-5nntp2
url=https://llucax.com.nyud.net/proj/mutt-nntp-debian/files/latest
wget $url/mutt_$deb_ver.dsc $url/mutt_$deb_ver.diff.gz \
   http://ftp.de.debian.org/debian/pool/main/m/mutt/mutt_$ver.orig.tar.gz
sudo apt-get build-dep mutt
dpkg-source -x mutt_$deb_ver.dsc
cd mutt-$ver
dpkg-buildpackage -rfakeroot
# install any missing packages reported by dpkg-buildpackage and try again
cd ..
sudo dpkg -i mutt-nntp_${deb_ver}_*.deb

Now you can enjoy reading your favourite newsgroups and your favourite mailing lists via Gmane with Mutt without leaving the beauty of your packaging system. No need to thank me, I'm glad to be helpful (but if you want to make a donation, just let me know ;).

See the project page for more details.

I've updated my Mutt Debian package with the NNTP patch to the latest Debian Mutt package.

This release is to bring just the regular bugfixing round from Debian.

If you have Debian testing/unstable and amd64 or i386 arch, just download and install the provided packages.

For other setups, here are the quick (copy&paste) instructions:

ver=1.5.21
deb_ver=$ver-5nntp1
url=https://llucax.com.nyud.net/proj/mutt-nntp-debian/files/latest
wget $url/mutt_$deb_ver.dsc $url/mutt_$deb_ver.diff.gz \
   http://ftp.de.debian.org/debian/pool/main/m/mutt/mutt_$ver.orig.tar.gz
sudo apt-get build-dep mutt
dpkg-source -x mutt_$deb_ver.dsc
cd mutt-$ver
dpkg-buildpackage -rfakeroot
# install any missing packages reported by dpkg-buildpackage and try again
cd ..
sudo dpkg -i mutt_${deb_ver}_*.deb mutt-patched_${deb_ver}_*.deb

See the project page for more details.

I've updated my Mutt Debian package with the NNTP patch to the latest Debian Mutt package.

If you have downloaded the previous version, you probably noted an extremely annoying bug, which is fixed in this new package, so I'm sure you want to upgrade =)

If you have Debian testing/unstable and amd64 or i386 arch, just download and install the provided packages.

For other setups, here are the quick (copy&paste) instructions:

ver=1.5.21
deb_ver=$ver-4nntp1
url=https://llucax.com.nyud.net/proj/mutt-nntp-debian/files/latest
wget $url/mutt_$deb_ver.dsc $url/mutt_$deb_ver.diff.gz \
   http://ftp.de.debian.org/debian/pool/main/m/mutt/mutt_$ver.orig.tar.gz
sudo apt-get build-dep mutt
dpkg-source -x mutt_$deb_ver.dsc
cd mutt-$ver
dpkg-buildpackage -rfakeroot
# install any missing packages reported by dpkg-buildpackage and try again
cd ..
sudo dpkg -i mutt_${deb_ver}_*.deb mutt-patched_${deb_ver}_*.deb

See the project page for more details.

Yai! Finally my CDGC patches has been applied to Tango [1] [2] [3]. CDGC will not be the default Tango GC for now, because it needs some real testing first (and fixing a race when using weak references). So, please, please, do try it, is as simple as compiling from the sources adding a new option to bob: -g=cdgc and then manually installing Tango.

Please, don't forget to report any bugs or problems.

Thanks!

I've updated my Mutt Debian package with the NNTP patch to the latest Debian Mutt package.

A couple of extra news:

• I added a new Git repository so you can download the sources via Git.
• The Debian revision is renamed to NnntpM (instead of the old NlucaM).

If you have Debian testing/unstable and amd64 or i386 arch, just download and install the provided packages.

For other setups, here are the quick (copy&paste) instructions:

ver=1.5.21
deb_ver=$ver-2nntp1
url=https://llucax.com.nyud.net/proj/mutt-nntp-debian/files/latest
wget $url/mutt_$deb_ver.dsc $url/mutt_$deb_ver.diff.gz \
   http://ftp.de.debian.org/debian/pool/main/m/mutt/mutt_$ver.orig.tar.gz
sudo apt-get build-dep mutt
dpkg-source -x mutt_$deb_ver.dsc
cd mutt-$ver
dpkg-buildpackage -rfakeroot
# install any missing packages reported by dpkg-buildpackage and try again
cd ..
sudo dpkg -i mutt_${deb_ver}_*.deb mutt-patched_${deb_ver}_*.deb

See the project page for more details.

I've posted a small set of patches to integrate CDGC into Tango. If you want to try them out, just follow the simple 3 steps described in the ticket.

Please, let me know how it went if you do.

Here are some details on how to try CDGC, as it needs a very particular setup, specially due to DMD not having precise heap scanning integrated yet.

Here are the steps (in some kind of literate scripting, you can copy&paste to a console ;)

# You probably want to do all this mess in some subdirectory :)
mkdir cdgc-test
cd cdgc-test

# First, checkout the repositories.
git clone git://git.llucax.com/software/dgc/cdgc.git
# If you have problems with git:// URLs, try HTTP:
# git clone https://git.llucax.com/r/software/dgc/cdgc.git
svn co http://svn.dsource.org/projects/tango/tags/releases/0.99.9 tango

# DMD doesn't care much (as usual) about tags, so you have to use -r to
# checkout the 1.063 revision (you might be good with the latest revision
# too).
svn co -r613 http://svn.dsource.org/projects/dmd/branches/dmd-1.x dmd

# Now we have to do some patching, let's start with Tango (only patch 3 is
# *really* necessary, but the others won't hurt).
cd tango
for p in 0001-Fixes-to-be-able-to-parse-the-code-with-Dil.patch \
         0002-Use-the-mutexattr-when-initializing-the-mutex.patch \
         0003-Add-precise-heap-scanning-support.patch \
         0004-Use-the-right-attributes-when-appending-to-an-empty-.patch
do
   wget -O- "https://llucax.com/blog/posts/2010/10/10-trying-cdgc-howto/$p" |
         patch -p1
done
cd ..

# Now let's go to DMD
cd dmd
p=0001-Create-pointer-map-bitmask-to-allow-precise-heap-sca.patch
wget -O- "https://llucax.com/blog/posts/2010/10/10-trying-cdgc-howto/$p" |
      patch -p1

# Since we are in the DMD repo, let's compile it (you may want to add -jN if
# you have N CPUs to speed up things a little).
make -C src -f linux.mak
cd ..

# Good, now we have to wire Tango and CDGC together, just create a symbolic
# link:
cd tango
ln -s ../../../../../cdgc/rt/gc/cdgc tango/core/rt/gc/

# Since I don't know very well the Tango build system, I did a Makefile of my
# own to compile it, so just grab it and compile Tango with it. It will use
# the DMD you just compiled and will compile CDGC by default (you can change
# it via the GC Make variable, for example: make GC=basic to compile Tango
# with the basic GC). The library will be written to obj/libtango-$GC.a, so
# you can have both CDGB and the basic collector easily at hand):
wget https://llucax.com/blog/posts/2010/10/10-trying-cdgc-howto/Makefile
make # Again add -jN if you have N CPUs to make a little faster

# Now all you need now is a decent dmd.conf to put it all together:
cd ..
echo "[Environment]" > dmd/src/dmd.conf
echo -n "DFLAGS=-I$PWD/tango -L-L$PWD/tango/obj " >> dmd/src/dmd.conf
echo -n "-defaultlib=tango-cdgc " >> dmd/src/dmd.conf
echo "-debuglib=tango-cdgc -version=Tango" >> dmd/src/dmd.conf

# Finally, try a Hello World:
cat <<EOT > hello.d
import  tango.io.Console;

void main()
{
   Cout("Hello, World").newline;
}
EOT
dmd/src/dmd -run hello.d

# If you don't trust me and you want to be completely sure you have CDGC
# running, try the collect_stats_file option to generate a log of the
# collections:
D_GC_OPTS=collect_stats_file=log dmd/src/dmd -run hello.d
cat log

Done!

If you want to make this DMD the default, just add dmd/src to the PATH environment variable or do a proper installation ;)

Let me know if you hit any problem...

Yaii! My beep will be back in the next kernel release :)

This is a note to let you know that I've just added the patch titled

    ALSA: hda - Add PC-beep whitelist for an Intel board

to the 2.6.35-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
    ../tmp/alsa-hda-add-pc-beep-whitelist-for-an-intel-board.patch
and it can be found in the queue-2.6.35 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@kernel.org> know about it.


>From e096c8e6d5ed965f346d94befbbec2275dde3621 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Tue, 3 Aug 2010 17:20:35 +0200
Subject: ALSA: hda - Add PC-beep whitelist for an Intel board

From: Takashi Iwai <tiwai@suse.de>

commit e096c8e6d5ed965f346d94befbbec2275dde3621 upstream.

An Intel board needs a white-list entry to enable PC-beep.
Otherwise the driver misdetects (due to bogus BIOS info) and ignores
the PC-beep on 2.6.35.

Reported-and-tested-by: Leandro Lucarella <luca@llucax.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 sound/pci/hda/patch_realtek.c |    1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5183,6 +5183,7 @@ static void fillup_priv_adc_nids(struct

 static struct snd_pci_quirk beep_white_list[] = {
        SND_PCI_QUIRK(0x1043, 0x829f, "ASUS", 1),
+       SND_PCI_QUIRK(0x8086, 0xd613, "Intel", 1),
        {}
 };



Patches currently in stable-queue which might be from tiwai@suse.de are

queue-2.6.35/alsa-hda-add-pc-beep-whitelist-for-an-intel-board.patch

If you feel it should not be added to the stable tree, and let <stable@kernel.org> know about it, I kill you!.

I've updated my Mutt Debian package with the NNTP patch to the latest Debian Mutt package.

If you have Debian testing/unstable and amd64 or i386 arch, just download and install the provided packages.

For other setups, here are the quick (copy&paste) instructions:

ver=1.5.20
deb_ver=$ver-8luca1
url=https://llucax.com.nyud.net/proj/mutt-nntp-debian/files/latest
wget $url/mutt_$deb_ver.dsc $url/mutt_$deb_ver.diff.gz \
   http://ftp.de.debian.org/debian/pool/main/m/mutt/mutt_$ver.orig.tar.gz
sudo apt-get build-dep mutt
dpkg-source -x mutt_$deb_ver.dsc
cd mutt-$ver
dpkg-buildpackage -rfakeroot
# install any missing packages reported by dpkg-buildpackage and try again
cd ..
sudo dpkg -i mutt_${deb_ver}_*.deb mutt-patched_${deb_ver}_*.deb

See the project page for more details.

Greate news! I think I can say now that GDB will support the D programming language soon (basically name demangling and pretty-printing some data types, like strings and dynamic arrays; if you're looking for the D extension to DWARF, you'll have to wait a little longer for that).

The D support patch was started by John Demme a long time ago, and finished by Mihail Zenkov, who was in charge of merging the patch to the current development branch of GDB and going through the review process.

In the words of Joel Brobecker:

The patch is approved (good job!).

I hope the patch is committed soon, so we can have it in the next GDB release.

Congratulations and thanks to all the people involved in both the patch itself and the review process.

After some repetitive discussions about how to improve error messages (usually inspired by clang), it looks like now the DMD frontend can suggest the correct symbol name when you have a typo =)

I've updated my Mutt Debian package with the NNTP patch to the latest Debian Mutt package. I've put up a small home page for the project too, so it's easier to find.

I'll post new releases here anyway, so stay tuned =)

Some time ago I wrote a partial patch to fix DMD's issue 3420:

Allow string import of files using subdirectories

const data = import("dir/data.txt");

Specifying -J. for DMD 1.041 is sufficient to allow this to compile.

I couldn't find an option for DMD 1.042 and newer which would allow this to compile.

It's a partial patch because it's implemented only for Posix OSs. The patch passed unnoticed until changeset 389, when the restrictions on string imports became even more evident, and I commented the issue in the DMD internals ML. Fortunately Walter accepted the patch; well accept might be a very strong word, since Walter never really accepts a patch, he always write a new patch based on the submitted one, don't even dream on getting some feedback about it.

But well, that's how he works. At least now in Posix (he said he didn't find a way to do this in Windows) there are no silly restrictions on string imports, without sacrificing security =)

Motivated by a couple of long waited forward references bug fixes in the DMD front-end, I decided to experiment merging it into LDC.

The task wasn't so hard, just apply the patches, ignore changes to the back-end (mostly), resolve some conflicts and you're done!

Christian Kamm kindly helped me with a couple of doubts when resolving conflicts and I got commit access to the LDC repository in the way (thanks for the vote of confidence, even when LDC are very relaxed when giving commit access :).

However I found a changeset that was a little harder to merge: r251, which added support for appending dchar to a char[] (fixing bug 111, another long waited one). The problem was, 2 new runtime functions were added (_d_arrayappendcd and arrayappendwdarrayappendwd) but I didn't know how to tell the back-end about them.

Trying to compile Dil with the new LDC with the DMD 1.055 front-end, I discovered this change also added a regression. So I tried to fix those two issues before pushing my patches, but Christian told me I should push them first and fix the problems later. I really prefer the other way around, but I won't tell the LDC developers how to run the project :), so I did it [*].

Christian disabled the new feature later because Tango is still lacking the new runtime functions, so LDC can't do much about them yet. I filled a bug so this issue don't get lost.

I would be nice to have some feedback if you try the new merged front-end in LDC :)

D has a very nice capability of string imports. A string import let you read a file at compile time as a string, for example:

pragma(msg, import("hello.txt"));

Will print the contents of the file hello.txt when it's compiled, or it will fail to compile if hello.txt is not readable or the -J option is not used. The -J option is needed because of security reasons, otherwise compiling a program could end up reading any file in your filesystem (storing it in the binary and possibly violating your privacy). For example you could compile a program as root and run it as an unprivileged user thinking it can't possibly read some protected data, but that data could be read at compile-time, with root privileges.

Anyway, D ask you to use the -J option if you are doing string imports, which seems reasonable. What doesn't look so reasonable is that string imports can't access a file in a subdirectory. Let's say we have a file test.d in the current directory like this:

immutable s = import("data/hello.txt");

And in the current directory we have a subdirectory called data and a file hello.txt in it. This won't compile, ever (no matter what -J option you use). I think this is an unnecessary limitation, using -J. should work. I can see why this was done like that, what if you write:

immutable s = import("../hello.txt");

It looks like this shouldn't work, so we can ban .. from string imports, but what about this:

immutable s = import("data/../data/hello.txt");

This should work, it's a little convoluted but it should work. And what about symbolic links?

Well, I think this limitation can be relaxed (other people think that too, there is even a bug report for this), at least on POSIX-compatible OSs, because we can use the realpath() function to resolve the file. If you resolve both the -J directories and the resulting files, it's very easy to check if the string import file really belongs to a -J subdirectory or not.

This looks very trivial to implement, so I gave it a shot and posted a patch and a couple of test cases to that very same bug report :)

The patch is incomplete, though, because it's only tested on Linux and it lacks Windows support (I don't know how to do this on Windows and don't have an environment to test it). If you like this feature and you know Windows, please complete the patch, so it has better chances to make it in D2, you only have to implement the canonicalName() function. If you have other supported POSIX OS, please test the patch and report any problems.

Thanks!

From time to time, people suggested features to make easier to add some dynamic capabilities to D. One of the suggestions was adding a way to have dynamic members. This is specially useful for things like ORMs or RPCs, so you can do something like:

auto rpc = new RPC;
rpc.foo(5);

And it get automatically translated to some sort of SQL query or RPC call, using some kind of introspection at runtime. To enable this, you can translate the former to something like:

obj.dispatch!("foo")(5);

There was even a patch for this feature, but Walter didn't payed much attention and ignore this feature until a couple of days ago, when he got bored and implement it himself, on its own way =P

I think this is a very bad policy, because it discourages people to contribute code. There is no much difference between suggesting a feature and implementing it providing a patch, unless you have a very good personal relationship with Walter. You almost never will have feedback on your patch, Walter prefers to implement things himself instead of giving you feedback. This way it's very hard for people wanting to contribute to learn about the code and on how Walter wants patches to be done; and this is what discourages contributions.

I won't write again about what are the problems in the D development model, I already done that without much success (except for Andrei, who is writing better commit messages now, thanks for that! =). I just wanted to point out another thing that Walter don't get about open-source projects.

Anyway, this post is about opDispatch(), the new way of doing dynamic dispatching. Walter proposed opDynamic(), which was wrong, because it's not really dynamic, it's completely static, but it enables dynamic dispatching with a little extra work. Fortunately Michel Fortin suggested opDispatch() which is a better name.

The thing is simple, if a method m() is not found, a call to opDispatch!("m")() is tried. Since this is a template call, its a compile-time feature, but you can easily do a dynamic lookup like this:

void opDispatch(string name)(int x)
{
    this.dispatch(name, x);
}

void dispatch(string name, int x)
{
    // dynamic lookup
}

I personally like this feature, we'll see how all this turns out.

Removing switch fall-through from D's switch statement is something discussed since the early beginnings of D, there are discussions about it since 2001 and to the date [*]. If you don't know what I'm talking about, see this example:

switch (x) {
case A:
    i = x;
    // fall-through
case B:
    j = 2;
    break;
case C:
    i = x + 1;
    break;
}

If you read carefully the case B case A code, it doesn't include a break statement, so if x == A not only i = x will be executed, the code in case B will be executed too. This is perfectly valid code, introduced by C, but it tends to be very error prone and if you forget a break statement, the introduced bug can be very hard to track.

Fall-through if fairly rare, and it would make perfect sense to make it explicit. Several suggestions were made in this time to make fall-through explicit, but nothing materialized yet. Here are the most frequently suggested solutions:

• Add a new syntax for non-fall-through switch statements, for example:

  switch (x) {
  case A {
      i = x;
  }
  case B {
      j = 2;
  }
  case C {
      i = x + 1;
  }
  

• Don't fall-through by default, use an explicit statement to ask for fall-through, for example:

  switch (x) {
  case A:
      i = x;
      goto case;
  case B:
      j = 2;
      break;
  case C:
      i = x + 1;
      break;
  }
  

  Others suggested continue switch or fallthrough, but I think some of this suggestions were made before goto case was implemented.

A few minutes ago, Chad Joan has filled a bug with this issue, but with a patch attached 8-). He opted for an intermediate solution, more in the lines of new switch syntax. He defines 2 case statements: case X: and case X!: (note the !). The former doesn't allow implicit fall-through and the latter does. This is the example in the bug report:

switch (i)
{
    case 1!: // Intent to use fall through behavior.
        x = 3;
    case 2!: // It's OK to decide to not actually fall through.
        x = 4;
        break;

    case 3,4,5:
        x = 5;
        break;

    case 6: // Error: You either forgot a break; or need to use !: instead of :
    case 7: // Fine, ends with goto case.
        goto case 1;

    case 8:
        break;
        x = 6; // Error: break; must be the last statement for case 8.
}

While I really think the best solution is to just make a goto case required if you want to fall-through [†], it's great to have a patch for a solution. Thanks Chad! =)

Did you ever wanted Mutt with NNTP support packed up for your Debian (or Debian-ish) box, but you are too lazy to do it yourself? Did you even tried to report a bug so the patch can be applied to the official Debian package but the maintainers told you they wont do it?

If so, this is a great day for you, because I did it and I'm giving it away with no charge in this one time only opportunity!!! =P

Seriously, I can understand why the maintainers don't want to support it officially, it a big patch and can be some work to fold it in. So I did it myself, and it turned out it's wasn't that bad.

I adjusted the patch maintained by Vsevolod Volkov to work on top of all the other patches included in the mutt-patched Debian package (the only conflicting patch is the sidebar patch and some files that doesn't exist because the patch should be applied after autotools files are generated and Debian apply the patches before that) and built the package using the latest Debian source (1.5.20-4).

You can find the source package and the binary packages for Debian unstable i386 here. You can find there the modified NNTP patch too.

If you have Ubuntu or other Debian based distribution, you can compile the binary package by downloading the files mutt_1.5.20-4luca1.diff.gz, mutt_1.5.20-4luca1.dsc and mutt_1.5.20.orig.tar.gz, then run:

$ sudo apt-get build-dep mutt
$ dpkg-source -x mutt_1.5.20-4luca1.dsc
$ cd mutt-1.5.20
$ dpkg-buildpackage -rfakeroot
$ cd ..
$ sudo dpkg -i mutt_1.5.20-4luca1_i386.deb \
        mutt-patched_1.5.20-4luca1_i386.deb

Now you can enjoy reading the D newsgroups and your favourite mailing lists via Gmane with Mutt without leaving the beauty of your packaging system. No need to thank me, I'm glad to be helpful ;)

I haven't been posting very often lately because I decided to spend some time writing my thesis document (in Spanish), which was way behind my current status, encouraged by my code-wise bad weekend =P.

Alberto Bertogli was kind enough to review my Naive GC implementation and sent me some patches, improving the documentation (amending my tarzanesque English =) and fixing a couple of (nasty) bugs [1] [2].

I'm starting to go back to the code, being that LDC is very close to a new release and things are starting to settle a little, so I hope I can finish the statistics gathering soon.

I have to be honest on this one. I'm not crazy about the druntime build system. I know there are a lot of other more important thing to work on, but I can't help myself, and if I'm not comfortable with the build system, I get too much distracted, so I have no choice but to try to improve it a little =)

First, I don't like the HOME environment variable override hack in build-dmd.sh (I won't talk about the Windows build because I don't have Windows, so I can't test it).

So I've made a simple patch to tackle this. It just adds a dmd.conf configuration file in each directory owning a makefile. I think it's a fair price to pay adding this extra files to be hable to just use make and get rid of the build-dmd.sh script.

I've added a ticket on this and another related ticket with a patch too.

I've been reading the source code of the druntime, and it's time to get my hands dirty and do some real work.

First I have to do to start hacking it is build it and start trying things out. There is no documentation at all yet, so I finally bothered Sean Kelly and asked him how to get started.

Here is what I had to do to get druntime compiled:

First of all, I'll introduce my environment and tools. I'll use DMD because there's no other option for now (druntime doesn't have support for GDC, but Sean says it's coming soon, and LDC will not be included until the support it's added to Tango runtime).

The trunk in the druntime repository is for D2, but there is a branch for D1 too.

I use Debian (so you'll see some apt stuff here) and I love git, and there's is no way I will go back to subversion. Fortunately there is git-svn, so that's what I'm gonna use =)

Now, what I did step by step.

1. Get the git goodies:

   sudo aptitude install git-core git-svn
   

2. Make a directory where to put all the D-related stuff:

   mkdir ~/d
   cd ~/d
   

3. Get D2 (bleeding edge version) and unpack it:

   wget http://ftp.digitalmars.com/dmd.2.026.zip
   unzip dmd.2.020.zip # "install" the D2 compiler
   rm -fr dm dmd/linux/bin/{sc.ini,readme.txt,*.{exe,dll,hlp}} # cut the fat
   chmod a+x dmd/linux/bin/{dmd,rdmd,dumpobj,obj2asm} # make binaries executable
   mv dmd dmd2 # reserve the dmd directory for D1 compiler
   

4. Make it accessible, for example:

   echo '#!/bin/sh' > ~/bin/dmd2 # reserve dmd name for the D1 compiler
   echo 'exec ~/d/dmd2/linux/bin/dmd "$@"' >> ~/bin/dmd2
   chmod a+x ~/bin/dmd2
   

5. Get D1 and install it too:

   wget http://ftp.digitalmars.com/dmd.1.041.zip
   unzip dmd.1.036.zip
   rm -fr dm dmd/linux/bin/{sc.ini,readme.txt,*.{exe,dll,hlp}}
   chmod a+x dmd/linux/bin/{dmd,rdmd,dumpobj,obj2asm}
   echo '#!/bin/sh' > ~/bin/dmd
   echo 'exec ~/d/dmd/linux/bin/dmd "$@"' >> ~/bin/dmd
   chmod a+x ~/bin/dmd
   

6. Get druntime for D1 and D2 as separated repositories (you can get all in one git repository using git branches but since I'll work on both at the same time I prefer to use two separated repositories):

   git svn clone http://svn.dsource.org/projects/druntime/branches/D1.0 \
     druntime
   git svn clone http://svn.dsource.org/projects/druntime/trunk druntime2
   

7. Build druntime for D1:

   cd druntime
   bash build-dmd.sh
   cd -
   

8. Build druntime for D2.

   This one is a little trickier. The trunk version have some changes for a feature that is not yet released (this being changed from a pointer to a reference for structs). Fortunately this is well isolated in a single commit, so reverting this change is really easy, first, get the abbreviated hash for the commit 44:

   cd druntime2
   git log --grep='trunk@44' --pretty=format:%h
   

   This should give you a small string (mine is cae2326). Now, revert that change:

   git revert cae2326
   

   Done! You now have that change reverted, we can remove this new commit later when the new version of DMD that implements the this change appear.

   But this is not all. Then I find a problem about redefining the Posix version:

   Error: version identifier 'Posix' is reserved and cannot be set
   

   To fix this you just have to remove the -version=Posix from build-dmd.sh.

   But there is still one more problem, but this is because I have renamed the bianries to have both dmd and dmd2. The compiler we have to use to build things is called dmd2 for me, but build-dmd.sh don't override properly the DC environment variable when calling make, so dmd is used instead.

   This is a simple and quick fix:

   diff --git a/src/build-dmd.sh b/src/build-dmd.sh
   old mode 100644
   new mode 100755
   index d6be599..8f3b163
   --- a/src/build-dmd.sh
   +++ b/src/build-dmd.sh
   @@ -11,9 +11,10 @@ goerror(){
        exit 1
    }
   
   -make clean -fdmd-posix.mak           || goerror
   -make lib doc install -fdmd-posix.mak || goerror
   -make clean -fdmd-posix.mak           || goerror
   +test -z "$DC" && DC=dmd
   +make DC=$DC clean -fdmd-posix.mak           || goerror
   +make DC=$DC lib doc install -fdmd-posix.mak || goerror
   +make DC=$DC clean -fdmd-posix.mak           || goerror
    chmod 644 ../import/*.di             || goerror
   
    export HOME=$OLDHOME
   

   (to apply the patch just copy&paste it to fix.patch and then do git apply fix.patch; that should do the trick)

   Now you can do something like this to build druntime for D2:

   export DC=dmd2
   bash build-dmd.sh
   

That's it for now. I'll be publishing my druntime (git) repository soon with this changes (and probably submitting some patches to upstream) so stay tuned ;)