After I merged a pull request for DerelictPQ, I realized something I had never noticed before. The binding was quite inconsistent with the rest of Derelict. The number one philosophy behind a Derelict binding is to remain as consistent as possible with the original C library, so that any C code using the library can be easily ported to D. DerelictPQ went against that by using named enums. There were some stylistic issues as well.
As a first step toward fixing this, I created a new branch of DerelictPQ called deprecated-93, added the PR changes there, and tagged a new 1.0.2 release. Those who need, or want, to continue using it can. I will not be making any updates there from here on out.
Next, I went through the pq.d module and made all enums anonymous. The enum names are now aliased to int. This is how the rest of Derelict does it. I could have taken a different approach and fixed it in a way that maintains backwards compatibility, but it would have been stylistically different from the rest of Derelict. So I opted to break things. I also removed some enum declaration which were apparently added for convenience, as they do not exist in the C headers. This is also a breaking change. I also made some other changes, such as making all of the C functions @nogc, that weren’t breaking.
Because of the breaking changes, I’ve tagged a new 2.0.0 release. If you’ve been declaring your derelict-pq dependency in your dub.json using ~> or == with the version number, you should be able to keep right on with what you’ve been doing. If you’ve been using >=, then next time you run ‘dub upgrade’ on your project things will break. You can change your dub.json to use 1.0.2 as the explicit version (there will be no more updates in that series) or fix your code to use the new 2.0.0 enums.
The binding is still against libpq 9.3. The latest release is 9.5.0. At some point, I’ll get around to diffing the headers from 9.4 and 9.5 with 9.3 to see if I need to add anything to the binding. That may entail new branches and new major version numbers for DerelictPQ. I’ll post any updates here as usual. But this is not a priority for me, so it isn’t happening soon.
I learned a major lesson from this. I need to pay more attention when adding third-party packages to DerelictOrg.
For several months now, partial support for SDL 2.0.4 has existed in the SDL-2.0.x branch of the DerelictSDL2 repository under the 1.9.x series of tags for the DUB registry. This branch also included support for loading SDL with SharedLibVersion. Now that SDL 2.0.4 has been officially released, and that I’ve finally gotten around to it, I’ve updated everything and tagged a new 2.0.0 release.
The SDL-2.0.x branch is no more, having been replaced by a branch named 2.0.4. I’ve gone through and updated the binding with any missing functions and types. I’ve also updated the master branch so that it is now in sync with the 2.0.4 branch. I also reset the master branch as the default. I’ll be doing that with any other of the Derelict repositories where master is no longer the default. It’s too confusing otherwise.
Because of the SharedLibVersion support, you can now load older versions of SDL 2.x with DerelictSDL2. Of course, if you take that route, it’s your responsibility to be aware of which enum values or union members and such were added in which version. You should also be aware of struct size differences, as some fields have been added to some events since the first SDL 2.0.0 release. It should all just work for normal use cases. If you are doing anything abnormal with events, though, watch out.
Another point to be aware of is that I have made only minor updates from the system.h and syswm.h headers. There’s a lot of stuff in there that I just have no time or inclination to test, particularly since I don’t need any of it myself. Most people will be in the same boat, but if you do need it, I’ll be more than happy to accept pull requests for the stuff relevant to the platforms you need it on. If that’s too much, I can implement it myself upon request, but it will be up to whomever is doing the requesting to test it.
As always, please report bugs in the issue tracker at github.
I’ve just returned to Korea from a 3-week trip to my hometown. I had some good quality time with my close relatives, ate some great food, and generally enjoyed my first Christmas with family in 22 years. A note more relevant to this blog is that while I was there I bought myself a Macbook Pro (which I’m using right now to write this post). Now that I’m back home, I’m in the process of getting DMD set up and exploring the world of development on Mac.
With my Windows PC, my Linux laptop (my wife’s old Samsung on which I replaced Windows) and my new Macbook, I’m finally in a position to handle the maintenance of Derelict on the Big Three by myself. About time, eh? And to be honest, I’m liking the Mac experience quite a bit. For me, the user experience is miles ahead of Linux and more enjoyable than Windows (all in the little details). No comment yet on the development experience, but I’m not anticipating any major issues. I’m already used to ‘command’ key shortcuts and have almost completely broken my habit of hitting the ‘control’ key, an annoyance which plagued my first few days with the thing.
Over the next several days, I’m going to slowly get caught up with pending issues in Derelict and the Learning D source. I’ll also start moving on my plans for learningd.org. The keyword here is slowly. I’m still decompressing from the trip and I’ve got a lot of real life things outside of DLand that need my attention to get caught up on. I should be back in full swing by the end of this month.
Oh, and while I haven’t made any travel reservations yet, I did purchase my DConf 2016 ticket. If you’re going, see you there!
For years I was an emphatic FireFox user, but at some point I made the move to Chrome and never looked back. This past summer, when I upgraded my home PC to Windows 10, I found that I liked Edge more than I expected to. I started using it exclusively for a while, but eventually I decided I missed my Chrome plugins. I went back to it about a month ago or so. About five minutes ago, I uninstalled it from my system.
As part of the server move, of course I had to update the DNS records for this domain with the new IP address. Once the changes propagated, Edge, Firefox, IE and Opera all picked it up just fine. Chrome did not. I waited and waited. Chrome kept giving me the old site. I flushed the DNS cache (both the browser’s and the system’s), turned off DNS prefetching, cleared my browser history, and even rebooted. Still got the old site. Chrome on my Android picked the new one up just fine. I haven’t checked it on my Surface 3 yet, but I can assume I’ll have the same problem there. I may as well check my Linux notebook, too, but I haven’t booted into that in quite a while.
At any rate, my patience wore out. I decided to just uninstall and start over with a fresh install. Did the first part, downloaded the installer to do the second part, then I decided not to bother. I’ll just run Opera for a bit. It’s the only one of the browsers on my system that I’ve never used regularly. If I don’t like it, I’ll just move back to Edge.
I’ve gotten the blog set up on the new server and all of the post data imported. I’ve tried to set up the plugins exactly as I had them on the other server, but may have overlooked something. If you notice any problems with the site, please let me know.
So I’ve created a new website as a companion to Learning D. You can find it at learningd.org. The goal is to provide news about the book, whatever that may be, along with other resources that relate to the concept of learning D. I hope that one day it is packed full of useful tutorials, code snippets, links and such. At some point, I’ll put out an open call for contributions, but I’m not ready for that yet.
As for this old blog, it isn’t going anywhere. I want to keep my posts regarding Derelict and any other personal projects, rants, and whatnot separate from the other site. I will be moving it to a new server, though. For the new site, I decided to start from scratch on a new system. I sort of put this server together with bandaids and glue, but that one is properly configured. And I’ve documented everything, so I won’t get lost when I need to maintain it. As such, I’ll be migrating this site over there soonish.
In a couple of weeks, I’m heading off to the States for three weeks to spend time with family and old friends, so my activity level will be next to nil until sometime around the middle of January. There’s a lot I’m itching to do in the coming year, though not all of it is related to D.
In late February of this year, I contracted with Packt publishing to author a book titled ‘Learning D’. I’m happy to announce that the book was released on Nov 27 and is available both from the publisher’s website and from Amazon. A sample is available here.
This was the second (DLang) book I’ve worked on, the first I’ve authored by myself. It required a significant investment of time and energy, but was an overall enjoyable process. There were a couple of bumps in the road at the end which prevented me from announcing the release sooner, but no major complaints. At some point, I’ll write a postmortem about the process.
The source will be available for download from the publisher’s site, but I’ll also be putting up a GitHub repository soonish. All of the code associated with the book can be considered under the Boost license, even if the copy you download does not contain a license file.
The target reader I had in mind while writing the book is someone who has some experience with a C-family language. The aim is to help such programmers make the transition to D more smoothly and be aware of the common pitfalls that arise when programming in D while thinking in C++ or Java. I hope it proves a useful addition to the D ecosystem.
People who have no programming experience would be better served by getting started with Ali Çehreli’s book, ‘Programming in D’.
The reload method of the DerelictGL3 and DerelictGL loaders now supports two GLVersion parameters.
The first represents the minimum required version of OpenGL that a context should support. Previously, it was necessary to check the return value of reload to determine if you got a high enough version. Now, when a version other than GLVersion.None is specified, the loader will throw an exception before attempting to load anything if the currently active context does not support that version. The default value, GLVersion.None, causes the function to behave as it always has.
The second parameter allows you to constrain the loader to a maximum version. This will force the loader to load no higher than the version specified by this argument, even if the context supports a higher version. The default value is GLVersion.HighestSupported.
As an example, the following will load any version up to and including OpenGL version 4.4.
Generally, the first parameter is more interesting. For example, if your app requires OpenGL 3.3 or higher, you can pass GLVersion.GL33 as the first argument. The second parameter is useful for rare and specific circumstances, such as avoiding driver bugs. For example, one DerelictGL3 user has a driver that reports support for GL 4.5, but some of the 4.5 functions repeatedly fail to load with that driver. Assuming your app requires no 4.5 functions, the second argument will allow the app to load even when that buggy driver is present.
A couple months ago I added a new branch to the DerelictSFML2 repository to support the SharedLibVersion feature of DerelictUtil, allowing multiple versions of CSFML to be loaded by one binding. Today, I was looking into whether I had updated to support CSFML3 or not when I realized something really bad: SharedLibVersion support can’t work for DerelictSFML2.
The short of it is that different minor versions of CSFML sometimes add new enum members right in the middle of existing enums, changing the value of those that come after. They also sometimes add a new member to a struct type, changing the size of the struct when it happens. While Derelict may be able to load multiple versions of the shared libraries, users won’t be able to use the new versions of DerelictSFML2 with older versions of the CSFML library.
To solve this, I’ve done what I should have done when I merged support for 2.2: I created a 2.2 branch and tagged it with version 1.2.0 for DUB. Next, I created a 2.3 branch and tagged it with version 3.0.0 for DUB. Ideally, it would be 1.3.0, but since I’ve already got the branch with SharedLibVersion support tagged with 2.0.x, I don’t want it showing up in the DUB registry as the newest version. To discourage people from using the 2.0.x versions, I’ve deprecated every module in the corresponding branch.
So here’s what it breaks down to:
- DerelictSFML2 1.0.x -> CSFML 2.0
- DerelictSFML2 1.1.x -> CSFML 2.1
- DerelictSFML2 1.2.x -> CSFML 2.2
- DerelictSFML2 2.0.x -> DEPRECATED — DO NOT USE
- DerelictSFML2 3.0.x -> CSFML 2.3
So if you’re currently using DerelictSFML2 2.0.x, please upgrade to 3.0.x. You’ll no longer be able to use SharedLibVersion, but neither will you be left with a bug resulting from calling a function in an older version of CSFML with a new enum value that would likely only manifest itself in the wild.
I took some time out today to get a little work done on the Derelict documentation. In addition to a new style and a bit of refactoring, I’ve added a few paragraphs about how to use SharedLibVersion. There’s still a great deal to be done. As soon as Learning D is complete, I’ll make the Derelict docs a priority.