Planet D

DerelictFreeGLUT

2012-05-21T13:37:52+00:00

I’ve noticed that a great many modern OpenGL tutorials are using freeglut. As such, I thought it would be a good idea to add a binding for it to Derelict3. It isn’t 100% complete. It’s missing the font type declarations at the moment, until I work out the best way to handle them. Until then, if you need the rest of it, I can say that it compiles and loads. Haven’t tested it at all yet.

dpj – A Mini-IDE for D

2012-05-20T04:24:09+00:00

I a recent post in D.announce, denewbie let it be known that dpj for Windows version 1.0 is ready for exposure to the D community. From both pages, “dpj is a mini-ide for the D programming language.” Currently, it appears to only support DMD. I hope to hear more about this one.

Binding D to C Part Three

2012-05-19T10:52:00+00:00

This is the (long overdue) third part of a series on creating bindings to C libraries for the D programming language.

In part one, I introduced the difference between dynamic and static bindings and some of the things to consider when choosing which kind to implement. In...

Derelict 3 Deb Package

2012-05-13T00:38:44+00:00

If you are a Linux user with APT on your system, you now have another option to get your hands on Derelict 3. Jordi Sayol has added it to his D-APT repository.

Voldemort Types In D

2012-05-07T23:34:00+00:00

Sometimes, the confluence of existing features can yield unexpected surprises.

vibe.d

2012-04-30T05:24:16+00:00

vibe.d was announced a few days ago and I was going to post about it then, but the site was down for a bit. Then I forgot about it. Which I shouldn’t have, because it looks like quite an awesome project.

a new framework for general I/O and especially for building
extremely fast web apps. It combines asynchronous I/O with
core.thread’s great fibers to build a convenient, blocking
API which can handle insane amounts of connections due to
the low memory and computational overhead.

It’s a young project, but already packs several features that can make web development with D a breeze. I would love to play around with it myself, but I barely have time for the projects I’m already working on. Anyone got a few extra hours per week to spare?

libgc-d version 1.0 released

2012-04-26T11:04:17+00:00

Version 1.0 of libgc-d has been released. This is a simple binding library for the libgc library. It has been tested with MCI's interpreter on Linux and OS X and should be ready for production use.

Archives can be downloaded here.

libffi-d version 1.0 released

2012-04-26T10:43:27+00:00

Version 1.0 of libffi-d has been released. This library is a wrapper around the C library libffi which is useful for dynamic invocation of native functions. Since libffi-d provides a more 'D-like' wrapper around the C library, as opposed to just being a binding, there is a certain amount of logic in libffi-d that is actually quite error-prone. Version 1.0 has been battle-tested in MCI's interpreter on Windows, Linux, and OS X.

Archives can be downloaded here.

New Bindings in Derelict 3

2012-04-17T06:45:00+00:00

Thanks to Sven-Hendrik Haase, there are two new packages in Derelict 3.

DerelictAlure is a binding to AL Utilities REtooled, a library that takes care of some common tasks when working with OpenAL.
DerelictASSIMP is a binding to the Open Asset Import library, which allows you to import, and export, 3D models from a variety of formats.

Both of these are very useful additions to Derelict.

DMD 1.074 and 2.059

2012-04-14T04:23:25+00:00

Walter has announced new versions of the DMD compilers. 1.074 is, as usual, a bug-fix release. With the end-of-support date for D1 getting ever closer, don’t expect anything major to come out of that branch.

DMD 2.059, on the other hand, is quite a sight. In addition to the numerous bug fixes, there are several new features and changes. One thing that’s going to be a pleaser to many is that Universal Function Call Syntax now applies universally. That’s something for which we’ve been waiting for quite some time.

A simple usage example of Haskell type classes and D templates

2012-04-10T23:18:55+00:00

This is a nice introduction to Haskell language:
http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way/

Near the beginning there is this simple Haskell program:

f :: Num a => a -> a -> a
f x y = x*x + y*y

main = print (f 3 2.4)

It compiles and produces the 14.76 output because:

`3` is a valid representation both for Fractional numbers like Float and for Integer. As `2.4` is a Fractional number, `3` is then interpreted as being also a Fractional number.

Despite the D language is sometimes better than C++, D templates are not Haskell type classes. This (heavily annotated) D code works (all those annotations are optional, but template constraints are often handy, also to help the compiler produce better error messages):

import std.traits;

T f(T)(in T x, in T y) pure nothrow @safe if (isNumeric!T) {
    return x ^^ 2 + y ^^ 2;
}

void main() {
    import std.stdio;
    writeln(f(2.1, 4.2));
}

But unlike in the Haskell example, D templates don't perform implicit type coercion (as it happens for normal D functions), so this code causes a compilation error:

import std.traits;

T f(T)(in T x, in T y) pure nothrow @safe if (isNumeric!T) {
    return x ^^ 2 + y ^^ 2;
}

void main() {
    import std.stdio;
    writeln(f(2, 4.2)); // does not match any function template
}

If you also want it to work with the multi-precision numbers currently defined in Phobos standard library you have to drop the "pure" and "nothrow" annotations because currently Phobos BigInt code doesn't have those qualities. And you also have to drop the "in" (that in D equals to "scope const") annotations on the input arguments because currently BigInt doesn't work well with immutability. You also need to keep in mind that isNumeric is a Phobos trait defined for built-in numbers only, so you need to add another specialization:

import std.traits, std.bigint;

T f(T)(T x, T y) if (isNumeric!T || is(T == BigInt)) {
    return x ^^ 2 + y ^^ 2;
}

void main() {
    import std.stdio;
    writeln(f(BigInt(2), BigInt(4)));
}

What if you want to use Rational numbers too or other kind of user-defined numbers? You have probably to write and use a isNumber template trait that contains actual D code that uses the basic numeric capabilities inside a __traits(compiles, {...}). Something like this for isInputRange:

template isInputRange(R) {
    enum bool isInputRange = __traits(compiles, {
        R r = void; // can define a range object
        if (r.empty) {} // can test for empty
        r.popFront(); // can invoke popFront()
        auto h = r.front; // can get the front of the range
    });
}

Such code is not hard to write, it's just a minimal list of operations you want to verify, but sometimes you need some tries to put inside it all your requirements. So here it's a good idea to write some compile-time unit tests to verify that your isNumber is working well with several types and usages. D template constraints are not the mythic C++0x Concepts, they can't verify conformance in both directions. So you usually have to write compile-time unit tests to design and write them well.

Introducing libgc-d

2012-04-06T17:07:38+00:00

We've just published libgc-d on GitHub (and it is building on the CI server as well)!

This is a bare-bones binding to the libgc library (also known as the Boehm-Demers-Weiser GC). It is a conservative garbage collector targeting applications written in languages such as C, C++, D, etc. We're using libgc-d in MCI as we now support libgc as a garbage collector option on all non-Windows platforms.

Setting Thread Affinity on Windows in D

2012-04-03T13:15:00+00:00

When working with D's standard library, it is sometimes necessary to work around missing declarations in the core.sys.windows.windows module. It's a fairly big module as is, but it isn't all-inclusive. If you are doing any heavy-duty Windows development, you'll likely want a...

Library News Roundup

2012-04-02T07:04:36+00:00

There’s been a sudden burst of announcements regarding D libraries — one native lib and three bindings. So I’ve collected them all here for your benefit. Thank me later.

First up, long-time D user Stewart Gordon, a D1 stalwart, has finally made the move to D2. That’s news in and of itself, but the reason I’m posting about it here is that it has resulted in his utility library being updated to D2. I’ve never used it, but you might find something useful there.

Daniel Kolesa has put together a binding to the Open Dynamics Engine, a rigid-body physics engine for games. Actually, he’s made two bindings. One, a static binding (meaning you can link statically or dynamically to ODE), has been created for the Deimos project. The second, a dynamic binding (meaning ODE must be loaded manually and static linking is not possible) has been ported from Derelict 2 and merged into Derelict 3.

Artur Skawina has announced an update for the native GTK bindings for D. I think the best place to send you is to the announcement itself, so you can get all the information you need before visiting the repository.

Finally, dnewbie has put together a binding for ocilib so that you can use Oracle databases from D. In my memory, this may be the first Oracle binding I’ve seen for D.

Uniform Function Call Syntax

2012-03-28T10:31:00+00:00

I have become more and more convinced that the key to code reusability and scalability is encapsulation — having subsystems communicate through small, well-defined interfaces and letting them hide their own implementation details.

Thrift now officially supports D!

2012-03-26T22:00:00+00:00

Thrift is a cross-language serialization and RPC framework, originally developed for internal use at Facebook, and now an Apache Software Foundation project. I started working on support for the D programming language during Google Summer of Code 2011, and at the end of last week, the implementation was finally incorporated into the main project.

First, let me thank Jake Farrell and everybody else on the Thrift team who was involved in THRIFT-1500; reviewing a ~719 kB patch certainly isn’t an easy thing to do. But now that the work is in, what can you (as a Thrift user) expect from the implementation?

Feature-wise, the library should roughly be up to par with the other major implementations (i.e. C++ and Java):

Protocols: Binary, Compact and JSON. The Dense protocol has not been implemented yet – it is only supported by the C++ implementation and I am not sure about its relevance nowadays (but if you are at a certain well-known company and it turns out that you still need the feature for new projects, let me know; adding support for it should not be hard).
Transports: Socket, SSL, HTTP and log file reader/writer implementations (plus your familiar helpers, i.e. buffered/framed/memory-buffer/piped/zlib...)
Servers: several single- and multithreaded variants (including a libevent-based non-blocking implementation)
Clients: Both a synchronous and an asynchronous (future-based interface with one or more libevent-backed worker threads) implementation are provided. Additionally, several pooling implementations for redundancy as well as aggregation use cases are available.

The implementation makes heavy use of D’s metaprogramming capatibilties and is also able to work without code generated off-line from .thrift files, if so desired. There are also a few experimental gimmicks, such as the capatibility to generate Thrift IDL files from existing D types at compile time. Soon to come:

Unix domain sockets: Currently, the D implementation only supports IPv4 and IPv6 TCP sockets, because that is what the D standard library does, but starting with the next release, it will also support Unix domain sockets (if really needed, the lack of support in std.socket could be worked around without much effort, though).
@safe-ty annotations: The D language features built-in memory safety annotations. The majority of the methods in the D Thrift library should be memory safe (except for e.g. TTransport.borrow), so marking it as such allowed Thrift to be used in D programs where safety is enforced without requiring the user to mark the Thrift calls as @trusted.

So, how to get started? As said above, the source code has been mergerd from my personal GitHub repo to the trunk of the main ASF repo, and as soon as the currently ongoing rework of the official Thrift site is completed, the Getting Started with Thrift and D and Building Thrift/D on Windows pages will follow along. A recent build of the API docs is currently available here on my website. If you find any bugs, be sure to file them at the Thrift JIRA.

Get an exception from a segfault on linux (x86 and x86_64), using some black magic !

2012-03-24T17:05:51+00:00

Linux (as other UNIXes) allow you to register handlers for signals. Here we are interested in SIGSEGV. This signal is sent to your program when you try to use a memory location you shouldn’t. Typically, when deferencing null.

Language like Java send a NullPointerException, that can be caught and you can recover from it. However, in a system language, you usually get a cryptic « segmentation fault », you cannot recover from it and cannot have any information about it outside a debugger. Let’s see how we can fix this.

As C++ and D are system languages that support exceptions, we will use this mechanism to handle SIGSEGV. I’ll do it in D in this post, but the same is doable in C++. If you understand why it work, it shouldn’t be a problem.

It is not that simple

1
2
3
4
5
6

shared static this() {
sigaction_t action;
action.sa_sigaction = &handleSignal;
action.sa_flags = SA_SIGINFO;
sigaction(SIGSEGV, &action, null);
}

With this simple sample code, we can register our handler, called handleSignal. But this isn’t as simple as this. When you get into handleSignal, you are not in a standard execution mode. Linux stored the whole state of you application, then called you code, and then will restore thats state when you return. It makes it impossible to throw or get a correct stack trace.

Let’s fool linux into calling our code when returning from the handler !

Well, if we are not able to do whatever we want within the signal handler, then let’s modify the stored context, so linux will restore something different that execute the code we want.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

static REG_TYPE saved_EAX, saved_EDX;

