Archive

Archive for the ‘Tools’ Category

Emacs : eldoc mode and c-eldoc mode (via Passing Thoughts)

July 9, 2010 1 comment

Here’s an excellent Emacs minor mode that I discovered last week, as did our friend at Passing Thoughts:

Emacs : eldoc mode and c-eldoc mode eldoc mode as the name suggests provides documentation for Elisp files. This is a very useful and cool mode and shows the function signature in the mode-line when your cursor is on a particular function.  It also provides info on the variables. Check out the screen-shots below. To start eldoc mode, add the following to your .emacs file ;;Turn on documentation in elisp mode (add-hook 'emacs-lisp-mode-hook '(lambda () (turn-on-eldoc-mode))) c-eldoc … Read More

via Passing Thoughts

Are sysadmins failing Free Software?

Today I attempted to run a simulation on the university’s Beowulf cluster and a simple shell script returned an error saying that mktemp was not present. Really? I have this experience all the time: I go from my Fedora System to the university’s RHEL system and find out that my workstation is a heck of a lot easier to use because on the cluster a package is missing, or there’s some security measure or other sysadmin preference that prevents me from using the system the way I should be able to use it.

To me this is merely annoying, but I think the Free Software movement needs to take notice of this. Here’s the real problem: people view “Linux” (their name for it, not mine) as a workhorse, something that no one would willingly use unless they need “performance.” A lot of people talk about what a pain it is to use “Linux” while I think it is a joy to use, and it’s a pain to use anything else. Perhaps the reason they think so is because they’ve only had contact with systems run by system administrators who keep everything too tightly locked down. I use “Linux” in quotation marks because the experiences these people have is so drastically different from the stable, capable GNU System I use for all my computing.

My first exhibit was the lack of mktemp on this thoroughly outdated RHEL system, but my second is that whenever I’m around system administrators, they talk about having problems that I have never had administering GNU systems on home and office workstations. Last time I was in such a situation, I told this to somebody and she was really nice about it: she said “We might just be doing everything wrong.” I understand she was just being tactful (though more than average), I highly doubt that I have all the answers. Anything that I have done that wasn’t part of a default install was something that was no more complex to figure out than reading the manual. But I’m not going to RTFM a room full of sysadmins, am I?

The problem I see for the Free Software movement is sysadmins are not motivated in any way to promote free software, at least not most of the time. On top of that, their jobs are certainly not easy and they don’t have most of the power. They have the sort of “spit on your french fries” power that unfortunately makes them defend their decisions ruthlessly, even if they’re shown to be wrong.

This becomes a problem for me advocating free software on a personal and minor public level because if I have a room full of scientists, most of them have used “Linux” but very few of them even know it can have a GUI. Even I didn’t know that until 5 years ago! Furthermore if any of them have tried using GNU/Linux and have faced continued frustration because the machine they’re working on doesn’t work, I’m not going to convince them of anything.

I’m not saying that sysadmins ought to put free software advocacy first; what I’m saying is that pretty often they make these machines like old Unix machines, instead of GNU machines — machines with no arbitrary limits, portable tools and an emphasis on enabling users to be active participants. If they could focus some of their energy on that, and their bosses would let them, then we’d all have an easier time telling people the benefits of free software.

Emacs Auto-complete Mode

I’ve just discovered a new add-on for Emacs called auto-complete-mode. After watching the video I was skeptical: I thought “this is going to get annoying really fast. However, after giving it a quick try, it is pretty cool. I think it will be especially useful in programming modes, since it presents your own symbol values from the current buffer as completion values. Also, auto-complete-mode only tries to complete if you pause typing. You can also bind a specific key (the author recommends M-TAB) to initiate auto-completion.

So I just typed “auto-completion” and the first choice that came up when I paused after “auto-compl” was “auto-complete-mode,” but then I hit TAB after the menu comes up and “auto-completion” is there now too. In other words, auto-complete-mode is smart: it learns.

Links:

Categories: Emacs, Tools Tags:

Totem Youtube Plugin

My favorite media player right now is Totem or “Movie Player” as it appears in the menus. I’ve been listening to music at work using Totem for weeks now and I like it better than Rhythmbox or Amarok, or any of the mpd or xmms2 clients.

My other major music player has been Mozilla Firefox, where I can look up plenty of videos with good sound quality on Youtube. My current favorite performer, Kate Bush, has tons of live performances and videos on Youtube with (as I said) good sound quality. Not great, but listenable. The biggest problem, however, is that I can’t use my keyboard “media” buttons to control the videos in any more than the volume, and pausing them requires switching to another desktop. This wouldn’t be so if Youtube hadn’t done away with the popup player; they’ve brought it back for some videos, but it doesn’t quite work the way it used to, which was annoying. At least with the popup player I could search videos from a small window and keep them on the same virtual desktop as my work. This is not so much so I can see Lady Gaga prancing around, but just to be able to control the videos and maintain my precious economy of motion.

