Some photos of our recent trip to to Andalusia, Spain.  Here we visit Montefrío, a town hidden in the mountains boasting a fascinating round, domed church and an old Moorish fort.

To complicate the situation more, the technique required depends on the version of D you are using.
DMD version 2.060 is out and with it comes the deprecation of std.algorithm.indexOf. Instead, std.algorithm.countUntil should be used in its place.

Here is an example:

import std.stdio;
import std.algorithm;

void main(string[] args) {

	auto items= ["item1", "item2", "item3"];
	writeln(items);
	auto index = countUntil(items, "item2");
	writefln("Index of 'item2' is: %d", index);
	auto mutated = remove(items, index);
	writeln(mutated);

}

It generates the following output:

["item1", "item2", "item3"]
Index of 'item2' is: 1
["item1", "item3"]

CMake Error at cmake/FindD.cmake:41 (message):
  D compiler is not found
Call Stack (most recent call first):
  CMakeLists.txt:65 (FIND_PACKAGE)

This is strange because DMD is installed. After some investigation I found that the compiler isn’t found because the cmake file (cmake/FindD.cmake) searches for the version using a regex in the output to “dmd” (around line 13):

string(REGEX MATCH "(Digital Mars|DMD32) D Compiler v[0-9]\\.[0-9]+" dmd_version "${d_output}")

This is the guilty line. When I type “dmd” on my command line, the first line looks like this:

DMD64 D Compiler v2.060

This clearly doesn’t match the above regex. To fix the problem you can modify the regex above in the file “cmake/FindD.cmake” to look like the following:

string(REGEX MATCH "(Digital Mars|DMD32|DMD64) D Compiler v[0-9]\\.[0-9]+" dmd_version "${d_output}")

This fixes the problem.

I have fond memories of playing Manic Miner and Jet Set Willy on this machine, as well as writing out computer programs from magazines.  This little box of circuits is probably what launched my interest in computing and inspired me to learn how to do programming.

Notice that the chiclet keyboard has come back into fashion, albeit without the rubbery keys that would sometimes get stuck, or just wouldn’t respond.

Look how things have changed over 30 years and imagine where we’ll be in 30 years time.

Anyway, enough reminiscing… happy birthday!

I am currently working on a Ruby project that uses a lot of regexes on large volumes of text.  It is currently running too slowly, so I decided to try to optimise it by implementing the regex matching code in the D programming language.  D has given me a lot of joy (compared to C or C++)  by making things like string (with Unicode) handling a breeze without taking the performance hit of supposed “productivity” languages.  I painstakingly reimplemented my Ruby functions in D expecting a huge performance boost (actually I expected an order of magnitude performance jump) but instead I was shocked to see that Ruby outperformed my D code by a significant margin.  The Ruby implementation was finished after 80 seconds, whereas the D program required around 280 seconds using the exact same regexes and the exact same input.

I am not being a Ruby fan boy here, actually I will be the first in line to give you a long list of complaints I have with it, so please don’t view this as a “Ruby is awesome, everything else sucks article”.  It is also entirely possible that I am doing something really dumb in my implementation.  I’d like to ask if anybody out there has done any benchmarking with D (especially in the realm of regexes) if they know what might be going on and if there are known performance problems.  I will try to post my code (in Ruby and D) as soon as possible

Just as an aside, the D programming language is a very interesting language and if you haven’t already played with it then you really should.  I can also highly recommend Andrei Alexandrescu’s superb book “The D Programming Language”.  There is, quite simply, no other book of this caliber about the D programming language.

Update 26 March 2012:

Apparently comments weren’t working on my blog, so sorry about that (the captcha plugin was sort of half activated, so I just switched it off until I get around to fixing it properly).  You are now able to comment on this post.  I got a nice email telling me that some people were curious over at the official D forums about my problem.  It seems that my post caught Andrei’s eye, so I thought I should get on with it and post my code and not leave people speculating on the forum.

The problem was as follows:  I was unable to post my work because it contained proprietary code and the data I was using was also somewhat sensitive, so I had to spend some time recreating the problem with “postable” code.  I recreated the problem using different input data and new regexes where I found D to vastly outperform Ruby.  This made my both happy and sad at the same time because I still needed to recreate the problem somehow.