extern(C)
void handleSignal(int signum, siginfo_t* info, void* contextPtr) {
auto context = cast(ucontext_t*)contextPtr;

// Save registers into global thread local, to allow recovery.
saved_EAX = context.uc_mcontext.gregs[REG_EAX];
saved_EDX = context.uc_mcontext.gregs[REG_EDX];

// Hijack current context so we call our handler.
auto eip = context.uc_mcontext.gregs[REG_EIP];
auto addr = cast(REG_TYPE) info._sifields._sigfault.si_addr;
context.uc_mcontext.gregs[REG_EAX] = addr;
context.uc_mcontext.gregs[REG_EDX] = eip;
context.uc_mcontext.gregs[REG_EIP] = &sigsegv_userspace_handler;
}

OK, so what is happening here ? First of all, linux is passing us a structure or type ucontext_t, that contains system dependent information about the context in which the segfault happened. This context is used by linux to restore the program state after we executed our signal handler. So let’s modify it to call the code we want.

On x86, EIP is the register that store the address of the instruction that is executed. If we modify the value of this register then the code placed at the new value will be executed when linux restore the program state. This is good, but not good enough.

It is also mandatory that we store the old EIP value. If we don’t, then we loose the information about where does the segfault happened. So we store the value of EAX and EDX into thread local global variables. And we put the address that cause the fault into EAX and the old EIP value into EDX. Now our handler have everything needed to generate a stack trace and react according to the faulting address.

Our userspace handler cannot be a regular function, that would be too easy

Our userspace handler will not be called like a regular function. The program will jump start execution its instruction directly into the context of the faulting code, except EAX, EDX ans EIP. We need to manipulate the stack to simulate a function call and save all this state before doing anything.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

void sigsegv_userspace_handler() {
asm {
naked;

push EDX; // return address (original EIP).
push EBP; // old EBP
mov EBP, ESP;

pushf; // Save flags.
push ECX; // ECX is a trash register and must be preserved as local variable.

// Parameter address is already set as EAX.
call sigsegv_userspace_process;

// Restore register values and return.
call restore_registers;

pop ECX;
popf; // Restore flags.

// Return
pop EBP;
ret;
}
}

// The return value is stored in EAX and EDX, so this function restore the correct value for theses registers.
REG_TYPE[2] restore_registers() {
return [saved_EAX, saved_EDX];
}

The first 3 instruction are here to simulate a standard function call : the return address is pushed on the stack, then the base pointer (EBP) for the previous function, and finally, the base pointer is modified to reflect the new state of the stack.

Then ECX and flags are stored on he stack. On x86, EAX, ECX and EDX are trash register. It means that a function isn’t required to preserve their content. So, we need to same them before calling anything. And we call sigsegv_userspace_process, a function that will process the segfault into what ever we want.

In case our function do not throw, the assembly code bellow will restore the state of the CPU and return to the faulting address. This is useful in case we want to play with page protection, but I will not explains details of this in this post.

Now we have a routine that make the segfault appear just like a regular function call.

Wait a minute. And what if EIP is causing the segfault ?

One case isn’t handled by our code. We can decide to call or to jump into a memory that is page protected. And now, what do we do ? First of all, unless you do it manually in assembly code, the jump case can’t appear, so let’s not handle it. After all, if you do assembly by yourself, you are supposed to know what you are doing. But, with function pointers, it is possible to call an invalid piece of memory.

1
2
3
4
5

void function() fun = null;

void main() {
fun();
}

In this case, the CPU will push the return address on the stack, but then nothing happen, because it will try to execute what is at an illegal address in memory. Let’s add this extra case in our sigsegv_userspace_handler.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

void sigsegv_userspace_handler() {
asm {
naked;

// Handle the stack for an invalid function call (segfault at EIP).
push EBP;
mov EBP, ESP;

// We jump directly here if we are in a valid function call case.
push EDX; // return address (original EIP).
push EBP; // old EBP
mov EBP, ESP;

// Same code here, not repeated for brevity.
}
}

And we also need to modify our signal handler, to jump at the right address depending on the case.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

So, if the value of EIP is th same as the segfaulting address, then we are in the case where an illegal address is called. If not, then 0×03 is added to EIP to skip the instructions that handle this case. When I said black magic, I meant it !

Note that no restoring is done for such a case : this is impossible anyway and the only exit solution is to throw.

So we finally get somewhere to handle that segfault !

Yes, and now is is easy.

1
2
3
4
5
6
7
8

void sigsegv_userspace_process(void* address) {
// The first page is protected to detect null deference.
if((cast(size_t) address) < MEMORY_RESERVED_FOR_NULL_DEFERENCE) {
throw new NullPointerError();
}

throw new Error("SIGSEGV");
}

What about x86_64 ? What about recovering ?

You have all required data to understand the code, so I’ll just let you read it : sigsegv.d

x86_64 assembly code is different, due to different architecture and calling convention. The example also show how you can recover without throwing by protecting a page, and unprotecting it within the userspace handler.

A pull request have been done to include that into the runtime of D : https://github.com/D-Programming-Language/druntime/pull/187

Special thank to Vladimir Panteleev and FeepingCreature for ideas that produces this code and blog post.

GDC Now on GitHub

2012-03-19T03:26:36+00:00

Like so many other D-related projects, GDC has been migrated to github. I suspect this will up the participation level by a significant factor.

Pegged

2012-03-15T04:20:18+00:00

Philippe Sigaud recently announced Pegged, a parsing expression grammar generator written in D. I have no background at all in this sort of thing, so talk about EBNF grammars and PEGs go way over my head. But if that’s your thing, there’s an ongoing thread in the D.announce forum you may want to drop in on.

Visual D 0.3.31

2012-03-15T04:13:03+00:00

Big news from Rainer Schuetze. The latest release of Visual D adds support for GDC. There’s a page on the project wiki that explains how to get it set up. This release also fixes one of my pet peeves. You can now edit the properties of multiple build configurations at once. Previously, any common properties had to be entered repeated for each configuration. Thank you, Rainer!

Putting D's Array Slices to Use

2012-03-08T15:50:00+00:00

I've been working on BorderWatch a little bit every day. My focus has been on getting the ASCII engine, Arthur, into a state that will let me get a game up and running. With the few modules that I've implemented so far, I believe I'm there. One of the D features that has...

BorderWatch

2012-03-05T14:26:00+00:00

I'm afraid I'm going to be waving goodbye to Dolce. It's been sitting, bit rotting, for a while now. Some time ago I encountered two major issues with my Allegro binding in Derelict 2. One, a random (and I mean...

Impact of 64bits vs 32bits when using non precise GC.

2012-03-04T23:00:27+00:00

As ARM release its intention to go 64bits, we can be pretty much sure that almost every device will be 64bits soon, except the one on which it is unrealistic to run a garbage collector.

A garbage collector can be precise like in Java, or not, like D’s GC or Boehm’s GC for C++. It means that theses GC don’t know what it a pointer and what isn’t. Non precise GC cannot move data to compact the heap, and are also prone to false positive. On a theoretical perspective, switching from 32 bits to 64 bits should improve things, but what it is in practice ?

Non precise GC, and how false positive happens

When you use a non precise GC, the GC is not aware of what is a pointer and what isn’t. It has to suppose that any data it encounter may be a pointer. Pointers are just a numbers stored in memory, and storing the address of something else in the memory. If you have data in memory, even if theses data aren’t pointers, they may have the value of an existing memory address, where something else is stored. This something else will be marked as « alive » by the GC, even if it is actually garbage. This is a false positive. Thing can cascade, because that memory marked as alive can also keep alive some other pieces of memory, and so on.

The bigger the block of memory are, the worse the problem becomes. A large chunk of memory is more likely to be kept as a false positive, because if it is bigger, more address point to it, and so more data can eventually have the same value of one of theses addresses. So the bigger the block is, the more likely it will become a false positive but it get worse ! If the block is bigger, it has more data in it, so it will also cascade more. Finally, the block is bigger, so the direct consequence of the false positive is bigger.

On a 64 bits system, memory addresses are 64 bits long. As the memory address space is way larger, it is less likely that false positive happen.

A program that generate garbage and store how much memory it use

To get numbers, lets generate garbage !

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

void main() {
import std.random;
Mt19937 gen;

import std.process;
import std.conv;
string cmd = "cat /proc/" ~ to!string(getpid()) ~ "/statm | cut -d ' ' -f 2";

//*
alias void* T;
/*/
alias uint T;
//*/

// Variable block size.
enum BLOCK_SIZE = 32 * 1024 * 1024 / T.sizeof;

T[] prevdatas;
T[] datas = new T[BLOCK_SIZE];
T[] crap;
for(uint i = 0; i < 8192; i++) {
foreach(ref data; datas) {
static if(T.sizeof > 4) {
data = cast(T) gen.front;
gen.popFront();
data = cast(T) ((cast(long) data << 32) | gen.front);
} else {
data = cast(T) gen.front;
}

gen.popFront();
}

crap = prevdatas ~ datas;
prevdatas = datas;
datas = new T[BLOCK_SIZE];

if((i % 16) == 0) {
import std.stdio;
write(shell(cmd));
}
}
}

This program allocate arrays, and put random value in them. And start again and again. At some point, it does measure how much memory it use.

This program doesn’t keep any reference to the old arrays, so it should generate a lot of garbage but if the memory usage grow, we have a leak (so false positives).

Result on 32 bits

The results on a 32bits system are scary. I did measure the memory consumption of this program with different block sizes. First of all, I could not run it on block larger than 128Kb. At this point, the amount of false positive is that high that the program end up early because it can’t allocate anymore.

It is clear that the memory usage isn’t stable at all. We have a massive leak when the block size is 16Kb and bigger. To know how many blocks did leak, I have rendered the same graph, but with the number of page used divided by the size of the block.

This graph tells us that the amount of false positive is the same for 16, 32 and 64Kb, but then the number of false positive increase when the block size is 128Kb. As the block is bigger, and may itself lead to more false positives, this cascade and put the system over its limits.

Lets switch to 64 bits !

With 64 bits, the situation is much nicer. I did run the tests to block size up to 32Mb.

In 64bits, the program quickly reach a point where its memory doesn’t grow anymore. It means the the amount of false positive is negligible.

In the first part, the amount of data allocated is negligible compared to the size of the code itself and data from the standard lib and runtime. Then, the memory consumption grow linearly with he memory block size. This second graph confirms that the program is not leaking, and that the amount of floating garbage is proportional with the total amount of data.

Conclusion

Switching to 64 bits solved the issue of false positive in the test program. These data must be confirmed with real world software, but I think it is safe to assume that the situation is way better in the 64 bits case.

As 64 bits is the future, it is unreasonable to invest into precise GC unless some very strong short term incitations comes up. However, precise GC has some other advantages that we may want to exploit. This also tells us that semi precise GC – for example a GC that is precise on the heap, but not on the stack – is a very valid solution and is compliant with hardware of the future. This also means that GC in system language get way more interesting that it used to be.

Additionally, this tells us that the support of 64 bits in DMD is a key feature, and a lot of attention should be put on it, especially on windows. 64 bit is, to this regard, a key feature when it comes to non precise GC.

At some point, false positive will be a problem even in 64bits, but I could not reach the point where it is in a reasonable time and efforts. If someone have data about this limit, please tell me. You’ll find the raw results, if someone want to study them throw this link : gc_measures_d2.058

Compiling Data into a D Executable

2012-03-03T14:22:00+00:00

I'm supposed to be posting part three of my series on binding D to C. It's going to be boring to write, so I keep putting it off. But I *will* get to it eventually. In the meantime, I wanted to blog about a neat feature of D that I'd sort of forgotten about until I needed it.

I'm working on an ASCII-based strategy/simulation game in the...

Mono-D 0.3.0

2012-02-29T18:47:39+00:00

A new version of Mono-D, the D Language Add-in for MonoDevelop, has been announced. This version sports a total overhaul of the code completion engine. There have been several releases of the add-in this month, but I hadn’t covered them all here. If you’ve not checked it out yet, you should. It’s shaping up better and better with each release.

Inheriting Purity

2012-02-22T23:16:00+00:00

Pure functions are an essential characteristic of functional programming, and their value is widely recognized.

A review of D2 – constness and immutablility

2012-02-18T17:00:10+00:00

The D programming language is a very promising language. I propose here to do a quick review of some problems it is facing (or at least problems I’m facing when using it) and propose some solutions.

Immutability and constness in D2

I wanted to to a single, but writing it, it kept getting longer and longer. The point wasn’t to rant randomly, but also to make some proposal to improve things. So I did split it into smaller articles, and here the first one. We will discuss constness and immutability in D2.

