Yenya's World

Fri, 30 Jan 2009

"Too late for -CS" Howto

Speaking on portability: I have recently came across a problem with the newest Perl. We start most of our scripts with the -CS or -CSD switch on the shebang line. Since perl-5.10, this no longer works, it fails with Too late for "-CS" option error message. While I don't understand what has led the Perl developers to this incompatible change, here is the workaround:

The -CS switch can be substituted with the following code at the beginning of the script:

use open ':std', ':utf8';
use open IO => ':bytes';

and the -CSD switch can be replaced with just

use open ':std', ':utf8';

Morale of the story: the most portable languages (and language features) are those which are sufficiently old (which Unicode support in Perl or the STL library in C++ is not). Apart from this problem Perl still seems to be a relatively portable language even for large projects such as IS MU.

Section: /computers (RSS feed) | Permanent link | 3 writebacks

Thu, 29 Jan 2009

Questionable Content

When browsing the Web, one can often find a content, which is - how to say it - questionable. Recently I have found an excellent example of it :-)

Hannelore Questionable Content is a web comic written by Jeph Jacques. It is not only interesting and funny, but it also contains humanoid robots, lots of rock music references (not that I get most of those), occasional anime references, and the highest proportion of characters with mental disorders from all the web comic strips. The only annoying part is occasional filler strips and guest strips. But on the other hand, it is actually released five times a week (unlike the Order of the Stick these days).

For a light intro you can read for example the story arc beginning in the strip #1322 from a week ago. Or start from the beginning. Favourite character? Hannelore the obsessive-compulsive disorder, of course. Go forth and waste your time :-)

Section: /world (RSS feed) | Permanent link | 0 writebacks

Wed, 28 Jan 2009

C++ Woes

I wonder why even these days people start new open source projects in C++. C++ is - as far as I know - by far the least portable compiled language. I would understand using C++ in big proprietary projects, where everything including the compile-time environment is fixed. But for open source projects, where compiler versions, header file features, etc. vary greatly? No way.

The project I hate today is named IMMS. While trying to compile it I had to edit 11 different files, adding #includes all over the code. I wonder how this could have been buildable anywhere at all - there were missing prototypes/definitions for things like memcpy(), INT_MAX, abs(), etc.

I cannot imagine how could it be possible at all for these symbols to end up defined in the author's build environment. The problem (one out of many) of C++ is that it is very strict about missing prototypes, but in turn it does nothing for preventing the namespace pollution, i.e. symbols being defined "accidentally", and thus the project being unbuildable elsewhere. I ran into the same problem a week or so ago when trying to compile a few months old version of Valknut.

Recommended reading: Linus' response to a question why Git is not written in C++. Morale: stay away from C++, or your projects will end up unbuildable after only few months.

Section: /computers (RSS feed) | Permanent link | 14 writebacks

Wed, 14 Jan 2009


I have finally got my feet wet with git. I have been playing with it before, but now I did some real work using it. There is a plenty of articles comparing git to other SCM systems, mostly pointing out advantages of distributed SCM. I will not repeat it here (altough it is also an important point), I will write about what I find most appealing on git specifically:

Unlike Mercurial, branches are first-class citizens in git. With hg, you are often better cloning the repository than undergo the pain of using hg branches.
Readability of changesets
git makes it really easy to make the development work readable by others. I.e. it allows the flow of changes to be neatly split into logical pieces, which can be then read, reviewed, and individually applied by others. This includes not only git-format-patch(1) which takes the history and makes each commit a separate RFC822-like file which you can mail to somebody else (and git-am(1) on the other side), but also git commit --amend which allows to edit the previously commited data. So as long as you do not publish the repository, you can rewrite the history as you like.
... AKA git-stash(1): you can postpone all your work just to commit a simple fix to something else, and then switch back to your long-term work.
It is fast!
... altough I have to find out when to call git gc and when/what to repack to be even more efficient.
No special server-side software to publish your changes
(not only git-specific) The repository is a directory structure which can be published e.g. via HTTP by any HTTP server. So when I wanted to contribute to some project, I just cloned its repository, commited my fixes, cloned it again to my public WWW space, and then mailed the developer "please pull from this URL and let me know what do you think". Zero-cost public repository setup (remember how long it took SourceForge to provide a public SVN repository?). Zero "politics" amongst developers (no "I have a commit access" anymore).

After having used CVS for many years, Subversion for some years, and briefly BitKeeper, Arch/tla, and Mercurial, I think Git is by far the best one (that reminds me: do not bother to read any articles comparing Git < 1.6 with Mercurial - present Git is very user-friendly and well-documented). So the message is: do not even thing about using a centralized VCS for new projects, and amongst distributed VC systems, at least have a look at Git.

What is your own experience with version control systems?

Section: /computers (RSS feed) | Permanent link | 1 writebacks


Yenya's World: Linux and beyond - Yenya's blog.


RSS feed

Jan "Yenya" Kasprzak

The main page of this blog



Blog roll:

alphabetically :-)