Latest articles

We're Overlooking A Key Part of C/C++ to D User Migration

In the D community, we have a strong belief in D's potential as a suitable and favorable alternative to C and C++ for areas commonly served by C/C++. This isn't surprising, since that's exactly how D was originally designed and envisioned.

To help facilitate that, D has always been designed to easily interface and directly link with C code. More recently, major improvements have also been made in interfacing D with C++. Naturally, one major benefit of this is to provide D with access to the wide array of existing C/C++ libraries. But the other key idea here is to help encourage D uptake. How? By making it easier for existing C/C++ projects to include D portions without the entire project needing to be ported.

This C/C++ interoperability is a fantastic feature for D to offer, and is essential in encouraging and facilitating migration to D. Building off this, we have Deimos, to offer D projects ready-made bindings to C/C++ libraries. Other projects in may offer to auto-generate D bindings or wrap existing Deimos bindings with D-centric benefits and simplifications. All of this, we hope, will make D appealing enough and entice C/C++ users to try out D in their projects - and potentially, commit more fully down the road.

But we're overlooking a key part of the picture. We're looking at something backwards:

Our whole approach to giving D inroads into the C/C++ world relies on convincing C/C++ users to actually try out writing D. Even before they do that, they must actively decide to go learn some D. We've had some success, but as many of us have learned, this can be a significant uphill battle. The status quo is strong with programmers (and understandably so).

Take our existing focus, offering C/C++ libraries to D projects: What if we flipped that around and started using D's C/C++ interoperability to offer D libraries to C/C++ projects?

Think about it: If a D library came with its own C/C++ bindings, then it may as well be a C/C++ library as far as most C/C++ users are concerned. Then just slap into a C-world-compatible makefile into the library, which auto-detects a D compiler and, if none, does an automatic project-local download/install of DMD/LDC/GDC (this could all be offered to D libraries via a single D tool up on, or even just include precompiled library binaries, and done: on any platform D supports, C/C++ users can use your D library just as if it were another C/C++ library.

That gives D inroads into C/C++ projects without requiring any C/C++ user to ever have to touch one line of D. Then, later, when coders wonder how the library they use works so efficiently and reliably, and is developed so productively - they can glance into the lib, see how simple it really is compared to a C/C++ equivalent, and see how much easier still it would be to use the library from D. Nice, D has just marketed itself.

tl;dr (In my day we called that a "summary"): I propose free C/C++ bindings with every D library! The D community should strive to offer them as a standard matter of course. Tools should be created to help D library authors offer their own C/C++ bindings. This will take us much farther into the C/C++ domain than merely offering C/C++ libraries to D users will.

Read more

WTF is the Deal With T-Mobile's Service Coverage?

For the past couple years, I've been a Verizon user with a deep seething hatred for Verizon. I won't get into why I despise them here, other than to say it's been for both real-world practical and ideological reasons. But, for various reasons also not worth getting into (such as other people on my group plan, and one particular catch involved in the "We'll pay your early termination fee" deals that's personally a show-stopper for me), and let's face it, there's no such thing as a good telecom company, I've been stuck until now.

I've been eyeing T-Mobile a lot lately. I'm not sure sure about the whole "uncarrier" moniker, but they do appear to be an improvement over Verizon in many ways. And from what I can tell, they seem the least offensive and questionable of all the options available here in the US.

However, as anyone who's looked into them knows, T-Mobile's famous Achilles heel has always been questionable service coverage. Aaaaannd...that leads straight down a rabbit hole: This year, T-Mobile's been saying a lot about their greatly improved network. Some users confirm it, some contradict it, and others just ramble about..."band 12"??? WTF is that??? Who even wants to know?!

After researching more and more, I think I've finally gotten a handle on just what is going on with T-Mobile's network lately. Here's what I've found out:

"If you haven't tried our network lately, you haven't tried it period." - Frequent T-Mobile tagline

Turns out, there's a lot of truth to that statement...depending on your phone. But back to that in a bit...

Ultimately, the key concept here is that there's two types of radio frequencies used by cellular carriers: Higher frequencies and lower frequencies.

Lower frequencies travel farther and do a good job of penetrating walls and buildings (See what FCC Chairman Tom Wheeler said about this last year). But there's a downside: They can't handle quite as many people at the same time. So the carriers have to make up for that by building more cell towers. This works out perfectly for the larger carriers who can afford it. In fact, for many years, and up to at least as recently as one year ago, "AT&T and Verizon control nearly three-quarters of low-band spectrum in the US".

Higher frequencies can support more users doing more things at the same time. This makes it attractive to underdogs carriers like T-Mobile who use it because they can support more customers with fewer towers at a lower cost. But the downside is that higher frequencies don't travel as far, and have trouble penetrating walls and buildings. So, historically, T-Mobile has been making do with fewer towers, each with less range. This is why T-Mobile's network works great when you're in range (their higher frequencies can handle more people and more data), but also why actually getting a signal could be difficult (their higher frequencies, from fewer towers, don't travel as far or go through as many walls and buildings).

