Latest articles

I recently ran into an issue I'd like to talk about in case anyone else has hit the same problem.

On my main PC, I run Manjaro Linux (an offshoot of Arch Linux). Recently, when I tried to to perform a system update, I started getting errors preventing me from updating. The problem was a conflict relating to package "ffmpeg2.8", which was in turn required by "4kvideodownloader". Now, you may or may not be familiar with 4kvideodownloader, but the details of it aren't especially important (aside from the fact that it's freaking awesome and I highly recommend it). What is important here is that I like 4kvideodownloader, and there are reasons I don't want to give it up.

This left me with a dilemma. The 4kvideodownloader tool (via its "ffmpeg2.8" dependency) were blocking me from updating my machine. The obvious choices were to either stop making any updates to my machine forever, or uninstall both "ffmpeg2.8" and "4kvideodownloader". I hated both options.

So I took a gamble. I uninstalled both "ffmpeg2.8" and "4kvideodownloader", hoping I would then be able to update my Manjaro/Arch-ish system and then...somehow...be able to get "4kvideodownloader" installed and working again.

Which brings me to the whole point of this post:

The gamble paid off! Once I uninstalled "ffmpeg2.8" and "4kvideodownloader" via yaourt (turns out, both are AUR packages), I had no trouble updating my system. And then, best of all, I had no trouble re-installing "4kvideodownloader" (along with its dependency, "ffmpeg2.8") afterwards.

Summary (ie, that's ordinary English for "TL;DR", for any of you hipster, fashion, Portlandia-as-everyday-life nerds out there.) :

You don't have to give up 4kvideodownloader, or wait for a AUR update to 4kvideodownloader, to update your Arch Linux-based system. Just uninstall them so you can update your system, and then you should have no trouble re-installing both. It worked for me...

Read more

Read more

Say you're part of my generation, and those classy, spiffy looking little bottles of intriguing Zima dissapeared from store shelves just before you were old enough to (legally) find out for yourself just how unworthwhile they really were.

Sure, everyone said it was horrible, nasty crap. Sure, in all your years you've never heard anyone say one good thing about Zima (not even that one dude who had just the weirdest taste in drinks...) But now they're back, and dagnabbit you're well over 21 this time, with a bucket list and some hard-earned cash.

And partway into one bottle, yes, you too can now check one more item off that bucket list - that slight cringe on your face is your badge of honor: You finally know for yourself exactly why it was ridiculed and dissapeard for over a decade. And you too, can now join in on the ribbing. Mission accomplished.

But, shoot, what do you do with the rest of the five and a half bottles in that six-pack? It never did feel right to toss even the most vile booze down the drain. What a shame. What's a dude[ette] to do?

Make Mozitos!

Ingredients:

• 1/2 Bottle of chilled but still nasty, overly-sugary, slightly beer-ish, not-very-citrusy swill that because of "malt and citrus" sounds like it should kinda taste like a shandy except it really doesn't (aka, "Zima")
• However many shots of whatever proof vodka you choose. You're on your own here, but one word of advice: Go with the cheapest one you can find. It's a freaking mixed drink - it's not like you're gonna notice the difference. (Rum would likely work well too, athough it's not as cheap. Just make sure not to use a sweeter one like Parrot Bay, at least not for this recipe. The Zima has plenty of sweetness already.)
• Juice from 1/2 a lime (Roll the lime hard on a countertop before slicing it open - That'll make it a lot easier to extract all the juice. Some people suggest slightly heating it in a microwave, but I think rolling it is easier, much more fun, and words just as well.)
• Several leaves of fresh mint (Or a bunch if you really love mint)
• Three ice cubes

Make:

1. Take your serving vessel (ie: "cup") and add the lime juice and mint leaves.
2. Use a muddler to mash the mint leaves (Carefully! You don't want to chip the glass if the glass is...umm...glass). The releases the mint's minty flavor into the drink.
3. Since nobody has a muddler, and most people don't even know what a "muddler" is, just use the handle of a knife or whatever else you have in your kitcken that looks like it'd be good for mashing mint leaves in a glass. (Hmm, maybe I should have mentioned this before step 2.)
4. Add your vodka (Or rum. Or whatever.)
5. Add ice.
6. Fill the rest of the glass with (roughly) 1/2 bottle of Zima
7. Serve. (That's fancy-talk for "Bottoms Up!")
8. Swear to never buy Zima again. Until the next time they bring it back as a "Limited Release"...

Read more

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 code.dlang.org 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 code.dlang.org), 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