Derelict and @nogc

I’ve begun the process of adding support for @nogc in a backward-compatible way for all of the Derelict packages. For now, I’ve added it to all branches of the SDL2, GLFW3 and GL3 bindings. More will come over the next few days. I’ll also try to make sure that I’ve got all of the bindings appropriately updated, branched and tagged.

Note that the @nogc attribute is only applied to the function pointers and not to any of the loader methods. It’s probably fine to add it to some of them (such as isLoaded). I’ll need to do a sweep at some point to add @nogc and other attributes to the loaders where appropriate, but for now it is not a priority.

If you are maintaining a Derelictified binding and want to take advantage of backwards-compatible @nogc, you’ll need to import derelict.util.system. Then you can add @nogc to your extern(C) function pointer declarations, but it has to come before nothrow if you want it to compile with anything other than DMD 2.066. To be backwards compatible, it’s implemented as a UDA when not using 2.066, and UDAs must be declared first in the attribute list.

Derelict News

In the past few weeks I’ve added a couple of new members to the DerelictOrg team.

Ben Boeckel has volunteered to take on a binding for OpenGLES. You can see the result of that in the DerelictGLES repository. Note that this is still a work in progress.

I’ve also brought ponce aboard to implement a couple of his derelict-extras packages under the DerelictOrg umbrella. For now, that includes both DerelictENet and DerelictBgfx.

I finally got around to tagging DerelictGL3 releases. When you are setting up your dub dependencies, you should now use "derelict-gl3": ">=1.0.0" rather than "derelict-gl3": "~master". I’ve gotten release tags on other Derelict packages as well (though not all, yet), but I’ll announce all of that later once I’ve got some documentation to lay it all out. Did I ever mention how I hate writing documentation?


If you’re looking to do any video work with libtheora, I’ve added a binding for it to Derelict. It’s been on my ToDo list for a long time. A couple of recent requests were enough to get me going on it.

Note that if you aren’t using dub to manage you’re project, you’ll need to have DerelictOgg handy when compiling DerelictTheora. At runtime, you’ll also need the libogg shared library around, since libtheora depends on it (though you don’t need to load it yourself).

With dub, you can add a dependency for “derelict-theora”: “>=0.1.0″ for now. Consider this an untested beta for now, because that’s exactly what it is. Once I’m sure any bugs have been fixed and all the kinks worked out, I’ll branch it and tag a 1.0.0 release.

Speaking of tags, I’ve been slowly tagging releases on the existing packages. Most recently DerelictGL3, DerelictGLFW3 and DerelictOgg have all gotten 1.0.0 tags. For DerelictGL3, you can use >=1.0.0 as your dependency. For the other two, you’ll want a more constrained version: ~>1.0.0.


Important DerelictSDL2 Updates

I mentioned in my last post that I would be changing the way I handle versioning in Derelict in order to keep in line with upcoming changes in dub. DerelictSDL2 is the first package for which I’ve implemented it. Here’s what it looks like and what you should do.

Current Branches

  • master — Ignore this. It should no longer be used as a dependency. It will continue to work for a while yet, but the next dub release will deprecate branch dependencies. They will be removed entirely in a future version of dub.
  • 2.0.0 — This branch binds to version 2.0.0 of SDL2. For DerelictSDL2 versioning, it is tagged as 1.0.0. Future tags, if needed, will be 1.0.x, but never 1.1. If you want to require SDL2 2.0.0 as the minimum required version for your app, this is the branch you shoud use. Your dub dependency should be "derelict-sdl2": "~>1.0.0", which will ensure that you get the latest 1.0.x and never 1.1. Unless you need any new functions in later versions of SDL2, I strongly recommend you use this branch as your dependency. It will load all 2.0.x versions of SDL2.
  • 2.0.1 — This branch binds to version 2.0.1 of SDL2. For DerelictSDL2 versioning, it is tagged as 1.1.0. Your dub dependency should be "derelict-sdl2":"~>1.1.0", which will ensure you get the latest 1.1.x. If you need the API additions in 2.0.1, this is the branch to use.
  • 2.0.2 — This branch binds to both version 2.0.2 and 2.0.3 of SDL2 (there were no additions to the API in 2.0.3). For DerelictSDL2 versioning, it is tagged as 1.2.0. Your dub dependency should be "derelict-sdl2":"~>1.2.0", which will ensure you get the latest 1.2.x. You really should be using this branch only if you need the 2.0.2 API additio