Immutability

D2 has several types qualifier (immutable, shared) and they are transitive. It means that any reference or pointer cannot point to anything depending on its type qualifier and cast cannot be done in all directions.

immutable data are data that can only be set once and never redefined again. This ensure that immutable data can be shared without any synchronization process. By default, data are thread local storage, and immutable is a way to share data across threads (with some limitations).

immutable data can point to immutable data only.
mutable data can point to mutable or immutable data.

This ensure that immutable data can never point to thread local data, so it avoid sharing data that isn’t supposed to by mistake.

Conciliate mutable and immutable world : const

Theses qualifiers are completed by const. const is a wild-card, because both immutable and mutable data can cast implicitly to it. It allow the programmer to write code that will work with both mutable and immutable data without duplication when modifying data isn’t required.

So you can cast immutable and mutable to const, but not the other way around.
mutable data can point to const but not the other way around.
const data can point to const or immutable data.
immutable data cannot point to const.

Theses rules ensure that previously expressed rules still apply.

Consider the simple exemple :

1
2
3
4
5
6
7
8
9
10
11

const(int)* fun(const int* p) {
return p;
}

void main() {
int a = 3;
immutable int b = 5;

fun(&a); // Works
fun(&b); // Works too !
}

Great, now we have a function that will work both with mutable and immutable.

Going further with inout, a scope defined type qualifier

Sometime, returning const just doesn’t make it. Because if you pass an immutable as argument, you may want to return an immutable, and not a const. This is explained in this article about inout very nicely.

Consider the simple example from previous part of the article :

1
2
3
4
5
6
7
8
9
10
11
12

const(int)* fun(const int* p) {
return p;
}

void main() {
int a = 3;
immutable int b = 5;

const int* c = fun(&a); // Works
int* d = fun(&a); // Fails ! However, with cut paste of the function code, it works.
immutable int* e = fun(&b); // Fails ! But will also be correct with cut paste programming skills.
}

If you call fun with a immutable parameter, you’ll loose this qualifier for a weaker one : const. A solution is to duplicate the code for immutable and mutable, or to make the compiler duplicate the code using metaprogramming. But it is not required here. We need a way to express the return type according to the parameter type.

Then come inout. inout is a local type qualifier that can refers to mutable, immutable or const data depending on the case. Locally, inout data are considered as const, but outside this scope, data will get its original type qualifier back. It goes like :

1
2
3
4
5
6
7
8
9
10
11
12

inout(int)* fun(inout int* p) {
return p;
}

void main() {
int a = 3;
immutable int b = 5;

const int* c = fun(&a); // Works
int* d = fun(&a); // Works
immutable int* e = fun(&b); // Works
}

The addition of this functionality was a great step forward to reduce the type qualifier mess. But some problems remains.

Existing code that has been written without const or immutable in mind.

Phobos, the standard lib of D, is full of code that isn’t const compliant. To begin with, the toString member function of Objects isn’t const, so cannot be called on const/immutable objects. This is problematic for such a feature, that is required everywhere.

Another example is invariant. Both feature are not supposed to modify the object they ran on (it would even be a huge mistake in invariant).

The sames goes for toHash, opCmp, opEquals, and so many others all over the place !

The current situation is very problematic. In the current state of things, const is broken. It is one a most important problem a beginner encounter and scared beginner isn’t what we want to make that language successful.

This will require breaking API changes. We have no choice, we’d better admit it and plan the change. No easy solutions here, just painful ones. The sooner we do that, the smaller the codebase will, the smaller the impact will. Let’s not be afraid and break our code !

A widely spread misconception in the D community : const cannot qualify a function

In this part, I’ll use const everywhere. However, the whole thing apply to immutable as well. I just omit it to avoid repeating everywhere that the same goes for immutable.

Let’s look at the code below :

1
2
3

const int* fun(const int* p) {
return p;
}

Know what it does ? It does not compile ! « Error: function fun.fun without ‘this’ cannot be const/immutable » is saying the compiler. Thank you dude !

It trigger an error because the compiler try to qualify not the return type, but the function. What is a const function ? In fact it make sense in a very specific case : non static class member functions. In all other case, expect if you put parenthesis, as in previous code samples, it will not compile. Want to scare beginners ? Here is a good solution !

Note that this specification is even against D design principle « if it look like C, it should behave as expected by a C developer ».

Ok, that being said, and considering it is just annoying for most function, let’s consider the case of non static class member function :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class Foo {
int* x;

// Error: cannot implicitly convert expression (this.x) of type const(int*) to int*
// Excaclty the reverse of what you would expect of such a code at a first look.
const int* getX() {
return x;
}

// Error: cast(int)*this.x is not an lvalue
// Yes ! ref is qualifying the return type (int), but const is qualifying the hidden parameter this. How convenient and intuitive !
ref const int getX2() {
return *x;
}

// Hopefully this is working as expected. The postfix const syntax is what what is often preferred in current D code, because the other way is too confusing. The parenthesis ensure that the first const is qualifying the return type.
const(int)* getX3() const {
return x;
}
}

I think we could simply admit that const isn’t qualifying the function, but the hidden parameter this. This has no advantages whatsoever and just confuse newcomers. Additionally, this break readers automatisms, because reading const int* doesn’t mean always the same thing.

The worse case being the « ref const » joke in the return type.

D aims to break patterns of error, and by mistake introduced one that didn’t existed in its predecessors. It has to be fixed.

This pattern can be encountered in 3 cases :

Standard functions, or static member functions.
Non static member functions.
Function pointers and delegates types.

And we want to qualify different things as being const :

The return type.
The hidden parameter – this or context execution of a delegate.
In case of function pointers and delegates types, the pointed memory location.

Let consider the most simple example : a function. The only things that make sens in this case is const qualifying the return type. So why overcomplicating ourselves ? Let’s make const in the return type qualify the return type itself instead of outputing error. It is what most people will expect.

1
2
3

const int* fun(const int* p) {
return p;
}

Then, comes hidden parameter. I strongly suggest postfix notation for that, so it cannot be confused with return type qualifier, and would break the confusion about const qualifying the function. This is already know as a good practice in most D project, and shouldn’t break too many code. However, it should be possible to put that const anywhere after the return type.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class Foo {
int* x;

const int* fun() { // OK
return x;
}

const int* const fun() { // OK
return x;
}

int* const fun() { // Fail : const int* cannot be casted as int*
return x;
}

const int* fun() const { // OK. Equivalent to proposal 2.
return p;
}
}

Then we need to be able to qualify function pointer and delegate. Let’s start with function pointer, because it doesn’t have transitivity issue. In such a case, the same as previously exposed apply : const qualify return type if it part of it, and qualify function pointer after that. Note that member function are delegate (they have hidden parameter) so this will not conflict. For delegate, transitivity impose us that the type qualifier of the delegate qualify also the hidden parameter. In such a case, const after return type will qualify both delegate and hidden parameter, and postfix const will qualify only the hidden parameter.

Let’s put that into some code so it’s easier to understand :

1
2
3
4
5
6
7
8
9
10
11
12
13

int* function() fp; // A function pointer that return an int*.
const int* function() fp; // A function pointer that return a const int*.
int* const function() fp; // A constant function pointer that return an int*.
const int* const function() fp; // A constant function pointer that return a const int*.

int* delegate() dg; // A delegate that return an int* using a mutable hidden parameter.
const int* delegate() dg; // A delegate that return a const int* using a mutable hidden parameter.
int* const delegate() dg; // A constant delegate that return an int* using a const hidden parameter (because of transitivity).
const int* const delegate() dg; // A constant delegate that return a const int* using a const hidden parameter (because of transitivity).
int* delegate() const dg; // A delegate that return an int* using a const hidden parameter.
const int* delegate() const dg; // A delegate that return a const int* using a const hidden parameter.
int* const delegate() immutable dg; // A constant delegate that return an int* using an immutable hidden parameter.
const int* const delegate() immutable dg; // A constant delegate that return a const int* using an immutable hidden parameter.

In last cases, I used immutable because const was implied by transitivity. So something stronger was required.

In all cases, parenthesis can be used to explicitly use const as a prefix. This would also make this modification auto compliant. Basically, auto should behave as if it as parenthesis around it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

const(int* function()) fp; // A constant function pointer that return an int*.

const auto fp = function int*() { // A constant function pointer that return an int* as well.
return null;
}

const auto fp = delegate int*() { // A constant delegate that return an int* as well using a const hidden parameter.
return null;
}

auto fp = delegate int*() const { // A constant delegate to a function that return an int* using a const hidden parameter.
return null;
}

auto const fp = delegate int*() const { // A constant delegate to a function that return an int* using a const hidden parameter.
return null;
}

auto fp = delegate int*() immutable { // A delegate to a function that return an int* using a immutable hidden parameter.
return null;
}

const auto fp = delegate int*() immutable { // A constant delegate to a function that return an int* using a immutable hidden parameter.
return null;
}

Conclusion

I hope I didn’t scarred you. D2 type system is really nice and address many issue that exists in other languages, introducing the tools required to handle functional and concurrent programming style.

However, this type system is really something new and some work has to be done to make it as powerful and as easy to use as it is on the paper.

Mono-D 0.2.9

2012-02-17T05:15:58+00:00

Mono-D is a plugin for MonoDevelop that allows for D support. Version 0.2.9 is now available for download.

DMD 1.073 and 2.058

2012-02-15T05:35:49+00:00

There’s a lot to be happy about in the two new DMD releases. Both version 1.073 and 2.058 are loaded with bugfixes. The 2.x release even sports a new lambda syntax. I was very happy that my “favorite” D bug was finally getting fixed in this release. Unfortunately, it was reverted during beta due to some serious regressions. My fingers are crossed for the next release.

Thanks to every one who helped make these fantastic releases possible. Your hard work is always appreciated!

D Forums

2012-02-15T02:48:05+00:00

Vladimir Panteleev’s awesome web interface to the D newsgroups has now gone live on the D site to replace the clunky old web interface that used to be there. I still prefer my newsreader, but now I finally have a nice, permanent place to link to D announcements and such from this blog.

Vladimir used D to create the whole thing, making it a nice demonstration of D usage in the web sphere. As with many other open source D projects these days, there is a repository over at GitHub for your hacking pleasure.

Comments Temporarily Moderated

2012-02-09T12:58:22+00:00

Unfortunately, some spam comments have been getting past the filter and posted to some old posts. It’s the first time it’s happened on this blog since I’ve been running it. But it’s starting to annoy me. I’ve deleted several today. So, until it dies down, I’m turning on comment moderation. Don’t let that stop you from commenting, though, if you have something to say!

Getting Started With D

2012-02-09T05:36:30+00:00

There’s a nifty little guide online now that explains how to get set up with the D Programming Language and (ahem) Vim on Windows. It looks to be a great intro for those coming to D for the first time. One of these days, I’ll have to take the time to try (again) to get comfortable with Vim.

The hashtable closure pattern

2012-02-02T15:45:05+00:00

I noticed that I was using a pattern of my own more and more. It is actually very usefull, for several reasons. It may have been used by other before me, but never saw a name for it.

This pattern is useful when you have to apply an operation dependent on parameters several times. for example when you want to apply a calculation on all elements of an array, the calculation depending on some parameters. This article will explain you that pattern and demonstrate how it can be used in Javascript, PHP and D.

This pattern can be used in any language that support first class function and hashtable, that is becoming more and more common (closure support was added in PHP as of version 5.3).

An explanation of the pattern and when it can be used

As an example is often more clear than a lot of theoretical chit chat, let’s talk about a concrete case. You want to create a function that present a set of data in different format (pie chart, histograms, etc . . .). We will use Javascript in the first place.

1
2
3
4
5
6
7
8
9
10
11
12

function create_chart(type, datas) {
for(var i = 0; i < datas.length; i++) {
switch(type) {
case 'pie' :
// Draw the data in a way.
break;
case 'histogram' :
// Draw data another way.
break;
}
}
}

Ok the point was not to show how we can draw a chart, but show what is the structure of the code. This code have a problem : the switch is performed for every data in the chart. This is obvious that the result of the switch is always the same and that it doesn’t belong into the loop. You don’t want calculation to be made for nothing. So let’s put that test outside the loop :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Now the computer isn’t repeating itself, but YOU are. And it is even worse. After all, the computer is done to do some work for you, not the other way around. Additionally, duplicating code is known as a bad practice. This is called the DRY principle : Don’t Repeat Yourself. Experience have showed us that duplicated code is harder to maintain, and is more bug prone. If you find a bug in the duplicated code, it have to be fixed at several place. You’ll sometime forget to correct it in one of the places. Eventually, the 2 duplication will evolve in 2 different implementation that require both to be maintained.

