Monthly Archives: June 2010

Nintendo Australia – You Suck!

Lets look at the release dates of Super Mario Galaxy 2 around the globe (according to Wikipedia)…

  • North America: May 23, 2010
  • Japan: May 27, 2010
  • EU: June 11, 2010
  • Australia: July 1, 2010

But Australia is in the same Wii game region as the EU… the release is exactly the same. So what the hell Nintendo! You are lucky that the game will be awesome so I can not protest.

The delay from the North American release data is something I have learned to live with, as EU region releases are always delayed (supposedly due to having to do the translations). But at least when the Smash Bros Brawl release date in Australia was four months behind the North American release, the EU suffered along with us.

Posted in Games on by Allan – Comments Off on Nintendo Australia – You Suck!

Pacman 3.4.0 Released

As Dan has already posted about, pacman-3.4.0 has been released. There are a bunch of new features that I am really enjoying.

Firstly, when updating it database, pacman will only extract the new entries. This is similar to what Xyne’s rebase script does (without all the extra output). I had not realised how awesome this feature was until I updated my chroots this morning. It speeds the process up immensely. The chroots using pacman-3.4 extracted the [extra] repo database with a barely noticeable pause while those using pacman-3.3 took a while.

The other feature that I am enjoying is the addition of a functional ‘which’ to the file ownership query. In the past, to find the owner of a binary in my path I would do something like pacman -Qo $(which makepkg) or provide the full path manually. Now pacman will search for binaries in your path automatically, so this is achieved with pacman -Qo makepkg.

Installing packages with pacman -U has received a nice overhaul, allowing pacman to handle package replacements and install needed dependencies all in one transaction. No more removing a package with pacman -Rd and then installing its replacement.

And makepkg also received its share of upgrades. It now automatically exits on build/packaging errors in PKGBUILDs so there is no more need to have “|| return 1” after the commands. Package splitting has improved with pkgver, pkgrel and arch now being able to be overridden and being able to only build subsets of a split package.

Of course, many other features made it into this pacman release. As always, many changes will hopefully never be noticed by a user (e.g. checking a package architecture matches the system architecture before installing, a major rewrite of the pacman bash completion, overhaul of tests in makepkg, more configurable library stripping during packaging), but all these are very useful contributions. See here for a more detailed summary of the changes and the git log for all the details of changes.

A pacman-3.4.0 package is currently in the [testing] repository for Arch Linux. We all know pacman releases are bug free (as the two patches already in the 3.4.1 queue can attest), so look forward to it being in a [core] repo near you in the not too distant future.

How Do You Check E-mails?

Saw an infomercial for Australia’s biggest ISP (Telstra BigPond) today and learnt something amazing. The “expert” talking to the presenter said something like:

People do a lot of things on-line these days. Watching movies, checking emails, browsing…

I was a bit taken back… People use the internet for checking emails? I have been doing it wrong all these years!

GCC in C++

As is becoming widely covered, the GCC Steering Committee and the FSF have approved the use of C++ in the GCC codebase. This is not a particularly sudden decision… I originally saw this proposed by Ian Lance Taylor on his blog a couple of years ago. He also has some good slides about how using C++ would be benificial. There was a gcc-in-c++ branch that corrected incompatibilities flagged by -Wc++-compat, but I think this is mostly merged and there is now an experimental --enable-build-with-cxx configure flag. So I think that this decision comes at no real surprise to anyone involved.

I think this is a great idea! Why? Because if the compiler is written in C++, then the compiler developers have more motivation to make C++ compilation faster. This is good for me as C++ is my primary choice for a writing in a compiled programming language. So this is a win for me.

Is it a win for GCC? I know some people (especially Linus Torvalds) think using C++ for anything is a major disaster. In fact, despite being a C++ proponent, I tend to agree… 99% of people who propose the usage of C++ for something are wrong. Many of the complexities in C++ have no place in most projects and too many C++ programmers feel the need to use the entire C++ toolset. Let be honest, the curiously recurring template pattern and template metaprogramming have no real place anywhere but in academia[1]. But (single) inheritance and the STL do provide what I have seen people try to replicate in C many times. Using C++ as a C with classes is not really that different from C but it can be much simpler to write.

There are some obvious cases where changing to C++ in the GCC codebase would be of great benefit. Take a look in gcc/vec.h in the gcc source.

/* The macros here implement a set of templated vector types and
associated interfaces. These templates are implemented with
macros, as we're not in C++ land. The interface functions are
typesafe and use static inline functions, sometimes backed by
out-of-line generic functions. ...
That is screaming out to be replaced by a std::vector. There are other examples where simple inheritance is mimicked using a slew of (un)defines and switch statements. Some of these are so complex, I wonder whether there will be any performance loss due to the introduction of virtual function calls. Certainly, it will be a win in terms of maintainability.

[1] Although in combination you get the expression template paradigm, which allows you to build a really nice numeric vector class that unrolls all loops at compile time and does not suffer from virtual function overhead, making it as fast as manually programming the vector arithmetic in C but much more convenient to use. Then you go back to using std::valarray which is close enough…