Again, and I really want to stress this, the 2.0.0 branch can load the 2.0.3 version of SDL, but the reverse is not true. If you depend on the 2.0.2 branch of Derelict, your users will see errors when trying to load earlier versions of the SDL shared library (unless you use the selective loading mechanism, which I still need to document). So unless you need the newer functionality, always depend on the 2.0.0 branch (version 1.0.0).

I plan to write up a tutorial this weekend detailing how to get started with DerelictSDL2 and dub for newcomers. After that, I’ll start looking at branching and tagging the other packages. I’m only intimately familiar with a handful of the Derelict bindings. I don’t actually use most of the libraries Derelict binds with, so I’ll need to do some digging to make sure I’ve got the very latest of each and that I understand the versioning. DerelictUtil and DerelictGL3 are special cases and will not have any branches. Tags will all be pushed to the master branch (they already are in DerelictUtil).

On a related note, I’ve had second thoughts about importing the old Derelict forum data. I’m going to be looking for a different solution, I think. I’m moving slowly, but I’ll get a new forum set up before the next century.

Derelict Versioning

There is going to be a change in upcoming versions of dub that deprecates “~branch” dependencies. Currently, my plan for Derelict revolves around using branches, rather than tags, for many of the Derelict packages so that binding versions match those of the libraries they bind (i.e. the 2.0.1 branch of DerelictSDL2 is implemented against SDL 2.0.1). With the deprecation, I’m going to have to change that scheme such that each Derelict package will have its own version numbers. It also means that you shouldn’t be using “~master” as a dependency anymore. I’m looking for the most painless way to handle this, as there are potential issues, but I believe there’s a good way to go about it.

This is just a heads up that a change is coming and you will eventually need to modify your project dependencies to take advantage of it. It’s not just Derelict that will be affected by this, as every package in the dub registry that isn’t currently tagged will need to be updated. I’ll post here when I start making the changes.

The One With D Redux

After dealing with a highly annoying malware infection and having an unsatisfactory experience with my shared hosting provider, I’ve set the The One With D up on a VPS at Linode. It’s been quite a while since I’ve done any sort of server administration. I had to reeducate myself quite a bit, but I’ve actually enjoyed it. Thanks to Feedburner, existing feed readers should pick the new posts up just fine now.

Notice that I said “set up” and not “moved” in the paragraph above. Given the nature of the intrusion at the shared host, I decided that I can’t trust the database. Rather than going the extra mile and making sure the database is clean, I decided to abandon it. I’ve backed it up in case I change my mind at a later date, but I think it’s best to start over from a clean slate.

With that, I’m also going to change my focus here. When I first started this blog, my goal was to do more than regurgitate newsgroup announcements. I was going to write about my experience with D, post code snippets, interview other D users and more. Over time, it became less and less of that stuff and more of posting announcements from the newsgroups– and even that has tapered off the past year or so as I keep putting posts off until later.

For the first few years, reposting announcements was a good role to fill. D didn’t have the prominence back then that it does today. Things have changed, though. Now, everything posted in the announce group also winds up on Reddit and HackerNews, which reach many more than this blog. There’s also some movement toward putting together a monthly summary of D news, including announcements from the newsgroups and info on github activity (an effort I’m silently cheering on from the sidelines). So the niche I was filling doesn’t really exist anymore.

So I’m taking this malware problem as an excuse to reboot. No more focus on D news. I’m going to start writing about things I enjoy using D for, things I’ve learned in the process, and generally whatever the hell I want to say about The D Programming Language (which, I am convinced, is somehow connected to the number 42). And without feeling guilty if I don’t post for a month!

On a related note, the Derelict forums will be coming back online shortly. I do want to keep the database in that case. I have high confidence that it’s clean. I’ll want to do my utmost to verify that before getting it up and running again. However, I will take this opportunity to move it out of the dblog subdomain, most likely into one of it’s own. More to come.