My code loads a file from disk, stores the contents into an array and runs a series of regexes against each line in turn.  The time taken is only measured during the regex phase (so the file loading isn’t counted).  I don’t care if the regexes match or not, but I always run every regex against every line.  The regexes are the same in the Ruby and the D code (unless I’ve made a horrible mistake).

In the D code I am not using Compile Time Regexes, and my Regexes are cached before the test (i.e. I am not  recompiling them on every loop iteration).  Additionally,  I am using the more recent std.regex package and not the deprecated std.regexp package.

I am using Ruby 1.9.2 and the Digital Mars D compiler v2.054

I perform the test twice, once for a more or less random CSV (actually pipe delimited, but that doesn’t really matter) file and secondly for the Complete Works of Shakespeare in text format.  Actually, I stop after just 2000 lines because the performance difference is already obvious.  The regexes used are always the same.  The performance is very much dependent upon which input file I use:

With CSV file input:

D Program: 55,813 ms

Ruby Program: 4851 ms

With Shakespeare text:

D Program: 1973 ms

Ruby Program: 4683 ms

Maybe if somebody could take a look at my code you could tell me if I’m doing something dumb or not.

All the code and test files can be downloaded here: Benchmark.zip

Update 27 March 2012: The more recent v2.058 DMD compiler doesn’t suffer this performance problem anymore.  I just tested it and it now runs significantly faster than Ruby in both scenarios.  Thanks for the support in the D forums!

In the olden days you could pick up a tape cassette containing a Spectrum or Amstrad game for a few pounds (yes, I’m British).  At this time, the gaming industry was in its infancy and the business side of the game was highly underdeveloped.  Games were written by a single (or a very small group) in squalid conditions and these programmers were like rock stars, or mad scientists working alone in their lab (complete with the associated lightning and electrical apparatus).  Some games turned out to be “smash hits” (Monty Mole, Manic Miner, Dynamite Dan to name a few), others were of very poor quality but hey, that’s the price you pay for experimenting.  How things have changed!

More recently creativity in game design went through a really stagnant phase with developers churning out platform games and more recently first person shooters and over the shoulder shooters.  The PC game Doom was an incredible step forward in gaming at the time, but it has spawned (through no fault of its own) a genre that now dominates the gaming industry.  Graphics standards began to rise and this meant larger and larger teams, now approaching the team sizes required to make a movie (actually game making and movie making now have a huge amount in common, but that is the subject for another post).  To fund these endeavors, huge companies such as EA, Ubisoft and Activision are active in video game marketing and promotion.  Big gaming companies don’t like to take big risks with their money and prefer to spend it on formulae that are tried and tested, usually pumping out sequels and variants.  This strategy has resulted in the growth of gaming franchises such as Modern Warfare and Call of Duty.  New games are inevitably tied in with the franchaise so as to guarantee high sales volumes.

Indy gaming on the PC has somewhat of a renaissance in recent years.  With the development of smart phones and tablet PCs where the average Joe has access to the development tools, we’ve seen an enormous growth in the independent gaming scene.  Another avenue for independent game developers has been social media platforms such as Facebook which allow gaming to be integrated with the social experience.  You don’t need hundreds of programmers to write your own games for these platforms and, I suspect, this has drawn many a disillusioned game programmer back out of the closet which they climbed into during the late nineties.

Mark from the Classic Game Room HD explains how Gamers can pick up affordable games for the iPod, which is how it used to be for the Atari 2600.

Zynga has turned, with its partnership with Facebook, into an extremely profitable company.  It develops games for social media web sites and is just one of many growing companies developing for the casual gamer.

On-line distribution now means that the humble PC programmer can start a games company and begin doing what they love creating games.  Steam, the on-line game distribution system, has also started selling independent games.  They have a very large market share in the on-line game distribution market and their catalog of games includes a large and growing number of games from developers that we’re probably unheard of just a few years ago.

Smaller game companies such as Paradox Interactive also stand gain by the reduced distribution costs promised by platforms such as Steam.  Companies such as these can focus their efforts on producing games for their market niche, keeping their fans very happy, and not have to spend millions on packaging and distribution.

With gamers becoming increasingly disenchanted with the large game publishers pushing draconian Digital Rights Management schemes down people throats, market conditions seem perfect for a renaissance of the independent gaming scene that has been ticking along very quietly in the background.  If companies and individuals are able to produce high quality games for a reasonable price and still turn a good profit, this can only be good news for the industry and gamers alike.