DerelictPHYSFS 2.0.0

DerelictPHYSFS spent quite some time languishing at the bottom of the second page of DerelictOrg projects, starving for attention. I created it on a whim a couple years ago when I wanted to use PhysicsFS for a project that I subsequently abandoned. In the time since, there have been no PRs for the project, no emails asking for help, no enhancement requests, nothing. So there it sat, forgotten.

Recently, I’ve begun work on assembling a codebase from the numerous abandoned games and graphics projects scattered around my dev projects folder. That eventually led me back to DerelictPHYSFS and a simple wrapper I had made for it (see Defile). The README for DerelictPHYSFS was still pointing to the old, defunct documentation page on this blog, rather than to the pages at derelictorg.github.io (which are still far from complete, but should currently be informative enough to use any Derelict package without much difficulty). The binding itself was stable. The 2.0.x API of PhysicsFS had not changed since I first made the binding (the last stable release, 2.0.3, was in October, 2012!), but the 2.1 API is what you get when building PhysicsFS from the development branch.

I normally don’t like to update Derelict bindings against unreleased versions of a C library, but in this case I think an exception is warranted. Any shared libraries built from the development branch of PhysFS would be compatible with the existing binding, but it would be nice to be able to make use of the newer API. So I’ve updated DerelictPHYSFS to the unreleased PhysicsFS 2.1. You can get that in the 2.1 branch on github, or through a dependency version of ~>2.0.0 in your dub configurations. The original binding is still there in the 2.0 branch, currently at version 1.0.3 as a dub dependency. I have no plans to update it further, unless someone is using it and really needs a bugfix (but I don’t think many people actually are using it).

I’ve also updated Defile to depend on the new version of DerelictPHYSFS. I intend to expand its API as I need it. It’s been available in the dub registry for quite some time and is still there for anyone who wants to use it. If you do, I make no promises about support. It’s a personal project that I decided to share with others and not something I intend to make room in my schedule to support for anyone other than me. Simple bug fixes or enhancements, maybe (definitely those that benefit me!), but anything time consuming? Forget it. Don’t let that discourage you from using it, though, if it’s something you need. It’s Boost licensed, so feel free to take it and do what you want with it.

There’s a lot of work I intend to get done with Derelict in the coming months. I need to update DerelictAllegro5 to Allegro 5.2 and get it into what I consider the right state for a 1.0.0 tag. I need to add support to DerelictLUA for Lua 5.1 so it can be used with LuaJIT. I also want to implement a static binding configuration for it like I did for DerelictGLFW3. I intend to do the same for a few other Derelict packages. I also need to work more on the documentation. That’s all competing with my plans for learningd.org and the example project from the book, the game-oriented stuff I’ve been working on the past few weeks, and some writing projects (not related to D or anything tech) I’ve got underway. Anyone got any spare time for sale?

DerelictUtil 2.0.6

I’m currently working on a project where I decided to make use of the Derelict’s ability to load specific file names in some cases, but the default in others. That’s when I discovered something about DerelictUtil I had forgotten — it doesn’t allow for empty or null library name strings.

For reasons lost in the mists of time, I originally chose to use an empty arg overload that calls the single string arg version, which then asserts the string is not empty or null. If I were starting from scratch today, I would make it so the single string arg overload takes an empty string as a default argument. Instead, I’ve modified the single string version to use the default library names in case of null or empty strings. If you also would like to make use of this, you should require a minimum dependency of version 2.0.6.

New POSIX-Specific Feature for DerelictUtil

I’ve been persuaded to add a new feature to DerelictUtil for systems that use dlopen to load shared libraries. Unlike LoadLibrary on Windows, the function accepts certain flags that determine when symbol resolution occurs and whether the symbols should be visible to other objects. For as long as DerelictUtil has existed, it has called dlopen in a way that matches the behavior of LoadLibrary on Windows, with immediate resolution and local (as opposed to global) visibility.

I’ve just added a new property that allows those who know what they are doing to change the dlopen flags as required:

import derelict.util.sharedlib;
version(linux) derelictLDFlags = LDFlags.rtldLazy;
DerelictFoo.load();
version(linux) derelictLDFlags = LDFlags.rtldNow | LDFlags.rtldGlobal;
DerelictBar.load();

The example uses version(linux), but it’s available anywhere version(Posix) is defined. Note that it’s a global property that affects all subsequent calls to the load method on any loader instance. The default is LDFlags.rtldNow.

DerelictGLFW3 2.0: derelict-glfw3-static

The desire to add static bindings to some of the Derelict packages goes way, way, back (at least as far as June of 2006, probably further). I was dead set against it, then for it, then against it, then for it, then against it… Anyway, the day has finally come when I’ve added static binding support to a Derelict package. In this case, it’s DerelictGLFW3 and it’s available now for your DUB dependencies with the 2.0.0 tag. Note that this is only available for GLFW 3.1. I have no plans to add support for this to the 3.0 binding.

So, DerelictGLFW3 is now both a dynamic and a static binding all in one. Dynamic is the default configuration, so you can configure your projects as you always have and call the DerelictGLFW3.load method. To enable the static binding, add the following to your dub.sdl.

dependency "derelict-glfw3" version="~>2.0.0"
subConfiguration "derelict-glfw3" "derelict-glfw3-static"

You’ll also need to link either dynamically or statically to the appropriate GLFW3 binaries. See more in the package documentation.

The static binding eliminates the DerelictUtil dependency and also produces smaller library files. It also reduces the size of your final executable, since you won’t have all of the loader code and the function pointers compiled in anymore. As much as I love the convenience of a dynamic binding, static bindings on Windows are more convenient than they were when I first started Derelict back in 2004. I’ve found myself wanting to use them on more than one occasion. I do intend to add support for this to some other Derelict packages, if not all. DerelictSDL2 is first on that list, but I make no promises as to when I’ll get around to it.

DerelictFT 1.1.0

I’ve just tagged release 1.1.0 of DerelictFT. This updates the binding to FreeType 2.6.3 (the 1.0.x series was implemented against FreeType 2.5), which should work with any of the 2.6.x releases so far. The changes in FreeType 2.6 compared to 2.5 are minor, but they are of a nature that makes SharedLibVersion support problematic. As such, I have no plans to add support for it to DerelictFT.

DerelictLua 1.3.0

I’ve finally gotten around to adding support for Lua 5.3 to DerelictLua. It can be found in the 5.3 branch at github and is accessible through DUB via the 1.3.0 version tag. Lua 5.2 is still usable through 1.2.x, the most recent release there being 1.2.3. I had intended to add support for SharedLibVersion, but it turned out to be unfeasible. Lua 5.3 removes a number of functions and changes the value of some enum fields.

If you’re using DerelictLua on Windows, I recommend you download the pre-built DLL from Lua Binaries if you aren’t interested in building it yourself.

DerelictPQ 2.0.0

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.

DerelictSDL2 2.0.0

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.

Back on the Job

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!

Chrome and DNS

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.