This past year, T-Mobile's been spending large amounts of money to do two things: First, they've been building new towers to help compensate for their signals not traveling as far as Verizon's. This gives them coverage across a much larger portion of land than before, and fills their coverage map with far more of their flagship pink. This is why some T-Mobile users, particularly ones in suburban areas, have been reporting their coverage has improved. (Although, rural areas are still lagging - albeit not by quite as much as before.) But, since high-frequency is still high-frequency, these additional towers alone don't do much to solve the problem of getting a good signal indoors, or around many large buildings. This is why other T-Mobile users, especially ones in urban areas, have been reporting they're still getting spotty coverage.

Addressing that is the second big thing T-Mobile has been working on recently. Early last year, they spent $3 billion buying a chunk of lower-frequency (700MHz) spectrum from Verizon, and have been bringing it live this year, especially over just these last few months, and they're continuing to utilize more of it even now. They also plan to buy even more (600MHz) at an FCC auction early next year.

This lower-frequency 700MHz range that T-Mobile bought from Verizon and has now been bringing live is what they're calling "Extended Range LTE". In more technical circles, this specific section of 700MHz is also known as "band 12".

But if T-Mobile now has all this new "works well indoors and through buildings" capability, why have some users been reporting they still get bad indoor coverage? They're probably on an older phone: Older phones are, well, older, and so don't support T-Mobile's new "band 12"/"700MHz"/"Extended Range LTE". For reference, here's the current list of phones which do support it. The list is also available here. (Unfortunately, that does exclude the phone I wanted, the Note 3. Damn. So long USB3 and hardware menu button :/ ). But it seems safe to expect all major current and upcoming phones to support it moving forward.

So, bottom line: T-Mobile is currently in the middle of a big shift improving their coverage. Some of this is already here, particularly in suburban areas, but some is still yet to come. The big caveat is that the improvements to indoor reception require a newer phone compatible with T-Mobile's new "band 12"/"700MHz"/"Extended Range LTE".

Read more

Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more

New update to Scriptlike: v0.9.4.

Scriptlike is a library to help you write script-like programs in D.

The two highlights in this release are string interpolation and a full set of examples in the documentation. Also of note are the new functions removePath and tryRemovePath which can be used to delete files (like remove) or directories (like rmdirRecurse).

For the full list of all changes in this release, see the changelog.

String Interpolation


AFAICT, a string mixin is necessary to accomplish this in D, but otherwise it works much like other languages:

// Output: The number 21 doubled is 42! int num = 21; writeln( mixin(interp!"The number ${num} doubled is ${num * 2}!") );

The interpolated sections are handled via std.conv.text(), so they accept any type.

Bikeshedding requested! I'm not 100% sold on the name interp for this long-term. Suggestions welcome.


The homepage/readme now provides sample code demonstrating all of Scriptlike's various features.

There is also a demonstration of suggested practices for how to use Scriptlike in a D-based script.

And finally, all examples are included as actual runnable programs (all automatically tested by dub test, to ensure continued freshness).

Read more

Material Design Makes Me Want a Windows Phone

I'm amazed that Google's actually managed to fool anyone into believing they really did design Google Metro I mean *cough* "Material Design".

Hell, I'm amazed they even choose to swipe it in the first place: The biggest visual abomination to hit computing devices since Windows 2, attached to the biggest operating system blunder since...well, since the last Microsoft operating system blunder, Vista, and some Google genius decides, "Yes, this is a great thing for us to imitate."