However, today I discovered the Youtube plugin for Totem. I can’t even remember what I was looking for — I think it was visualizations — but “yum search totem” turned up the Youtube plugin, and away I went:

# sudo yum install totem-youtube

(remember that I’m using Fedora). Now you can search and play Youtube videos directly from Totem, play and pause them with the media buttons. Excellent!

Back up your Subversion and Mercurial repositories

June 28, 2010 1 comment

This morning I cooked up two scripts to back up my VCS repositories. I have two Subversion repositories locally, one for my main research project and another for my homepage. I have three hg repositories at the moment, one for local shell scripts (like the ones I was writing), one for my configuration files and another for an extended book project I’m working on.

The svn-oriented script takes either command-line arguments or reads repository paths from a file (~/.svnbk), each one on a single line. It makes (not “takes”) an svnadmin dump to stdout, which is compressed with the best available compression program, in the specified directory.

#!/bin/sh

# svnbk.sh: A tool for backing up my SVN repositories
#
# Copyright (C) 2010 Joel James Adamson
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
# 02110-1301, USA.

# Usage:
#  svnbk.sh [repositories] bkupdir
#
# If `repositories' is empty then svnbk.sh will look in ~/.svnbk for a
# list of repositories to back up; repositories will be dumped to
# compressed files in the directory `bkupdir'

# If available, use xz compression; otherwise use bzip2; if
# unavailable use gzip
XZ=$(which xz)
BZ2=$(which bzip2)
GZIP=$(which gzip)

if [ -x $XZ ]; then
    ZIP="$XZ"
    EXT=".xz"
elif [ -x $BZ2 ]; then
    ZIP="$BZ2"
    EXT=".bz2"
elif [ -x $GZIP ]; then
    ZIP="$GZIP"
    EXT=".gz"
else
    printf "Compression unavailable; dumping to uncompressed dump files\n";
    ZIP="none"
    EXT=""
fi

# Command-line variables
declare -a argv
argv=("$@")
# number of command-line args
argc="${#argv[@]}"
LAST=$(($argc - 1))
BKDIR=${argv[$LAST]}
# now to get a list of repositories from the command-line, we copy
# argv, then destroy the last element:
declare -a REPOS
REPOS=(${argv[@]})
unset REPOS[$LAST]
if [[ -z $REPOS ]]; then
    while read repo ; do
	FILE="$BKDIR/svn_$(basename $repo).dump$EXT"
	svnadmin dump $repo | $ZIP - > $FILE
    done  $FILE
    done
fi

The Mercurial backup requires you to initialize remote repositories, which is easy if you’re backing up to a mounted CIFS or NFS partition. Unfortunately, hg init does not create the directories on the CIFS partition I’m using, so I used the following:

joel@cifshost > mkdir hgbak
joel@cifshost > cd hgbak
joel@cifshost > mkdir bin
joel@cifshost > cd bin
joel@cifshost > hg init

After that the hg push should work just fine. The config file for this one has the local repository followed by the remote repository on each line. It does not use any compression:

#!/bin/sh
#
# Copyright (C) 2010 Joel J. Adamson
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
# 02110-1301, USA.

# hgbk.sh: A tool for backing up my hg repositories
#
# Usage:
#  hgbk.sh [repositories] bkupdir
#
# Read ~/.hgbk for a list of repositories to back up; the syntax of
# the file specifies
#
# [local repository] [remote (backup) repository]

# now to get a list of repositories from the command-line, we copy
# argv, then destroy the last element:
while read -a repo ; do
    cd ${repo[0]}		# full pathname!
    hg push ${repo[1]}
done < $HOME/.hgbk

Pretty easy, but saves a lot of time. The only non-automated part is the initial remote repository. I then activate them with the following script, placed in ~/.cron.daily/:

#!/bin/sh

ERRLOG=$(mktemp)
/home/joel/bin/svnbk.sh /home/joel/bioark 2>| $ERRLOG
SVNRC=$?
/home/joel/bin/hgbk.sh >> $ERRLOG
HGRC=$?
if [ $SVNRC -ne 0 ] || [ $HGRC -ne 0 ]; then
    mail joel < $ERRLOG
fi

rm $ERRLOG

You can download these from my homepage. I welcome comments and improvements.

Software is Not Just a Tool (via The World)

Here’s an excellent posting on the problems of different perspectives about what software is, and what makes it useful. There’s a fundamental divide between developers who believe users should just use the software the way they make it — whatever their malicious motives are — and developers who treat users with respect.

