I started my social coding journey on bitbucket.org. Already using some code from there it was just a matter of time until I felt the need to submit a patch anyway. So I thought “let’s try this fancy stuff everyone is talking about”.
A fork and a few patches and pull requests later I must say I like it. It feels more user friendly from the source control point of view (I guess Mercurial as a distributed version control system helps here). But it feels also much more alive thanks to this social aspects. I got a list of projects and people I can follow and I can comment patches and even specific code lines of others.
And now there is ohloh.org. They even take it one more step forward. This site is not so much about the code in terms of developing but in terms of analyzing it and socializing it. I can add projects here and they try to analyze how many people are/were working on it. They apply metrics to say something about the code quality it has and how alive it is. They even got those crazy calculations how much a project is worth in respect to the work hours it took. They estimate Firefox worth $88m. But one of the most interesting aspects of ohloh is that you can even find out who else is working on similar projects near you. This is especially funny since you find a lot of familiar faces there and more often than I’d imagined they were not as old and not even as far away as I thought.
All in all I think the times are great to collaborate. I wish I had more time for this

I published a little open source tool that i wrote to help me messing with OpenCL source files: clcompile

Visit me on bitbucket at www.bitbucket.org/Extrawurst
Visit me on ohloh at www.ohloh.net/accounts/Extrawurst

I must confess I wasn’t expecting much after my last experiences with a SWT port. But DWT really is mature. I got it to build very fast and the snippets helped me a lot learning the usage. The lib design comes more natural to me than gtkD and I had the same results in a fraction of the time it took me to tame gtkD. Now my CLInfo Tool³ is DWT based.

DWT in short

Pro:

• Much more intuitive design – I didn’t even miss the gui designer
• Better documentation with a lot of example snippets
• No need to ship a bunch of dependencies with the binary

Con:

• Not absolutely everything of the SWT is ported yet
• No gui designer
• Build script uses rake⁴ – one more dependency for users of the lib

All in all my conclusion for now is going with DWT for GUI applications in D. At least if it stands the test under linux. But that is still to come..

1. post about gtkD
2. DWT project page
3. CLInfo Tool Page
4. rake project page

There is one very mature GUI lib called DFL¹ for D2 available but it has one big inconvenience: it is not platform independent, it is Win32 only. The first revisions of my CLInfo² tool are written using it. It made me feel home immediately. It is structured like all the libraries for Win32 I was used to: Delphi VCL, MFC and .Net Win Forms.

Now it is not as if there are no platform independent libraries for D out there in development, like DWT³ , QtD⁴ or GtkD⁵ . But the main problem is that most of them are either not ported to D2 or simply still too immature.
Recently I decided to give GtkD another try because it was released in a new version⁶ . And well what can I say. It works. Well at least I was able to to compile it without any hassle which is nothing natural looking back to all those times I already tried them before.
So nothing was stopping me from messing around on those unknown grounds anymore… I thought…
Well as I said I was used to the Win32 way GUI for my whole life and as it turns out this is a quite different way compared to the open-source gimp Gtk way.
At first I tried to follow some tutorials teaching me how to programmatically set up my UI which evolved to a disaster when the UI got more complex than having a bunch of buttons and a list with a menubar.
Then I learned about the Glade Designer⁷ which felt quite familiar to what I was used to. But I used the wrong export format, apparently libglade and the glade file format was deprecated and no one told me .
Back to square one. Now I use the gtkBuilder and the according file format. But the code using this still feels quite alien to me.
Anyway I finally got the same UI I had on windows using GtkD and hypothetically my tool should now build and run under Linux too. Guess that is the next journey to come

1. Website DFL
2. Website CLInfo
3. Website DWT
4. Website QtD
5. Website GtkD
6. Announcement of GtkD 1.4
7. Website Glade

• CL_DEVICE_SINGLE_FP_CONFIG
• CL_DEVICE_QUEUE_PROPERTIES
• CL_DEVICE_TYPE

All three of them have types defined as enums and those values are used as bitfields (or masks) so the driver can support multiple values of these.

To support such bitfields in my application i wanted to come up with convenient generic method and D enables me to do so using meta programming techniques:

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

string[] bitfieldToStrings(T)(T _val)
	if( is(T == enum) )
{
	string[] res;
 
	foreach(mem; __traits(allMembers, T))
	{
		auto memValue = mixin(mem);
 
		if( (_val & memValue) == memValue)
		{
			res ~= mem;
		}
	}
 
	return res;
}

This template method returns an array of which enum members are masked in the given value (as a string array). I want to emphasize some parts of this function which for me make D code so elegant and clean (especially compared to C++):

1. Contracts(Line 2): C++0x dismissed them, D has them for almost a year. Here i want to make sure the template will only be used with enum types.
2. Strings(Line 4): D has first class strings (array of immutable chars) which makes my life a lot easier.
3. Foreach(Line 6): What is there more to say ? Just convenient.
4. Compile time reflections(Line 6): __traits is a pity of a name for such a powerful construct which in this case returns an array of strings of all members of a given type (in this case our enum)
5. Automatic type inference(Line 8): C++0x finally has it too. But it is too new to be used platform independently. D has it since dawn of time.
6. String mixin(Line 8): Some may argue this is a hackish concept but for me it came in handy very often. Here we mixin every member of the enum to check if it is masked in the given value.

Download the current version on the CLInfo Page.