As if stealing Metro wasn't insane enough, they just had omit the one good thing Metro actually does have going for it: Actual...fucking...words right below all the nonsensical hieroglyphs. (Even Chinese/Japanese logographic writing occasionally has such a thing as "Ruby/Furigana". And those are for long-established symbols, not some vague squiggly metaphor pulled out of a random cubicle-dwelling technohipster's ass one afternoon.)

Seriously Google, if I wanted my phone to look like Windows Phone Unicorn-Vomit Edition, I'd get a Windows phone. At least then I could actually read all the meaningless idiotically-designed buttons.

Remember this computer "interface" from Idiocracy?

Idiocracy UI

We've already shot beyond that, with hieroglyphs that make far less sense, and screwups like Google have been leading the charge.

Oh well, I shouldn't complain. At least it's not an iPhone.

Read more

Various Software Updates and New Tools

I've been fairly busy over the last couple months or so updating several projects. Enough has accumulated that instead of making individual posts for each update to each tool and library, I'm combining them all into this one post.

Most of this has been part of a behind-the-scenes push to get the next incarnation of DAuth ready for release. It will still be the same library, but will be rebranded as "InstaUser" (partly to avoid confusion with OAuth, which DAuth isn't directly related to) and will have an expanded scope.

The current DAuth will become "InstaUser Basic", the core of the InstaUser project. But InstaUser will also offer brand-new purely optional components: "InstaUser Store" to instantly get up-and-running with database-backed user account storage, and "InstaUser Web" which builds on InstaUser Store to provide ready-to-use web-based login and registrations. Eventually, there may even be an "InstaUser OAuth", but that's only in the "wishlist" stage right now and definitely won't be in the first release of InstaUser.

Anyway, that's all still in-progress, but working on it has revealed various direct and indirect needs in other projects. Here's what's new since my last "Announcements" post:

DAuth v0.6.2

[Project Homepage]
[Full Changelog]

This will likely be the last DAuth release before being rebranded InstaUser.

DAuth is an open-source salted password hash authentication library for D. It provides a simple, yet flexible API. With it, your software can easily incorporate user accounts with reliable, upgradeable security.

Changes since v0.6.1:

v0.6.2 - 2015/03/25

  • Fixed: #1/#2: Compilation failure when using DUB and DMD 2.067 (@NCrashed)

gen-package-version v1.0.2

[Project Homepage]
[Full Changelog]

Automatically generate a D module with version and timestamp information (detected from git or Mercurial/hg) every time your program or library is built. You can also generate a DDOC macro file (using the --ddoc=dir switch.)

Even better, all your in-between builds will automatically have their own VCS-generated version number, including the VCS commit hash (for example: v1.2.0-1-g78f5cf9). So there's never any confusion as to which "version" of v1.2.0 you're running!

Just add this to your project's dub.json:

"dependencies": { "gen-package-version": "~>1.0.2" }, "preGenerateCommands": ["dub run gen-package-version -- --root=$PACKAGE_DIR --src=path/to/src"]

Replace and path/to/src with the appropriate values for your project (but keep $PACKAGE_DIR exactly as written above), and you're ready to go:

module; import std.stdio; import; void main() { writeln("My Cool Program ", packageVersion); writeln("Built on ", packageTimestamp); }

Changes since v0.9.0:

v0.9.1 - 2015/06/14

  • Fixed: helper/ isn't set as executable when checked out through dub.

v0.9.2 - 2015/06/14

  • Fixed: The old recommended "preGenerateCommands" led to problems (project dependencies that use gen-package-version would run it from the wrong directory).

v0.9.3 - 2015/06/15

  • Enhancement: If detecting the version number via git fails, attempt to detect it via the current directory name (ex, ~/.dub/packages/[project-name]-[version-tag]).
  • Enhancement: Don't bother running git if there's no .git directory.
  • Enhancement: Bootstraps itself, so gen-package-version itself enjoys the following fix:
  • Fixed: Fails to detect version number for packages fetched by dub (since they lack .git).

v0.9.4 - 2015/06/16

  • Enhancement: Support detecting the version number via Mercurial (hg).
  • Enhancement: Support .hgignore for Mercurial working directories.

v1.0.0 - 2015/06/27

  • Change: The generated packageTimestamp is changed from ISOExt format to human readable. The ISOExt formatted version is now called packageTimestampISO.
  • Change: Value for --module is no longer allowed to contain periods.
  • Enhancement: Basic ability to be used as a library. See the README for details.
  • Enhancement: Add -r|--root to support projects in any directory, not just the current directory.
  • Enhancement: Minor improvements to --verbose and --trace outputs.
  • Fixed: Don't update the version file (and thus trigger a project rebuild) if the version file doesn't need updated. Bypass this check with the new --force flag.
  • Fixed: Don't rebuild gen-package-version if not needed.
  • Fixed: Failure on Windows when target project is on a different drive letter from current working directory.

v1.0.1 - 2015/06/28

  • Fixed: Don't use a broken scriptlike release (v0.9.0), use v0.9.1 instead.

v1.0.2 - 2015/07/01

  • Enhancement: Now works on DMD 2.066.1 (previously required 2.067.0 or up).

New tool: safeArg v0.9.7

[Project Homepage]
[Full Changelog]

Think of this like xargs -0, but simplified and ready-to-use in any dub-based project, even on Windows.

See the homepage for more info and examples, but essentially, the purpose is this:

Using eval or command substitution to pass arguments to a program is error-prone, non-portable and a potential security risk. This command-line tool utilizes the commonly-recommended approach of null-delimited stream to provide safety and reliability when passing arbitrary data to a program as command-line arguments.

Scriptlike v0.9.2

[Project Homepage]
[Full Changelog]

Utility library to aid in writing script-like programs in D.

Changes since v0.8.0:

v0.9.0 - 2015/06/27

  • Change: Split scriptlike.file and scriptlike.path into the following:
    • scriptlike.core
    • scriptlike.file.extras
    • scriptlike.file.wrappers
    • scriptlike.path.extras
    • scriptlike.path.wrappers
    Utilizes package.d to retain ability to import scriptlike.file and scriptlike.path.
  • Change: Convert changelog from markdown to ddox so links are more readable.
  • Enhancement: Add (opt-in) command echoing to most functions in scriptlike.file.
  • Enhancement: Add yap and yapFunc as improved versions of to-be-deprecated echoCommand.
  • Fixed: Make escapeShellArg const-correct.
  • Fixed: Make Path.toRawString and Ext.toRawString both be pure @safe nothrow.

v0.9.1 - 2015/06/28

  • Fixed: Fails to compile unless the makedocs script has been run.

v0.9.2 - 2015/07/10

  • Fixed: Properly flush all command echoing output (ie, in yap and yapFunc).
  • Enhancement: Add a "no-build" configuration for projects that need to import/depend on Scriptlike through DUB, but use their own buildsystem.

SDLang-D v0.9.2

[Project Homepage]
[Full Changelog]

A library to parse/generate SDL (Simple Data Language) files. Offers both DOM and StAX/Pull APIs.

SDL is like XML/JSON/YAML, but is low-verbosity, simpler than YAML, and supports comments and basic datatypes. It looks like this:

// An example of SDL: folder "myFiles" color="yellow" protection=on { folder "my images" { file "myHouse.jpg" color=true date=2005/11/05 file "myCar.jpg" color=false date=2002/01/05 } // Another folder folder "my documents" { document "resume.pdf" } }

Changes since v0.9.0:

v0.9.1 - 2015/03/17

  • Fixed: #16: Access Violation when using the pull parser.

v0.9.2 - 2015-07-31

  • New: Uses for continuous integration testing.
  • Change: Updated package.json to newer dub.json name.
  • Fixed: #16: Now fixed for DUB users, too: Access Violation when using the pull parser.
  • Fixed: #21: Remove unneeded "buildOptions" from DUB package config (fixes a DUB warning) (@schuetzm)
  • Fixed: #28/#29: Wrong line count for Windows style line breaks. (@s-ludwig)
  • Fixed: Fixed running unittests via DUB. (Part of #29) (@s-ludwig)
  • Fixed: Trailing line comments incorrectly treated as line continuation instead of newline (Related: #20, plus libsdl-d's e565f30 and c6dc722) (@Dicebot)
  • Improved: #22/#23: Internal improvements (@schuetzm)

Read more

Those who rely on Moore's Law...

Those who rely on Moore's Law inevitably ignore and fall prey to Wirth's Law.

(See also Jevons paradox.)

Read more