One of the most frustrating things I do in my daily work is wrangle with CSS. Trying to get a particular website to display correctly on multiple browsers and screen resolutions without ruining my HTML semantics can be an extremely painful process. Anyone who's ever had to do this knows the reason: browsers implement CSS differently, and sometimes (in the case of Internet Explorer) incorrectly and without any sort of sanity. The causes behind the … Read More

via The World

Subversion Causes Brain Damage (according to Joel Spolsky)

June 22, 2010 4 comments

I just read part of a Mercurial tutorial by Joel Spolsky and I’ve been thinking about it since I read it. Some people just don’t get it. In this case Spolsky doesn’t seem to get what Subversion is for. He makes the claim that people who use Subversion are “Brain-damaged” for the following reason:

Subversion team members often go days or weeks without checking anything in. In Subversion teams, newbies are terrified of checking any code in, for fear of breaking the build, or pissing off Mike, the senior developer, or whatever. Mike once got so angry about a checkin that broke the build that he stormed into an intern’s cubicle and swept off all the contents of his desk and shouted, “This is your last day!” (It wasn’t, but the poor intern practically wet his pants.)

Okay, so his point is made, but the problem is that he and these people obviously haven’t read The Subversion Book. What he’s describing is people checking in code that they haven’t tested, which is really stupid. What the book says to do is always test before you commit, and if you’re trying something radical make a private branch (which is bloody easy with Subversion), and do your experimenting. Then you merge that branch into a working copy of the trunk, test the changes, and commit if it works. The book generally encourages boldness in the name of collaboration; they certainly discourage the despotic “lead developer Mike” depicted above. If you find out someone’s committed a bug, the mature thing to do is revert the change, then go to the person (or send him an email) and say “Please test before committing.”

I’ll admit that I’ve not worked at the same level of collaboration as Mr. Spolsky, but I have read the (friendly) manual. Version control is all about the ability to track changes, make branches, and do thorough testing. And most of all it’s about the ability to maintain the entire history of your project so you can undo big mistakes. I’ll also say that my attempts so far to demonstrate Subversion to people have resulted in people simply not getting it. However, what they didn’t get was version control, not centralized version control. The situation would have been no different if I’d shown them Mercurial.

Furthermore, every Subversion (or git, or bzr, or hg, or CVS) repository I’ve ever gotten code from has a big disclaimer that says “This might be broken, don’t expect it to work.” Even Emacs has that and it has always worked. I guess this sort of thing is expected in the free software community whereas it is part of a huge scheme of denial in the non-free software community (if you can call it a community).

The other thing that Spolsky doesn’t seem to get is Unix. What Subversion does is model a Unix filesystem hierarchy and record the changes to that filesystem hierarchy. One of the beautiful things about Unix is that the filesystem hierarchy is significant, i.e. it means something. Subversion knows that and it does a damn good job of exploiting all the beauty of it. Those of us who can tell that Unix is The Right Thing are always going to have a hard time explaining how simply beautiful it is. Subversion has obviously spread beyond the “worse is better” community, and people out there often just don’t get it.

A little background

If you’re one of my non-programming friends or you’ve never used version control, or are thinking about it: Version control is a scheme for recording changes to a set of files. For example you can keep track of changes to documents, program code, or basic directory structures. If someone makes a change to a program and introduces a bug, you can undo it, in a way.

For a long time the only game in town was a set of programs called CVS (for Concurrent Version System). CVS was cool in its time but had a number of problems, so instead of improving it beyond all recognition, a team of developers created a beefed up, slightly more sophisticated one called Subversion.

With CVS and Subversion, you download (“check out”) code from a centralized repository (a database system on a server somewhere) that everybody checks their code into and out of. The repository is a centralized place for development. This model does have some shortcomings, though none that are completely damning; it’s still good for many types of projects.

As an alternative the Linux Kernel developers and a few others developed distributed version control systems, where every developer has his own “repository” locally where he or she checks in changes to code. To communicate changes to others, or get theirs, you “push” and “pull” changes, respectively. This has a number of advantages, but again it’s not a panacea. It’s good for some projects whereas Subversion is better for others.

For the kind of programming I do, Subversion is my choice. Also for my homepage, I use Subversion because the directory structure of my webpages is very important. However, for my configuration files and a writing project that I expect is years away from publication, I use Mercurial.

The unfortunate thing about distributed version control is that it’s a fad and therefore everybody’s raving about it and dissing the perfectly good system of centralized version control. I think that Mercurial and git are better than a fad, but I don’t think they solve every problem the way some people do. They start referring to decentralized systems as “modern.”

About the author

Joel Adamson is a graduate student in evolutionary biology; he uses Subversion and Mercurial for managing his projects.

%d bloggers like this: