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.
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 :-)
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 :-)
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.
Wed, 14 Jan 2009
Git
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:
- Branches
- Unlike Mercurial,
branches are first-class citizens in
git. Withhg, you are often better cloning the repository than undergo the pain of usinghgbranches. - Readability of changesets
gitmakes 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 alsogit commit --amendwhich 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.- Hot-fixes
- ... 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 gcand 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?