Here comes another good principle in programming : separation of concerns. Here we don’t want to care how to we traverse all our datastructure to apply our code on each data. Let’s delegate that work to another piece of code. This has 2 advantages : you avoid duplication of the loop, and by improving that traversal function, you’ll improve your whole codebase. You can improve it to make it faster, or to support new datastructures, or whatever your software will need in the future.

I’ll use the $.each function of jQuery here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Maybe this doesn’t look like a win to you, but it is, I can assure you. Now you have clearly separated the fact of traversing you datastructure and the action you’ll apply on it. But still we have some repetition, we have 2 identical calls to $.each . I’d say that is better but still not perfect.

Here, the whole point of our code is reduced to associate a closure with a keyword (pie or histogram) and pass this closure to $.each . To create this association, we will use an hashtable, and « TADAA ! » the Hashtable – closure pattern is born.

In javascript, every object is an hashtable, so let’s write some code :

1
2
3
4
5
6
7
8
9
10

function create_chart(type, datas) {
$.each(datas, {
pie : function(i, data) {
// Draw the data in a way.
},
histogram : function(i, data) {
// Draw data another way.
}
}[type]);
}

Implementation in PHP and D

You know everything, let’s go directly to code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function create_chart($type, $datas) {
$closures = array(
'pie' => function($i, $data) {
// Do stuff . . .
},
'histogram' => function($i, $data) {
// Do other stuff . . .
},
);

$closure = $closures[$type];
foreach($datas as $i => $data) {
$closure($i, $data);
}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

void create_chart(R)(string type, R datas) if(isInputRange!R) {
alias typeof(datas.front) T;
auto closure = [
"pie" : function void(size_t i, T data) {
// Do stuff . . .
},
"histogram" : function void(size_t i, T data) {
// Do other stuff . . .
},
][type];

size_t i = 0;
foreach(data; datas) {
closure(i++, data);
}
}

Both in PHP and D, foreach is a very extensible feature of the language. It will allow us to travers almost any datastructure.

Building on that pattern

In all our example, we use a string as a key for our hashtable. This is nice, but we can use actually anything. For performance reasons, an int is preferred. With an int, you can simply use an array (which is a special hashtable with identity as an hash function).

This pattern has another advantage, is make your code very extensible. In all presented examples, the hashtable is predefined. But you can perfectly store the hashtable outside the function and provide a way for third party code to add closure in it. Now you have a very nice design with a core library that can accept plugins to extends its functionality easily.

Derelict on GitHub

2012-02-01T11:38:57+00:00

I’ve finally got Derelict all set up on GitHub. But if you haven’t kept up with the Derelict forum, you may be surprised at the Derelict3 label. The short version is that my decision to move to GitHub coupled with the recent announcement by Andrei that D1 would be phased out this year led me to believe this was a good time to overhaul the code base. Read more about that in my forum post on the topic.

You can consider it in an alpha state. Currently, there are three packages: DerelictUtil, DerelictGL3 and DerelictGLFW3. The readme in the repository explains most of what you need to know to get started. Two things to note. First, if you aren’t using modern OpenGL, stick with Derelict2. Second, if you are using D1, stick with Derelict2. Otherwise, consider this an opportunity to easily get up and running with Modern OpenGL in D.

If you do want to dive in, you’ll likely want to get your hands on GLFW 3 if you haven’t got a framework already. I do intend to add bindings for SDL 2, but for now GLFW 3 is it. You’ll have to check out the source from the Sourceforge git repository (the Subversion repository is the 2.7 branch — not what you want). You’ll then need CMake to build.

As I explain in the readme, non-Windows and/or non-DMD users will need to modify the Derelict build script to actually build Derelict3. It is currently set up only for Windows and is not in a final, configurable form yet. I just hacked it together, though I did put just a little bit of structure in it with an eye to the future. It shouldn’t take too much effort to get it going.

Enjoy!

Tango For D2

2012-02-01T09:52:25+00:00

There has been an ongoing effort to port Tango to D2 for some time now. I remember hearing the first whispers of such a project a couple of years ago. Well, it’s definitely more than whispers now.

I don’t know the history behind this particular branch, but SiegeLord has finished an initial port of Tango to D2. The announcement says it works fine alongside Phobos, a serious validation of one of the reasons behind D2′s adoption of DRuntime. This means that, as long as they use D2, library developers can make use of either Phobos or Tango without care. And app developers can use any library that suits their app, regardless of whether it’s using Phobos or Tango under the hood. Awesome stuff.

To be sure, the old religious Phobos/Tango divide has not been a problem for quite some time, as it’s been pretty much settled that you use Tango with D1 and Phobos with D2. Well, for those in the know at least. There are a lot of unenlightened people out there who go on hearsay. Now, with D2, you can get the best of both worlds. Use whichever suits your style, or both at once, and no guilty feelings. Hopefully, this will put the old infamous legend to rest once and for all.

I’ve rarely looked at Tango since moving to D2 some time ago, except for an occasional compile to make sure Derelict still builds with it. From a practical point of view, I think it’s useful to make use of both libraries. So now that we have the ability to do so, I’m more excited than I expected to be. There are certain features one has that the other lacks, or that are more complete in one than the other. There I can see great benefit. It all depends on how well they play together. From what I’ve heard so far, they seem to get along swimmingly.

Of course, I’ll have to investigate this more to see if it really is as useful for me as it appears on the surface. In the meantime, thanks for the effort, SiegeLord, Jacob Calrborg, Igor Stepanov, and whomever else contributed!

Binding D to C Part Two

2012-01-31T03:16:00+00:00

This is part two of a series on creating bindings to C libraries for the D programming language.

In part one, I discussed the difference between dynamic and static bindings and some of the considerations to take into account when deciding which way to go. Here in part two, I'm...

A Tutorial on Templates

2012-01-31T03:12:38+00:00

Phillipe Sigaud has put together a tutorial on D templates. Well worth the read if you haven’t yet familiarized yourself with them. It’s great to see this stuff popping up these days. It makes getting into advanced D features easier than ever.

`getaddrinfo` cross-platform edge case behavior

2012-01-30T23:00:00+00:00

The POSIX and Windows getaddrinfo function returns a list of IP addresses and port numbers for a given hostname and service (resp. port), superseding gethostbyname and getservbyname. Besides some flags, it accepts two string parameters. Either one of them is allowed to be null, representing localhost (or rather 0.0.0.0, depending on AI_PASSIVE) respectively an automatically assigned port. Both parameters being null at the same time, however, is forbidden, and leads to a EAI_NONAME error (WSAHOST_NOT_FOUND on Windows). What happens if the strings are empty ("\0") instead of null, however, is not covered by the spec and not really documented anywhere.

It turns out that there are quite a few differences there between the various operating systems, which is obviously likely to cause issues for Wine (an implementation of the Windows API on Posix/X systems). To get a clear understanding of how the different cases are handled, I put together a little D program which tests a few combinations of host name, port, and flag parameters (see end of post). The snippet could be written in C just the same, as getAddressInfo directly maps to getaddrinfo, I just chose D to avoid platform dependencies and writing an unduly large amount of more boilerplate code.

The results are summarized in the following table, where »loopback« means that the IP addresses returned were 127.0.0.1 and ::1, »catchall« refers to 0.0.0.0 and ::, »public« means that the actual IP addresses of all available network interfaces were returned, and NONAME refers to a lookup error. »hostname« means that the actual fully qualified name of the host that ran the test was used (care: the host part of the FQDN only does usually not resolve on OS X).

Host	Port	Flags	Windows	Linux	OS X
`null`	`null`	-	`NONAME`	`NONAME`	`NONAME`
		`AI_PASSIVE`	`NONAME`	`NONAME`	`NONAME`
	`""`	-	loopback	loopback	`NONAME`
		`AI_PASSIVE`	catchall	catchall	`NONAME`
	`"0"`	-	loopback	loopback	loopback
		`AI_PASSIVE`	catchall	catchall	catchall
	`"80"`	-	loopback	loopback	loopback
		`AI_PASSIVE`	catchall	catchall	catchall
`""`	`null`	-	public	`NONAME`	`NONAME`
		`AI_PASSIVE`	public	`NONAME`	`NONAME`
	`""`	-	public	`NONAME`	`NONAME`
		`AI_PASSIVE`	public	`NONAME`	`NONAME`
	`"0"`	-	public	`NONAME`	loopback
		`AI_PASSIVE`	public	`NONAME`	catchall
	`"80"`	-	public	`NONAME`	loopback
		`AI_PASSIVE`	public	`NONAME`	catchall
`"localhost"`	`null`	-	loopback	loopback (v4)	loopback
		`AI_PASSIVE`	loopback	loopback (v4)	loopback
	`""`	-	loopback	loopback (v4)	loopback
		`AI_PASSIVE`	loopback	loopback (v4)	loopback
	`"0"`	-	loopback	loopback (v4)	loopback
		`AI_PASSIVE`	loopback	loopback (v4)	loopback
	`"80"`	-	loopback	loopback (v4)	loopback
		`AI_PASSIVE`	loopback	loopback (v4)	loopback
hostname	`null`	-	public	loopback (v4)	public
		`AI_PASSIVE`	public	loopback (v4)	public
	`""`	-	public	loopback (v4)	public
		`AI_PASSIVE`	public	loopback (v4)	public
	`"0"`	-	public	loopback (v4)	public
		`AI_PASSIVE`	public	loopback (v4)	public
	`"80"`	-	public	loopback (v4)	public
		`AI_PASSIVE`	public	loopback (v4)	public

getaddrinfo() behavior on Windows Server 2008 R2, Arch Linux (Kernel 3.1.4, glibc 2.14.1), and OS X 10.7.2 (Lion).

What caused me to investigate the issue in the first place is the behavior when given an empty, non-null host string: Windows returns the public addresses of the present interfaces, while OS X resolves them to ::1/::, but only if a port is given, and Linux doesn’t resolve them at all! Windows generally accepts the most combinations, returning an error only for the explicitly disallowed combination, which is relied on by some applications (e.g. the game League of Legends).

There were also some less significant differences in behavior which are mostly not listed in the table. First, in both of the Linux VMs I tried (an up-to-date Arch box and Ubuntu Oneric), only the IPv4 address of the loopback interface was returned. Second, as in the test no address family, socket type or protocol hints were passed to getaddrinfo(), each address was returned twice on OS X, once with SOCK_STREAM/IPPROTO_TCP and once with SOCK_DGRAM/IPPROTO_UDP set. Linux returned three copies of each address, for STREAM, DGRAM and RAW, with the according protocol types set, whereas Windows only returned a single copy with protocol type IPPROTO_IP and socket type set to 0.

In any case, as a result I have prepared a patch for Wine to emulate at least the succeeding/failing behavior of the Winsock incarnation of getaddrinfo on Linux and OS X, which should solve the bigger part of the related problems. There ideally shouldn’t be any Windows software relying on details beyond that (such as the actual number/layout of addresses returned), but who knows…

import std.algorithm, std.conv, std.range, std.socket, std.stdio;
alias AddressInfoFlags AIF;
void main() {
  foreach (host; [null, "", "localhost", Socket.hostName()])
  foreach (port; [null, "", "0", "80"])
  foreach (flags; [cast(AIF)0, AIF.PASSIVE]) {
    write(
      host ? "'" ~ host ~ "'" : "null", ":",
      port ? "'" ~ port ~ "'" : "null", " (", flags, "): "
    );
    try {
      writeln(
        join(
          map!q{text(a.address, " (", a.protocol, ")")}(
            sort!q{a.family < b.family}(
              getAddressInfo(host, port, flags)
            )
          ),
          ", "
        )
      );
    } catch (Exception e) {
      writefln("[%s]", e.msg);
    }
  }
}

D program used for gathering the data (longer than necessary to get semi-nice output).

D:GamesVFS

2012-01-20T04:50:51+00:00

kith-sa has announced a virtual file system aimed at D game developers. D:GameVFS isn’t fully featured (can’t delete directories, lacks security), doesn’t support archives, and has an unstable API. But it’s licensed under the Boost Software License and is available for you to snatch at github for you to use and/or improve upon. For details of what it can and can’t do, see the intro page at github.

A Tutorial on Ranges

2012-01-16T13:24:37+00:00

Ali Çehreli wrote a book on D in Turkish. He has been translating it into English chapter-by-chapter. In the newsgroups, he recently posted a link to the English translation of the chapter on ranges.

The topic of ranges is, in my opinion, the single most difficult concept for D newcomers to wrap their heads around. I know I’ve had my fair share of head-scratching moments when functions in std.algorithm or std.range didn’t work the way I expected them to. This chapter definitely goes a long way to reducing them.

DWT Moved to GitHub

2012-01-09T13:14:46+00:00

I had intended to post about this when I first saw it in the DWT newsgroup, but it slipped my mind. Luckily, Jacob reposted it in the announce newsgroup. He has picked up DWT and lugged it over to github, breaking the packages up into submodules in the process. From the announcement:

Use these commands to clone the repository and get all submodules:

$ git clone git://github.com/d-widget-toolkit/dwt.git
$ git submodule init
$ git submodule update

In another post, he mentioned that he has no time for DWT development himself at the moment, but will happily accept pull requests. So those of you with the wherewithal to do some work on DWT , your country (that would be D Land) needs you.

Binding D to C

2012-01-08T08:12:00+00:00

This is part one of a series on creating bindings to C libraries for the D programming language.

This is a topic that has become near and dear to my heart. Derelict is the first, and only, open source project I've ever maintained. It's not a complicated thing. There's very little...

Visual D 0.3.30

2012-01-07T15:02:12+00:00

A new release of Visual D, the plugin for Visual Studio, has been uncaged. I’ve already installed it. Rather than quote the announcement, I’ll just point you over to DFeed so you can read it in full. Gotta love DFeed.

D Version Manager 0.4.0

2012-01-07T03:10:45+00:00

D Version Manager “allows you to easily download and install D compilers and manage different versions of the compilers.” A new version has been released which adds the ability to compile DMD, DRuntime and Phobos (either from a github clone or from an official release package). For more info on the release, see the announcement thread over at DFeed.

Happy New Year

2012-01-01T08:22:20+00:00

I’m looking forward to a wonderful year in D-Land. Of course, I expect to see continued growth of the community and improvement in the compilers. But more than that, I have a feeling that this could be a bigger year for D than ever. If you asked me why, I couldn’t tell you. It’s just a feeling.

Have a happy and healthy new year!

Targeting OS X 64 Bit

2011-12-27T13:24:00+00:00

A while back, I targeted the D programming language compiler to generate 32-bit code for OS X, and 64-bit code for Linux. For the last several years, all Mac OS X machines include 64-bit CPUs, so the obvious next step is to target 64-bit code for OS X.

Dolce and Da5teroids

2011-12-18T13:12:00+00:00

So I've finally gotten started on some game code. In order to see if Dolce is actually useful or a waste of time, I decided to start by porting the A5teroids demo that ships with the Allegro 5 package. Here's what I've learned so far.

First, the whole idea of Dolce as a framework on top of Allegro to allow an absolute minimum amount of startup...

Dice and random sources

2011-12-18T01:47:04+00:00

On Le Scienze (an edition of Scientific American) number 519, November 2011 there is a small mathematical problem. It asks to extract a random number among 8 using a die (that gives just a 1-6 result).

The Le Scienze number 520, December 2011 shows two alternative answers. The first is to throw the die three times, and take the parity of each result. This means producing three random bits, that are the binary digits of a 0..7 number. The second solution is to use the rotation too of the physical die, and look at the numbers on the other faces, this gives 24 random possibilities, that are usable to find a 0..8 random number.

This simple D v.2 code uses the first solution. random8() returns a random 0..8 number. It requires three throws to find a result:

import std.stdio, std.random, std.algorithm;

__gshared uint dieCount;

int throwDie() {
    dieCount++;
    return uniform(0, 6);
}

int random8() {
    return ((throwDie() % 2) << 2) +
           ((throwDie() % 2) << 1) +
           (throwDie() % 2);
}

void main() {
    enum int N = 10_000_000;
    uint[int] freqs;

    foreach (_; 0 .. N)
        freqs[random8()]++;

    foreach (k; freqs.keys.sort())
        writeln(k, " ", freqs[k]);

    writefln("\n%.6f", dieCount / cast(double)N);
}

Output:

A die throw gives about 2.6 random bits, if you look at just its upper face. So using 3 bits from 3 throws means wasting about 4.75 random bits (log(6 * 6 * 6, 2) ~= 7.75).

But it's not hard to reduce the number of dice to throw on average. The idea is to just throw away a die result if it's larger than 4 (but in the code the die gives a 0..6 result, so the limit is 3), to collect two random bits, and then to find the parity of another die throw to collect the third bit of the result. On average this requires just a little more than two and half throws for each 1..9 random result. But this strategy too wastes some bits of the random source:

import std.stdio, std.random, std.algorithm;

__gshared uint dieCount;

int throwDie() {
    dieCount++;
    return uniform(0, 6);
}

int random8() {
    while (true) {
        immutable int d1 = throwDie();
        if (d1 < 4)
            return (d1 << 1) + (throwDie() % 2);
    }
}

void main() {
    enum int N = 10_000_000;
    uint[int] freqs;

    foreach (_; 0 .. N)
        freqs[random8()]++;

    foreach (k; freqs.keys.sort())
        writeln(k, " ", freqs[k]);

    writefln("\n%.6f", dieCount / cast(double)N);
}

Output:

There are ways to waste less bits on average, but they become more complex and require more total throws to reach the average.

Update Dec 19 2011: for a smarter solution see this rosettacode task:
http://rosettacode.org/wiki/Seven-sided_dice_from_five-sided_dice#D

The Task: Given an equal-probability generator of one of the integers 1 to 5 as dice5; create dice7 that generates a pseudo-random integer from 1 to 7 in equal probability using only dice5 as a source of random numbers.

Two D solutions, fiveToSevenSmart minimizes the number of calls to dice7:

import std.random: uniform;

__gshared uint die5Count;

/// Generates a random number in [1, 5].
int dice5() /*nothrow*/ {
    die5Count++; // update count
    return uniform(1, 6);
}

/// Naive, generates a random number in [1, 7] using dice5.
int fiveToSevenNaive() /*nothrow*/ {
    immutable int r = dice5() + dice5() * 5 - 6;
    return (r < 21) ? (r % 7) + 1 : fiveToSevenNaive();
}

/**
Generates a random number in [1, 7] using dice5,
minimizing calls to dice5.
*/
int fiveToSevenSmart() /*nothrow*/ {
    static int rem = 0, max = 1;

    while (rem / 7 == max / 7) {
        while (max < 7) {
            immutable int rand5 = dice5() - 1;
            max *= 5;
            rem = 5 * rem + rand5;
        }

        immutable int groups = max / 7;
        if (rem >= 7 * groups) {
            rem -= 7 * groups;
            max -= 7 * groups;
        }
    }

    immutable int result = rem % 7;
    rem /= 7;
    max /= 7;
    return result + 1;
}

void main() {
    import std.algorithm; // sort, reduce
    import std.stdio; // writefln
    enum int N = 10_000_000;

    foreach (rnd; [&fiveToSevenNaive, &fiveToSevenSmart]) {
        uint[int] counts;
        .die5Count = 0;

        foreach (_; 0 .. N)
            counts[rnd()]++;

        immutable tot = reduce!q{a + b}(counts.byValue());
        foreach (k; sort(counts.keys))
            writefln("%d %.2f%%", k, (100 * counts[k]) / cast(double)tot);

        writefln("Average dice5 throws: %.4f\n",
                 die5Count / cast(double)N);
    }
}

That prints:

1 14.29%
2 14.30%
3 14.27%
4 14.29%
5 14.26%
6 14.29%
7 14.29%
Average dice5 throws: 2.3813

1 14.28%
2 14.28%
3 14.29%
4 14.30%
5 14.29%
6 14.29%
7 14.27%
Average dice5 throws: 1.5458

Derelict Updates

2011-12-15T14:32:42+00:00

Users of Derelict 2 should upgrade to the latest and greatest. The newest DMD releases broke compilation, but the repository now contains fixes. Also, I discovered that DerelictAllegro wasn’t Tango-ready, so now it is.

DMD 1.072 and 2.057

2011-12-14T12:01:49+00:00

DMD 1.072 was released a few days back, but 2.057 spent some extra time in the oven before being announced today. One of the biggest deals in 1.072 is support for 64-bit Mac OSX. And in the 2.057 release, there’s just too much goodness to pick any one thing to mention here.

One important related bit of news is that next year, from Dec 31, 2012, DMD 1.x will no longer be developed. So if you’ve got a D1 codebase you were considering porting to D2, now may be the time to get started on that. The D1 compilers will still be around, of course, they just will no longer have any official support.

News Roundup

2011-12-06T02:14:08+00:00

Recent announcements from D Land.

* If you are doing any graphics programming in D, you may be interested in gl3n, a math library explicitly geared toward that purpose.

* Version 0.3.29 of VisualD has been announced. This release includes a nifty little tool that will convert C++ code to D.

* Another IDE plugin has hit the streets. This one, called Mono-D, is “a MonoDevelop AddIn which provides code completion/refactoring features and project management for D.”

* And good news for Windows developers who don’t want to use DMD. A new version of MingW GDC is out, with support for Thread-Local Storage. For this one, Daniel Green’s full newsgroup announcement is quoted below.

Please post all issues in D.gnu or on GDC’s bitbucket site https://bitbucket.org/goshawk/gdc

* Built against TDM GCC 4.6.1: http://tdm-gcc.tdragon.net/
* Built against GDC revision 7e22befef29c.
* Working TLS support.
* Updated binutils and mingw runtime for TLS support.
* new gas directive @secrel32 will generate a constant offset usable
as an immediate or displacement value.
Works like posix counterparts @tpoff, @dtpoff, etc.
* Fixes an error with the mingw runtime related to TLS.
* 7-zip format for size reasons: http://7-zip.org
* Release includes both D versions.
* -v1(default) compiles for D1.
* -v2 compiles for D2.
* The switch must be used for linking as well.
* Made possible by Iain Buclaw’s hard work in maintaining GDC.
* 64bit and up to date GDC forthcoming.

To install simply extract to you TDM MinGW32 directory.

This release
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm-1-gdc-7e22befef29c-20111205.zip

All MinGW GDC downloads.
It’s highly recommended to ignore all prior builds. TLS *will* not work.
https://bitbucket.org/goshawk/gdc/downloads

All patches, source files and build scripts can be found at https://bitbucket.org/venix1/mingw-gdc/

Enjoy.

Reading PDFs on the Kindle Fire

2011-12-02T21:29:00+00:00

I've read a lot of reviews of the Kindle Fire, and they don't discuss something very important to me — reading PDF files on the Fire

Updates and links

2011-11-26T01:26:56+00:00

Two new small D programs, to compute sorting networks at compile time, and to compute PI:
http://www.fantascienza.net/leonardo/js/index.html#bose_nelson
http://www.fantascienza.net/leonardo/js/index.html#machin_pi

-------------------

A little but nice introduction to Haskell:
http://www.ozonehouse.com/mark/haskell-amuse-bouche/slides.html
And its code:
https://github.com/mtnviewmark/haskell-amuse-bouche
And its talk:
http://youtu.be/b9FagOVqxmI

An Adventure in the Nth Dimension, by the good Brian Hayes, some simple but interesting and important comments about higher higher dimensions geometry:
http://www.americanscientist.org/issues/id.13850,y.0,no.,content.true,page.1,css.print/issue.aspx

One of the strangest things I've seen in JavaScript, used with the Agda language:
https://github.com/agda/agda-frp-js

Interfacing D with C++ : start new thread

2011-11-24T23:16:45+00:00

Interfacing D with C++ is sometime tricky. In this scenario, I will show how to start a thread from C++ that execute C++ code, but in a valid D environment, so that C++ code can interact with D code safely.

This work as been done to port SFML2 to D2 language. But the technique is useful for anybody who want to start safely thread in a environment with code in both C++ and D.

The main function

First of all, we need a C++ main. This seems easy, but is actually not so straightforward, because D runtime already define that function (and you’ll get an error at link time). So lets define a D main, that start our program in C++ :

1
2
3
4
5

module main;
extern(C++) int CXXmain();
int main(string[] argv) {
return CXXmain();
}

Now we can start our C++ code using CXXmain function. We doesn’t pass any command line parameter in this example, however, this is something we should consider to add in the future.

The C++ thread class

To encapsulate the thread functionality (that is different on each system) we will use a class designed to abstract what is a thread. To not reinvent the well, this example will use a modified version of SFML‘s thread class. This thread class use ThreadImpl, another class, to provide an system dependent implementation of threads. Let’s write our own version of ThreadImpl, implementing what we need to start a thread using D runtime.

The header :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

#ifndef SFML_THREADIMPL_HPP
#define SFML_THREADIMPL_HPP

#include <SFML/System/NonCopyable.hpp>

namespace sf
{
class Thread;

namespace priv
{
////////////////////////////////////////////////////////////
/// \brief D implementation of threads
////////////////////////////////////////////////////////////
class ThreadImpl : NonCopyable {
public :

////////////////////////////////////////////////////////////
/// \brief Default constructor, launch the thread
///
/// \param owner The Thread instance to run
///
////////////////////////////////////////////////////////////
ThreadImpl(Thread* owner);

////////////////////////////////////////////////////////////
/// \brief Wait until the thread finishes
///
////////////////////////////////////////////////////////////
void Wait();

////////////////////////////////////////////////////////////
/// \brief Terminate the thread
///
////////////////////////////////////////////////////////////
void Terminate();

private :

////////////////////////////////////////////////////////////
/// \brief Global entry point for all threads
///
/// \param userData User-defined data (contains the Thread instance)
///
/// \return Os specific error code
///
////////////////////////////////////////////////////////////
static void* EntryPoint(void* userData);

////////////////////////////////////////////////////////////
// Member data
////////////////////////////////////////////////////////////
void* tid; ///< Tid instance
};

} // namespace priv

} // namespace sf

#endif // SFML_THREADIMPL_HPP

And the implementation :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

#include <SFML/System/D/ThreadImpl.hpp>

#include <SFML/System/Thread.hpp>

// Thoses are not supposed to be used on C++ side. Anyway, they require to be in the global scope to be linked with D.
void* __dsfml_start_thread(void* (*entryPoint)(void*), void* userData);
void __dsfml_wait_thread(void* tid);
void __dsfml_terminate_thread(void* tid);

namespace sf
{
namespace priv
{
////////////////////////////////////////////////////////////
ThreadImpl::ThreadImpl(Thread* owner) {
tid = __dsfml_start_thread(&ThreadImpl::EntryPoint, owner);
}

////////////////////////////////////////////////////////////
void ThreadImpl::Wait() {
__dsfml_wait_thread(tid);
}

////////////////////////////////////////////////////////////
void ThreadImpl::Terminate() {
__dsfml_terminate_thread(tid);
}

////////////////////////////////////////////////////////////
void* ThreadImpl::EntryPoint(void* userData) {
// The Thread instance is stored in the user data
Thread* owner = static_cast<Thread*>(userData);

// Forward to the owner
owner->Run();

return NULL;
}

} // namespace priv

} // namespace sf

Now we have a thread class in C++ that forward its calls to D code. We need to start a thread from D using that code. Let create our main C++ code to start teh thread :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#include<SFML/System.hpp>

#include<iostream>

using namespace sf;

void someFunction() {
std::cout << "Some function !" << std::endl;
}

int CXXmain() {
Thread* t = new Thread(someFunction);
t->Launch();
return 0;
}

Start a thread the D way

Now that we have everything set up to forward thread call to D, we have to handle that calls. The most interesting function (and the only one we will implement for now) is __dsfml_start_thread. This function has 2 parameters : a function pointer to a C++ entry point for the new thread, and a pointer to user defined data.

Let’s start this new thread with the spawn method :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

module dsfml.system.thread;

import std.concurrency;

alias extern(C++) void* function(void*) EntryPoint;

extern(C++) {
void* __dsfml_start_thread(EntryPoint entryPoint, void* userData) {
Tid tid = spawn(function void(EntryPoint entryPoint, shared void* userData) {
entryPoint(cast(void*) userData);
}, entryPoint, cast(shared void*) userData);

return cast(void*) [tid].ptr;
}

void __dsfml_wait_thread(void* tid) {
// TODO: This could be implemented in the future.
}

void __dsfml_terminate_thread(void* tid) {
// Does nothing because it is unsafe (and not provided by D API as far as my knowledge goes).
}
}

As you can see, we have to do a lot of casts to work around the lack of shared qualifier in C++, but required by D to share data across threads. This is due to the different memory model between D and C++.

After Words

Starting a thread the D way is required because of the way memory is managed in D2. The garbage collector has to be aware of the existence of all threads. Some data structures are also built for each thread in D to allow message passing and various other things.

If we use shared with __dsfml_start_thread, the program doesn’t link anymore using gdc (and frontend v2.055). This is something that should be improved to help binding C++ and D.

In the same way, it is not possible to implement a C++ main because of D runtime. This is something to consider and a standard solution has to be provided by the D community in the future to help newcomers.

In order to compile and link theses examples, I use g++ and gdc both version 4.6. Building .o files isn’t difficult, but producing an executable at the end can be tricky. To do so, I used gdc and manually linked the C++ standard library using the switch -lstdc++ .

The modified version of SFML as been compiled in static as D2 doesn’t clearly define how to use shared libs at the moment.

I never succeeded in compiling a working executable using g++ and adding -lgphobos2 and/or -lgdruntime .

xfBuild Ported to D2

2011-11-24T12:06:35+00:00

Back when Tomasz Stachowiak was an active D’er (before he ran off and got a job at one of my favorite game development shops), he created xfBuild, a build tool for D. It was created with D1/Tango. Now, Andrej Mitrovic has ported it to D2/Phobos and slapped it up on Github. He insists that it’s in an alpha state and you shouldn’t use it on production code. I might just give it a whirl with my Dolce project. If anything blows up, I’ll be sure to let him know.

Dolce Gets Some Love

2011-11-17T13:11:00+00:00

Once the semester ended, I took a week to do nothing but play Dark Age of Camelot and get some much needed guitar practice in. Then I dove back in to the gym for some long overdue exercise. I also managed to pick up a few more private classes to fill some of the gaps in my schedule. Once I let off all that steam, I fired up...

Einstein's Riddle solutions in D

2011-11-15T01:46:59+00:00

[Update: the same text with colorized code: http://www.fantascienza.net/leonardo/ar/einstein_riddle.html ]

This post is about the D translation of two old little C++ programs, to show some differences in the idioms of the two languages, and to discuss a little about static typing too.

I have found the original C++ code in this page:
See also: http://www.weitz.de/einstein.html

Both C++ programs solve a logic problem named "Einstein's Riddle". Here you find more info about its variants:
http://en.wikipedia.org/wiki/Zebra_Puzzle

The original C++ versions are by Klaus Betzler and by Dr. Gabor Csanyi.

This post is not a discussion of the Einstein's Riddle, or of algorithms that solve it. The C++ code is about ten years old, so it doesn't use some of the handy features of modern C++0x, that are sometimes comparable to D features. So this is not meant to be a fair comparison between modern C++ and modern D V.2 language.

To compile the D code I am using DMD v.2.056 (or an alpha version of v.2.057 from GitHub).

See here for the complete C++ and D code:
http://www.fantascienza.net/leonardo/js/einstein.zip

Archive contents:
- einstein1.cpp: original first C++ (fast) solution.
- einstein1a.d: D translation of the first C++ solution.
- einstein2.cpp: original second C++ (slow) solution.
- einstein2a.d: first D translation of the second C++ solution. This contains a good amount of strong static typing. This uses more idiomatic D arrays.
- einstein2b.d: second D translation of the second C++ solution. This uses arrays that are more efficient but less idiomatic D.
- einstein2c.py: Python2 translation of the first D translation of the second C++ solution. This program is rather slow, even counting it's in Python, I don't fully know why.

==========================================

Comments on the first program (einstein1.cpp and einstein1a.d):

C> inline unsigned long BIT(unsigned n) {return 1<<n;}
C> 
C> const unsigned long
C>   yellow = BIT(0),
C>   blue = BIT(1),
C>   red = BIT(2),
C>   green = BIT(3),
C>   white = BIT(4),
C> 
C>   norwegian = BIT(5),
C>   dane = BIT(6),
C>   brit = BIT(7),
C>   german = BIT(8),
C>   swede = BIT(9),
C> 
C>   water = BIT(10),
C>   tea = BIT(11),
C>   milk = BIT(12),
C>   coffee = BIT(13),
C>   beer = BIT(14),
C> 
C>   dunhill = BIT(15),
C>   marlboro = BIT(16),
C>   pallmall = BIT(17),
C>   rothmans = BIT(18),
C>   winfield = BIT(19),
C> 
C>   cat = BIT(20),
C>   horse = BIT(21),
C>   bird = BIT(22),
C>   fish = BIT(23),
C>   dog = BIT(24);
C> 
C> const char * Label[] = {
C>   "Yellow","Blue","Red","Green","White",
C>   "Norwegian","Dane","Brit","German","Swede",
C>   "Water","Tea","Milk","Coffee","Beer",
C>   "Dunhill","Marlboro","Pallmall","Rothmans","Winfield",
C>   "Cat","Horse","Bird","Fish","Dog"
C> };

D> string bitFlags(BaseType=uint)(string enumName, string enumItems) {
D>     string result = text("enum ", enumName, " : ", BaseType.stringof, " {\n");
D>     result ~= text("    None = 0,\n");
D>     foreach (i, flag; enumItems.split())
D>         result ~= text("    ", flag, " = (1 << ", i, "),\n");
D>     return result ~ "}";
D> }
D> 
D> mixin(bitFlags!uint("E", "
D> Yellow    Blue     Red      Green    White
D> Norwegian Dane     Brit     German   Swede
D> Water     Tea      Milk     Coffee   Beer
D> Dunhill   Marlboro Pallmall Rothmans Winfield
D> Cat       Horse    Bird     Fish     Dog"));

The D version uses named enums, so D writeln is able to print their names, this avoids the need of the Label array. A simplified bitFlags compile-time function allows to create a simple enumeration of bit flags.

----------------------------------------------

C> const unsigned long color = yellow+blue+red+green+white;
C> const unsigned long country = norwegian+dane+brit+german+swede;
C> const unsigned long drink = water+tea+milk+coffee+beer;
C> const unsigned long cigar = dunhill+marlboro+pallmall+rothmans+winfield;
C> const unsigned long animal = cat+horse+bird+fish+dog;
C> 
C> unsigned long house[5] = {norwegian,blue,milk,0,0};  // rules 8,9,14
C> unsigned long result[5];
C> 
C> const unsigned long comb[] = { // simple rules
C>   brit+red,                    // 1
C>   swede+dog,                   // 2
C>   dane+tea,                    // 3
C>   green+coffee,                // 5
C>   pallmall+bird,               // 6
C>   yellow+dunhill,              // 7
C>   winfield+beer,               // 12
C>   german+rothmans              // 13
C> };
C> 
C> const unsigned long combmask[] = { // corresponding selection masks
C>   country+color,
C>   country+animal,
C>   country+drink,
C>   color+drink,
C>   cigar+animal,
C>   color+cigar,
C>   cigar+drink,
C>   country+cigar
C> };

D> enum E color =   E.Yellow    | E.Blue     | E.Red      | E.Green    | E.White;
D> enum E country = E.Norwegian | E.Dane     | E.Brit     | E.German   | E.Swede;
D> enum E drink =   E.Water     | E.Tea      | E.Milk     | E.Coffee   | E.Beer;
D> enum E cigar =   E.Dunhill   | E.Marlboro | E.Pallmall | E.Rothmans | E.Winfield;
D> enum E animal =  E.Cat       | E.Horse    | E.Bird     | E.Fish     | E.Dog;
D> 
D> immutable E[] comb = [ // simple rules
D>     E.Brit     | E.Red,     // 1
D>     E.Swede    | E.Dog,     // 2
D>     E.Dane     | E.Tea,     // 3
D>     E.Green    | E.Coffee,  // 5
D>     E.Pallmall | E.Bird,    // 6
D>     E.Yellow   | E.Dunhill, // 7
D>     E.Winfield | E.Beer,    // 12
D>     E.German   | E.Rothmans // 13
D> ];
D> 
D> immutable E[] combMask = [ // corresponding selection masks
D>     country | color,
D>     country | animal,
D>     country | drink,
D>     color   | drink,
D>     cigar   | animal,
D>     color   | cigar,
D>     cigar   | drink,
D>     country | cigar
D> ];

The D version uses | (or) instead of +, for better clarity. comb and combMask are not enums for more efficiency.

D> int main() {
D>     E[5] house = [E.Norwegian, E.Blue, E.Milk, E.None, E.None]; // rules 8, 9, 14
D>     E[5] result;

The D code defines 'house' and 'result' inside the main(), this avoids global mutable variables. 'house' is needed as argument by most functions, but the overall performance of the program is about unchanged.

'house' is an array of E enums, that are strongly typed, so I have had to add E.None, that is represented with 0.

==========================================

Comments on the second program (einstein2.cpp and einstein2a.d):

C> char *NationS[] = {"British", "Swedish", "Danish", "Norvegian", "German"};
C> enum Nation {British, Swedish, Danish, Norvegian, German};
C> char *NumberS[] = {"One", "Two", "Three", "Four", "Five"};
C> enum Number {One, Two, Three, Four, Five};
C> char *ColourS[] = {"Red", "Green", "Blue", "White", "Yellow"};
C> enum Colour {Red, Green, Blue, White, Yellow};
C> char *DrinkS[] = {"Milk", "Coffee", "Water", "Beer", "Tea"};
C> enum Drink {Milk, Coffee, Water, Beer, Tea};
C> char *SmokeS[] = {"PallMall", "Dunhill", "Blend", "BlueMaster", "Prince"};
C> enum Smoke {PallMall, Dunhill, Blend, BlueMaster, Prince};
C> char *PetS[] = {"Dog", "Cat", "Fish", "Horse", "Bird"};
C> enum Pet {Dog, Cat, Fish, Horse, Bird};

D> enum Number : ubyte { One,      Two,     Three,  Four,       Five   };
D> enum Color  : ubyte { Red,      Green,   Blue,   White,      Yellow };
D> enum Drink  : ubyte { Milk,     Coffee,  Water,  Beer,       Tea    };
D> enum Smoke  : ubyte { PallMall, Dunhill, Blend,  BlueMaster, Prince };
D> enum Pet    : ubyte { Dog,      Cat,     Fish,   Horse,      Bird   };
D> enum Nation : ubyte { British,  Swedish, Danish, Norvegian,  German };

In D enums are almost strongly typed, but not as strongly as C++0x "enum class" enumerations:

http://en.wikipedia.org/wiki/C%2B%2B0x#Strongly_typed_enumerations

In D writeln is able to print the name of named enums, so the arrays like PetS are not necessary. In D unsigned bytes are named "ubyte".

----------------------------------------------

C> void
C> myprint(char *ptr, char **s)
C> {
C>   printf("%12s%12s%12s%12s%12s\n", s[ptr[0]], s[ptr[1]], s[ptr[2]], s[ptr[3]], s[ptr[4]]);
C> }
...
C> main()
C> {
...
C> 		      // woo-hoo!
C> 		      printf("Found a solution:\n");
C> 		      printf("Nation: ");
C> 		      myprint(nation, NationS);
C> 		      printf("Number: ");
C> 		      myprint(number, NumberS);
C> 		      printf("Colour: ");
C> 		      myprint(colour, ColourS);
C> 		      printf("Drink : ");
C> 		      myprint(drink, DrinkS);
C> 		      printf("Smoke : ");
C> 		      myprint(smoke, SmokeS);
C> 		      printf("Pet   : ");
C> 		      myprint(pet, PetS);
C> 		      printf("\n");

D> void showRow(E)(in E[] data) {
D>     auto names = [EnumMembers!E];
D>     writefln("%6s: %12s%12s%12s%12s%12s",
D>              (Unqual!E).stringof,
D>              text(names[data[0]]), text(names[data[1]]),
D>              text(names[data[2]]), text(names[data[3]]),
D>              text(names[data[4]]));
D> }
...
D> void main() {
...
D>                                             writeln("Found a solution:");
D>                                             showRow(nation);
D>                                             showRow(number);
D>                                             showRow(color);
D>                                             showRow(drink);
D>                                             showRow(smoke);
D>                                             showRow(pet);
D>                                             writeln();
D>                                         }

D here is doing more at compile-time. The printing template function showRow is able to find the names of the enums and of their elements.

text() is used because formats like "%12s" are not yet supported (DMD 2.056) for enum members.

----------------------------------------------

C> char perms[][5] = {
C>   {     4,     3,     2,     1,     0},
C>   {     3,     4,     2,     1,     0},
C>   {     4,     2,     3,     1,     0},
C>   {     2,     4,     3,     1,     0},
C>   {     3,     2,     4,     1,     0},
C>   {     2,     3,     4,     1,     0},
C>   {     4,     3,     1,     2,     0},
C>   {     3,     4,     1,     2,     0},
C>   {     4,     1,     3,     2,     0},
C>   {     1,     4,     3,     2,     0},
C>   {     3,     1,     4,     2,     0},
C>   {     1,     3,     4,     2,     0},
C>   {     4,     2,     1,     3,     0},
C>   {     2,     4,     1,     3,     0},
C>   {     4,     1,     2,     3,     0},
C>   {     1,     4,     2,     3,     0},
C>   {     2,     1,     4,     3,     0},
C>   {     1,     2,     4,     3,     0},
C>   {     3,     2,     1,     4,     0},
C>   {     2,     3,     1,     4,     0},
C>   {     3,     1,     2,     4,     0},
C>   {     1,     3,     2,     4,     0},
C>   {     2,     1,     3,     4,     0},
C>   {     1,     2,     3,     4,     0},
C>   {     4,     3,     2,     0,     1},
C>   {     3,     4,     2,     0,     1},
C>   {     4,     2,     3,     0,     1},
C>   {     2,     4,     3,     0,     1},
C>   {     3,     2,     4,     0,     1},
C>   {     2,     3,     4,     0,     1},
C>   {     4,     3,     0,     2,     1},
C>   {     3,     4,     0,     2,     1},
C>   {     4,     0,     3,     2,     1},
C>   {     0,     4,     3,     2,     1},
C>   {     3,     0,     4,     2,     1},
C>   {     0,     3,     4,     2,     1},
C>   {     4,     2,     0,     3,     1},
C>   {     2,     4,     0,     3,     1},
C>   {     4,     0,     2,     3,     1},
C>   {     0,     4,     2,     3,     1},
C>   {     2,     0,     4,     3,     1},
C>   {     0,     2,     4,     3,     1},
C>   {     3,     2,     0,     4,     1},
C>   {     2,     3,     0,     4,     1},
C>   {     3,     0,     2,     4,     1},
C>   {     0,     3,     2,     4,     1},
C>   {     2,     0,     3,     4,     1},
C>   {     0,     2,     3,     4,     1},
C>   {     4,     3,     1,     0,     2},
C>   {     3,     4,     1,     0,     2},
C>   {     4,     1,     3,     0,     2},
C>   {     1,     4,     3,     0,     2},
C>   {     3,     1,     4,     0,     2},
C>   {     1,     3,     4,     0,     2},
C>   {     4,     3,     0,     1,     2},
C>   {     3,     4,     0,     1,     2},
C>   {     4,     0,     3,     1,     2},
C>   {     0,     4,     3,     1,     2},
C>   {     3,     0,     4,     1,     2},
C>   {     0,     3,     4,     1,     2},
C>   {     4,     1,     0,     3,     2},
C>   {     1,     4,     0,     3,     2},
C>   {     4,     0,     1,     3,     2},
C>   {     0,     4,     1,     3,     2},
C>   {     1,     0,     4,     3,     2},
C>   {     0,     1,     4,     3,     2},
C>   {     3,     1,     0,     4,     2},
C>   {     1,     3,     0,     4,     2},
C>   {     3,     0,     1,     4,     2},
C>   {     0,     3,     1,     4,     2},
C>   {     1,     0,     3,     4,     2},
C>   {     0,     1,     3,     4,     2},
C>   {     4,     2,     1,     0,     3},
C>   {     2,     4,     1,     0,     3},
C>   {     4,     1,     2,     0,     3},
C>   {     1,     4,     2,     0,     3},
C>   {     2,     1,     4,     0,     3},
C>   {     1,     2,     4,     0,     3},
C>   {     4,     2,     0,     1,     3},
C>   {     2,     4,     0,     1,     3},
C>   {     4,     0,     2,     1,     3},
C>   {     0,     4,     2,     1,     3},
C>   {     2,     0,     4,     1,     3},
C>   {     0,     2,     4,     1,     3},
C>   {     4,     1,     0,     2,     3},
C>   {     1,     4,     0,     2,     3},
C>   {     4,     0,     1,     2,     3},
C>   {     0,     4,     1,     2,     3},
C>   {     1,     0,     4,     2,     3},
C>   {     0,     1,     4,     2,     3},
C>   {     2,     1,     0,     4,     3},
C>   {     1,     2,     0,     4,     3},
C>   {     2,     0,     1,     4,     3},
C>   {     0,     2,     1,     4,     3},
C>   {     1,     0,     2,     4,     3},
C>   {     0,     1,     2,     4,     3},
C>   {     3,     2,     1,     0,     4},
C>   {     2,     3,     1,     0,     4},
C>   {     3,     1,     2,     0,     4},
C>   {     1,     3,     2,     0,     4},
C>   {     2,     1,     3,     0,     4},
C>   {     1,     2,     3,     0,     4},
C>   {     3,     2,     0,     1,     4},
C>   {     2,     3,     0,     1,     4},
C>   {     3,     0,     2,     1,     4},
C>   {     0,     3,     2,     1,     4},
C>   {     2,     0,     3,     1,     4},
C>   {     0,     2,     3,     1,     4},
C>   {     3,     1,     0,     2,     4},
C>   {     1,     3,     0,     2,     4},
C>   {     3,     0,     1,     2,     4},
C>   {     0,     3,     1,     2,     4},
C>   {     1,     0,     3,     2,     4},
C>   {     0,     1,     3,     2,     4},
C>   {     2,     1,     0,     3,     4},
C>   {     1,     2,     0,     3,     4},
C>   {     2,     0,     1,     3,     4},
C>   {     0,     2,     1,     3,     4},
C>   {     1,     0,     2,     3,     4},
C>   {     0,     1,     2,     3,     4}
C> };

D> const(T[][]) permutations(T)(in T[] items) pure nothrow {
D>     const(T[])[] result;
D> 
D>     void perms(in T[] s, in T[] prefix=[]) nothrow {
D>         if (s.length)
D>             foreach (i, c; s)
D>                perms(s[0 .. i] ~ s[i+1 .. $], prefix ~ c);
D>         else
D>             result ~= prefix;
D>     }
D> 
D>     perms(items);
D>     return result;
D> }
...
D> void main() {
D>     static immutable permsNumber = permutations([EnumMembers!Number]);
D>     static immutable permsColor = cast(immutable(Color[][]))permsNumber;
D>     static immutable permsDrink = cast(immutable(Drink[][]))permsNumber;
D>     static immutable permsSmoke = cast(immutable(Smoke[][]))permsNumber;
D>     static immutable permsPet = cast(immutable(Pet[][]))permsNumber;

Here I have used one of the peculiar features of D, the compile-time function evaluation. The C++ 'perms' array is just an array of all permutations of the [0, 1, 2, 3, 4] numbers. So I have written a little permutations() function (a function as commonly useful as this one, maybe as a lazy range, needs to be present in Phobos. Python has a similar generator in the itertools standard library module) that returns an array of all the permutations.

In D the enums are strongly typed, and the functions of this program work with strongly typed enums to avoid bugs, so I need different permutations of the enum members. Probably a good compiler is able to see all those immutable arrays contain the same bit patterns (despite being of different types), but this program iterates on them many times, so to be sure there is low pressure on the CPU cache, the other arrays are just aliases of the first one. I don't last casts a lot, because they are quite unsafe in D, but here I think they are acceptable.

The D 2D arrays like permsNumber are dynamic arrays of dynamic arrays of 5 enum members, that are represented with ubytes. In the C++ code perms is an array of fixed-sized arrays, this gives a bit higher performance to the C++ code. I have created another D version that solves this problem, but needs to use the arrays in a not D idiomatic way, see below.

----------------------------------------------

C> char
C> possible(char *number, char *colour, char* drink, char *smoke, char *pet)
C> {
C>   // Rules, with the rule number as a comment
C> 
C>   // single property rules
C>   if(number != NULL && number[Norvegian] != One) // 9
C>     return FALSE;
C>   if(colour != NULL && colour[British] != Red) // 1
C>     return FALSE;
C>   if(drink != NULL && drink[Danish] != Tea)  // 3
C>     return FALSE;
C>   if(smoke != NULL && smoke[German] != Prince) // 13
C>     return FALSE;
C>   if(pet != NULL && pet[Swedish] != Dog)    // 2
C>     return FALSE;

D> bool isPossible(in Number[] number, in Color[] color, in Drink[] drink,
D>                 in Smoke[] smoke, in Pet[] pet) pure nothrow {
D>     // Rules, with the rule number as a comment
D> 
D>     // single property rules
D>     if (!number.empty && number[Nation.Norvegian] != Number.One) // 9
D>         return false;
D>     if (!color.empty && color[Nation.British] != Color.Red)      // 1
D>         return false;
D>     if (!drink.empty && drink[Nation.Danish] != Drink.Tea)       // 3
D>         return false;
D>     if (!smoke.empty && smoke[Nation.German] != Smoke.Prince)    // 13
D>         return false;
D>     if (!pet.empty && pet[Nation.Swedish] != Pet.Dog)            // 2
D>         return false;

Here the stronger typing of the D enums allows to write safer code, with less chance for bugs.

Generally the D function uses const/immutable/pure/nothrow everywhere it's possible, this gives performance and safety.

==========================================

Comments on the second program, second version (einstein2b.d):

This is very similar to einstein2a.d, the main difference comes from the desire to increase the performance avoiding one pointer level using fixed-size arrays to represent the is various permutations.

D> import std.stdio, std.math, std.traits, std.array, std.conv;
D> 
D> 
D> const(T[N][]) permutationsFixed(T, size_t N)(in T[N] items) pure nothrow {
D>     const(T[N])[] result;
D>     T[N] row;
D> 
D>     void perms(in T[] s, in T[] prefix=[]) nothrow {
D>         if (s.length)
D>             foreach (i, c; s)
D>                perms(s[0 .. i] ~ s[i+1 .. $], prefix ~ c);
D>         else {
D>             row[] = prefix[];
D>             result ~= row;
D>         }
D>     }
D> 
D>     perms(items);
D>     return result;
D> }

The permutationsFixed() function returns an dynamic array of fixed size arrays.

----------------------------------------------

D> enum Number : uint { One,      Two,     Three,  Four,       Five   };
D> enum Color  : uint { Red,      Green,   Blue,   White,      Yellow };
D> enum Drink  : uint { Milk,     Coffee,  Water,  Beer,       Tea    };
D> enum Smoke  : uint { PallMall, Dunhill, Blend,  BlueMaster, Prince };
D> enum Pet    : uint { Dog,      Cat,     Fish,   Horse,      Bird   };
D> enum Nation : uint { British,  Swedish, Danish, Norvegian,  German };

The enums have uint as base type because it's about or more efficient than ubytes, in this program.

----------------------------------------------

D> bool isPossible(immutable(Number[5])* number,
D>                 immutable(Color[5])* color,
D>                 immutable(Drink[5])* drink,
D>                 immutable(Smoke[5])* smoke,
D>                 immutable(Pet[5])* pet
D>                 ) pure nothrow {
D>     // Rules, with the rule number as a comment
D> 
D>     // single property rules
D>     if (number && (*number)[Nation.Norvegian] != Number.One) // 9
D>         return false;
D>     if (color && (*color)[Nation.British] != Color.Red)      // 1
D>         return false;
D>     if (drink && (*drink)[Nation.Danish] != Drink.Tea)       // 3
D>         return false;
D>     if (smoke && (*smoke)[Nation.German] != Smoke.Prince)    // 13
D>         return false;
D>     if (pet && (*pet)[Nation.Swedish] != Pet.Dog)            // 2
D>         return false;
D> 
D>     // only check complicated rules, if everything is defined
D>     if (!number || !color || !drink || !smoke || !pet)
D>         return true;
D> 
D>     // double property rules
D>     foreach (i; 0 .. 5) {
D>         if ((*color)[i] == Color.Green && (*drink)[i] != Drink.Coffee)    // 5
D>             return false;
D>         if ((*smoke)[i] == Smoke.PallMall && (*pet)[i] != Pet.Bird)       // 6
D>             return false;
...
D> void main() {
...
D>     foreach (ref number; permsNumber)
D>         if (isPossible(&number, null, null, null, null))
D>             foreach (ref color; permsColor)
D>                 if (isPossible(&number, &color, null, null, null))

Normally in D you pass static arrays efficiently using "const ref T[N]", but in this program also nulls must be supported. So I have had to perform some experiments to find a flexible enough but efficient way to give them to the isPossible() function.

So I pass them as pointers to immutable fixed size arrays:

D>                 immutable(Color[5])* color,

They are pointers to arrays (so they are like C/C++/D1 fixed size arrays), so they are efficient, despite this is a not idiomatic way to use arrays in D.

To use the array items you need to deference the pointer first:

(*color)[i]

An alternative syntax, but it's less natural because the first isn't really an array of size 1, it's a pointer to an array:

color[0][i]

==========================================

Some benchmarks:

Runtime timings, seconds:
  einstein1.cpp:  0.01
  einstein1a.d:   0.05
  einstein2.cpp:  0.70
  einstein2a.d:   1.09
  einstein2b.d:   0.76
  einstein2c.py: 19.03 (with Psyco)

DMD 2.057 head

G++ 4.6.1
Python 2.6.6

Celeron 2.3 GHz, 32 bit OS.

----------------------------------------------

Strong static typing is useful, but it often also requires lot of work. In practical D programs I try to find a balance point in the amount of strong static typing I use, to avoid wasting some of my time. Yet, as I get more experienced in programming, I like to express more and more code invariants in statically enforced constraints, like the ones of a static type system, because despite they ask me lot of work, they help me avoid some bugs.

So "Make illegal states unrepresentable", as it's said here regarding OCaML code:
http://ocaml.janestreet.com/?q=node/85

So write your code to turn the illegal states into static errors.

Type Qualifiers and Wild Cards

2011-11-07T10:47:00+00:00

Type qualifiers are modifiers applied to data types.

Language Promotion

2011-11-02T16:05:49+00:00

The D Programming Language has a long way to go for wider adoption despite it isn’t exactly new. As I mentioned in the initial post C/C++ will dominate the native language arena for general purpose programming. The reasons are not as much theoretical than technical and historical ones.

I launched this blog with the very intention to promote D and this way contribute to the process of raise this programming language to the arena where C++ has no really competition at the moment. Unfortunately, for doing this, we need to employ some PR too. As a coder, all I need to be impressed is lines of code, simple, but straightforward text to identify the “beauty” of a programming language but I’m also aware that for spreading the word, the packaging matters a lot.

Digital Mars does a very poor job on this. When I first tried the D programming language I navigated to the Digital Mars’ website and… I almost dropped my idea of getting familiar with D. At the very moment you look the home page of D you will realise that poor people at DM have no web designer around who would keep that website in some humanly tolerable shape. Coder geeks tend to ignore the power of consumable outlook, but this is even worse. The whole site looks as it was the first attempt of some 14 years old kid to create website from a set of HTML code in notepad adding some incredibly lame graphics hacked together in MS Paint.

As a result, the structure is almost completely missing, the forums are rather counter-intuitive, honestly, it’s rather embarrassing. If I wasn’t so busy with my life, I would donate a useful website design with a comprehensive structure. I’m not a web designer by any means, but I can do better than that. So, if anyone out there could spend a little time on this and contribute to this majestic cause, please go for it ASAP!

There’s a sharp contrast between the D’s inner beauty and the way it’s treated. How can someone possibly hope for building a community around a language which has a completely repellent website?

Fortunately, later on a new website appeared which is trying to make it up for this shocking experience. Well, it looks a bit better, but I have no idea why is it a separate one which is pointing to the old one at plenty occasion. Where a community could be fostered it’s still sucks. But at least the logo worth to look at. Many people before me stated already, but I can’t emphasise the following: the name “D” was a terrible choice. Perhaps, if things get really serious, as a beginning of a new life Water would re-baptise it, though this looks quite unlikely, pity for many.

Oh, and please consider this as a good advice anywhere you need to use some iconic graphics for D, forget the following images:

Too childish, too amateur for a language that should conquer the world. You can find better ones:

The images above can be also found on this worthy, but quite hidden site. With this, I stop my rant for a while…

Why D?

2011-10-28T09:11:23+00:00

This blog is dedicated my work on the D Programming Language. Though my self had not even worked on a project and coded serious stuff in D I can see the possibilities and the real need of such a programming language. If you don’t know what is D, please refer to the official website.

I think when Walter Bright come to the conclusion that there’s a need for a multi-paradigm, imperative, native language, he made the right choice. As a C++ developer myself, I found several frustrating issue with my main programming language and with all the efforts of the recent C++11 standard these pains doesn’t seem to pass. I don’t want to bash C++: it’s a nice piece of language which stays prominent for many years if not decades, but I think today, in 2011 we need to prepare ourselves to learn from the mistakes of the past, and have a clear start. C++ is dragging many compatibility issues with it self along its long way, and therefore a new language design, free of such a heavy burden could mean a fresh start in the native development.

As of today, the most prevalent programming languages in the native arena is C and C++. C is good as it is, restricted system programming language which fit most of the hardware environment. C++ on the other hand, though it made an astonishing progress with the C++11 standard, has major flaw: it just doesn’t hold the challenge against the world of Java and C# world. These programming languages became success not because of their revolutionary new technology but from rather the fact that they can keep the developers happy and enthusiastic. All this is because it was easy to produce a wide variety of coding tools that makes the development fun. In order to maintain the momentum of the native development, we need to get the fun back to the native development.

C++ unfortunately can not offer such an easy entertainment. As a project is getting more and more complicated the build time grows enormously. It desperately calls for a module system. The parsing is difficult because the extent and ambiguity of the C++ grammar. The compiler can be hardly manipulated, the reflection system is partial, and a language level garbage collector would just make life easier for everyone if the coder can decide to not use it in certain, well limited scenarios.

In this series of blog post I document my experiments, understanding and contribution to the language D.

Planet D

DerelictFreeGLUT

dpj – A Mini-IDE for D

Binding D to C Part Three

Derelict 3 Deb Package

Voldemort Types In D

vibe.d

libgc-d version 1.0 released

libffi-d version 1.0 released

New Bindings in Derelict 3

DMD 1.074 and 2.059

A simple usage example of Haskell type classes and D templates

Introducing libgc-d

Setting Thread Affinity on Windows in D

Library News Roundup

Uniform Function Call Syntax

Thrift now officially supports D!

Get an exception from a segfault on linux (x86 and x86_64), using some black magic !

It is not that simple

Let’s fool linux into calling our code when returning from the handler !

Our userspace handler cannot be a regular function, that would be too easy

Wait a minute. And what if EIP is causing the segfault ?

So we finally get somewhere to handle that segfault !

What about x86_64 ? What about recovering ?

GDC Now on GitHub

Pegged

Visual D 0.3.31

Putting D's Array Slices to Use

BorderWatch

Impact of 64bits vs 32bits when using non precise GC.

Non precise GC, and how false positive happens

A program that generate garbage and store how much memory it use

Result on 32 bits

Lets switch to 64 bits !

Conclusion

Compiling Data into a D Executable

Mono-D 0.3.0

Inheriting Purity

A review of D2 – constness and immutablility

Immutability and constness in D2

Immutability

Conciliate mutable and immutable world : const

Going further with inout, a scope defined type qualifier

Existing code that has been written without const or immutable in mind.

A widely spread misconception in the D community : const cannot qualify a function

Conclusion

Mono-D 0.2.9

DMD 1.073 and 2.058

D Forums

Comments Temporarily Moderated

Getting Started With D

The hashtable closure pattern

An explanation of the pattern and when it can be used

Implementation in PHP and D

Building on that pattern

Derelict on GitHub

Tango For D2

Binding D to C Part Two

A Tutorial on Templates

getaddrinfo cross-platform edge case behavior

D:GamesVFS

A Tutorial on Ranges

DWT Moved to GitHub

Binding D to C

Visual D 0.3.30

D Version Manager 0.4.0

Happy New Year

Targeting OS X 64 Bit

Dolce and Da5teroids

Dice and random sources

Derelict Updates

DMD 1.072 and 2.057

News Roundup

Reading PDFs on the Kindle Fire

Updates and links

Interfacing D with C++ : start new thread

The main function

The C++ thread class

Start a thread the D way

After Words

`getaddrinfo` cross-platform edge case behavior