Computer

Two days ago, I updated my laptop from Ubuntu 6.06 "Dapper Drake" (aka LTS) to "Feisty Fawn", aka version 7.04. Just in case you wonder, how I did that, I just followed the usual directions and first updated to Edgy and then to Feisty via issuing "gksu 'update-manager -c'" twice. Things went quite smoothly, but I did encounter some problems:

- I lost access to my databases during the migration from Postgres 7.4 to 8.2., i.e. there was no proper migration and as support for version 7.4 has been dropped, I even have no way to dump the old data and import it again. I need to figure out whether I can easily access the old dbs from Postgres 8.2 (mind you, I'm talking of the raw data and the DB server, not client access).

- As a result, my local copy of serendipity stopped working. I re-installed serendipity (a clean start seemed to be a good idea), but still Iceweasel gets wrong information about the phtml files it generates. Probably a problem with the PHP installation, which I need to get straight (I'm not a PHP guy, though).

- When booting into Edgy, when switching from the splash screen to X. the screen went black and there was no way to get a display. I solved that by ssh-ing into the box, modifying /etc/X11/xorg.conf by using the ati driver instead of the fglrx driver and then editing /boot/grub/menu.lst so that it wouldn't show the splash screen or suppress messages. The problem went away after going to Feisty.

- To get VMware running again, it wasn't enough to issue the usual /opt/bin/vmware-config.pl that you have to do with every new kernel. It kept telling me that the headers directory wouldn't fit my current running kernel. Fortunately, I already had loaded the new version down which solves the problem (I guess there is a new version numbering scheme in newer kernels).

- The update of course also brought with it the switch to Iceweasel, so of course, I lost some of my trusted extensions (Reveal, Surfkeys).

- What really annoyed me was the ugly, fat looking "optimal" font that I encountered in most applications. Why Gnome doesn't use subpixel hinting as a default is beyond me (especially as I'm quite certain to have had that setting in the old setup, too).

- The new eclipse version of course knew nothing about my local installed plugins, implying that I had to reinstall them.

On the nice side, my mail setup kept working and the network setup kept working, which I think is way more important.

Joey seems to have inspired a "list of programming languages you know"-contest over on planet.debian.org, so this is mine:

1. Basic (forgotten)
   I've started using Basic on the Commodore C64 and have used it considerably, apart from the intrinsics of peek and poke, which some would claim was what Basic on the C64 was all about. I also used Basic on the Apple II at school, but was spared any further need to use Basic.
   
2. Cobol (forgotten)
   I remember my old computer science teacher bringing white and green prints on endless paper and teaching us the joys of Cobol. Having used Basic before, it looked somewhat suspicious but not too alien. Fortunately, we only had to solve some simple problems on paper, as the Apple II only had .... DBase II, I think.
   
3. Pascal (forgotten)
   (Turbo) Pascal was the language of choice in the first semester at the University of Koblenz at the start of the nineties. I've did what I had to do in it, but never really liked it. From the occasional look I throw in Wirth's algorithms book I know I can still read it, but the language looks just as baroque as the copy of the book I have.
   
4. Prolog (forgetting)
   I've really done a lot in Prolog, being first exposed in the second semester to it. I remember to marvel at some guys who grokked the language at first usage in the initial course -- to me, having used only imperative languages up to then, it was a mistery. I still think Richard A.O'Keefe's book "The Craft of Prolog" is among the best CS books.
   
5. C/C++ (forgetting)
   About 1992, I somehow got interested in object-oriented programming. Free software was still unknown to me, so I bought a student edition of Turbo C++ and some Addison-Wesley book and of I went inventing another wheel. At the time, I also had to do some C hacking for some course at the university, involving MS Windows programming. I've used C over time in several smaller projects, but would never call myself a C hacker.
   
6. Assembler (forgotten)
   My first exposure to Assembler was with some book for the C64. I was very interested but understood next to nothing. I should program some I/O chip directly instead of just using "load $,8,1"? WTF? Next look was in University, of course. I still know enough bits to be able to grok more or less the output of (disassemble 'foo) of some (tiny) foo-function in CL on an i386-style machine, but that's about it.
   
7. Mercury (had interest in)
   Mercury seemed like a nice successor to Prolog, adding several features of functional languages. I read several manuals, had several installations and never used it for anything.
   
8. Life (had interest in)
   Another possible successor to Prolog, which I've learned about at a summer school for language, logics and information. That's about all I remember.
   
9. XLisp (forgotten)
   My first exposure to Lisp in the context of a course for computational linguistics. The only thing worse than the editor used in the system was the tutor giving the course. A horror of parenthesis is about the only thing I remember.
   
10. Shell scripting (daily usage)
    I think since 1992 or 93 I've been using Unix systems and shell scripts. I no longer can remember whether our Suns dumped you into csh or sh or whatever, but since I've been using Linux systems (since 94), I've been using bash and written bourne shell scripts. Of course, I've also written the occasional csh script abdomination, but "Csh programming considered harmful" was an early lecture.
    
11. Emacs Lisp (forgetting)
    I remember seeing one of my instructors doing nearly miracles with XEmacs and wondering how his fingers could be that flexible -- I know that now. I've written several small utilities in Elisp and keep using it occasionally.
    
12. Common Lisp (improving)
    When I started a student job in 1995, I also started using Common Lisp, using Steele's CLtL2. Having used Elisp before, I no longer was worried about parenthesis. I still keep finding areas I didn't know or used before. And it's a language large enough that keeps you re-learning tricks you thought you knew. Which didn't stop me from giving a course on CL, which in hindsight didn't have the right focus: instead of showing that CL is just as capable of doing whatever you expect, it's also capable of doing you won't expect.
    
13. Smalltalk (interested)
    At the computational linguistics lab in Freiburg, the parser system was implemented in Smalltalk, so when I started there I took a small course in Smalltalk. As I worked more on the knowledge representation side of the system, I only rarely used it, though, so rare indeed, that I never got to do anything serious with the language. I still can read Smalltalk despite it's somewhat unusal syntax and have to do that even sometime.
    
14. Tcl (forgotten)
    We wanted to extend a linguistic annotation written in Tcl, so I bought a book and started digging through the code. Soon enough a student took over the job (and did it rather well), so I started the tiny bits I've learned quite soon. I remember finding the concept that every thing is a string to be rather messy and still see it as a lame excuse for dynamic/weak typing.
    
15. Perl (static)
    For nearly ten years, I had been using shell and/or Emacs to solve any data mangling tasks when I finally gave in and had a closer look at Perl. I still find it amazing how quick and dirty it's possible to solve problems in Perl, but on the other hand I've given up Perl for more complex tasks that require some thought and design, since Perl's syntax and language idiosyncrasies keep leading me to programs I don't even like myself.
    
16. XSLT (improving)
    At about the same time I started using Perl, I also needed to transform a set of XML documents and XSLT was all over the media, so I had a closer look. I dislike the noisy syntax of XSLT and particular the intermix with output elements and it's fever for being a "clean" functional language. But the concept of XPath and the idea of traversing a document via axis I find very compelling.
    
17. make (static)
    For a long time the power of make didn't occur to me. A colleague of mine, however, used it to implement a nifty workflow for document processing, of which I learned a lot of tricks when I needed to mimic it for a different task.
    
18. Ruby (improving)
    When I finally was fed up with Perl, I looked around to find Ruby as a nice halfway compromise between Common Lisp and Perl. It's still fancy and geeky and with Ruby on Rails has a lot of buisness ballyhoo around it, so I hope it will see more use in my current surrounding.
    
19. Java (not interested)
    Like everybody else, I couldn't avoid looking at Java. It seems to be the Cobol of today and as such is the job guarantee today. But Java looks so boring, I can hardly stand it. And this with regard to both the language and the results produced with it. Sigh But still, it's likely that someday I'll going to buy another book (that would be my third Java book, the first being O'Reilly's Java in a nutshell for Java 1.1 in maybe 1997 or so?), since just like Cobol at it's time, avoiding Java is hard ...
    
20. Python (not interested)
    When Python 1.4 hit the scene, there was quite some bubble around it. It burst quickly and as my latest review of the language reveiled last year, it still doesn't seem interesting.
    

Missing in this list is stuff like Scheme, Dylan, Oz, Oberon, Eiffel, Haskell and probably some other "tiny" languages which I looked at at some point in time and really didn't ever took a second look. Of those, I may take another look at Haskell in the future, but currently I have no concrete plans in doing so.

I love the Unix toolbox:

[elendil->Get_the_gore]mp3info -p "%S\t%m:%02s\t%t\n" * | perl -ne '{ $time=$time+$1 if (/^(\d+)[ \t]+(.*)$/); print $2."\n"; } END { print "Total seconds: $time\n"; $min=$time/60; $secs=$time%60; print(sprintf("Total time: %d:%d\n",$min,$secs)); }'
2:10 Fox in a box
3:16 Loaded heart
2:53 All grown up
3:07 Pleasure unit
2:51 Where evil grows
3:16 Casino
2:38 Don't cry
2:24 Mary Ann
3:48 You lied to me before
1:50 So sophisticated
2:50 Little baby
2:44 Sweet potato
2:56 Voodoo doll
1:51 Hammer stomp
Total seconds: 2314
Total time: 38:34


Printing out the track number and the track title works only if the file contains an ID3 tag, of course.

For a review, I needed to get the track list of a given CD. As the track list wasn't available via CDDB, I went to some large online store and found the tracklist. I need to convert it to XML, though. The original data I fetched looks like so:

1. Fox In A Box
2. Loaded Heart
3. All Grown Up
4. Pleasure Unit
...

whereas I need:

<li id="1">Fox In A Box</li>
<li id="2">Loaded Heart</li>
<li id="3">All Grown Up</li>
...

After cutting the original data to my Emacs, writing out a simple file and using Perl for that simple transformation seemed just gross. In the past, I've been an Emacs hacker. But no more, or so it seems, since it took me nearly half an hour just to come up with this simple function:

(defun tracklist-to-li (point mark)
  "Generate a string with <li>-elements containing tracks.
Assumes that one every line of region, a track position 
and the track name is given."
  (interactive "r")
  (save-excursion 
    (goto-char point)
    (let ((current-pos (point))
	  (result ""))
      (while (re-search-forward "^\\([0123456789]+?\\)\.[ \t]+\\(.*\\)$" 
				mark t)
	(setq result
	      (concat result
		      "<li id=\""
		      (match-string 1)
		      "\">"
		      (match-string 2)
		      "</li>\n"))
	(setq current-pos (point)))
      (message result))))

What took the most time was that I've had forgotten to escape the grouping parenthesis in the regular expression and that it took me a little while to accept that there is really no \d or equivalent character class in Emacs regexps. Which probably means that I've been doing too much in Perl, sed and the like. OTOH, it just may hint at the horror of regular expressions handling in Emacs. What I also dislike is that whenever you want some result in Emacs and see it, too, you have to invoke an interactive operation like message. Of course, there is IELM, but this doesn't really help you for interactive functions operating on regions.

And five minutes later, I realize I need to convert some string like "The (International) Noise Conspiracy|The
Hi-Fives|Elastica" into a similar list structure. With a simple cut & paste and roughly 30 seconds later, I have

[bauhaus->~]perl -e '$a="The (International) Noise Conspiracy|The Hi-Fives|Elastica"; @a=split("\|",$a); 
foreach $b  (sort @a) { print "<li>$b</li>\n"; }'

Hmm. Perhaps I've come quite a long way on the dark side already ...

On the other hand, in Ruby, this is just as simple (I'm using irb, the interactive ruby shell here):

irb(main):008:0> a="The (International) Noise Conspiracy|The Hi-Fives|Elastica"
=> "The (International) Noise Conspiracy|The Hi-Fives|Elastica"
irb(main):009:0> a.split("|").each {|string|
irb(main):010:1* print "<li>"
irb(main):011:1> print string
irb(main):012:1> print "</li>\n"
irb(main):013:1> }
<li>The (International) Noise Conspiracy</li>
<li>The Hi-Fives</li>
<li>Elastica</li>
=> ["The (International) Noise Conspiracy", "The Hi-Fives", "Elastica"]

The difference here is the implicit array Ruby generates, which of course in Perl you could hide in the array position of the foreach loop. Note the annyoing misfeature of irb to always show the prompt even when your still continuing your current input line.

In Common Lisp we can do it just as short:

CL-USER> (let* ((a "The (International) Noise Conspiracy|The Hi-Fives|Elastica")
		          (splits (ppcre:split "\\|" a)))
	           (loop
      	              for string in splits
	              do 
	                  (format t "<li>~S</li>~%" string)))
<li>"The (International) Noise Conspiracy"</li>
<li>"The Hi-Fives"</li>
<li>"Elastica"</li>
NIL

The same thing here: The result of the split could have been easily embedded in the loop.

The lesson, of course, is that in the end this example only serves to show that things that are easy to achieve in a high-level are indeed easy to achieve. Or to put it otherwise that the use of regular expressions is no more a discriminating feature between programming languages.

Gary King discusses some issues of XSLT. He concludes:

I still feel as if there is less here than meets the eye; that it ought to be possible to express these graph-transformations more elegantly and with less fuss and bother.

To me, the only interesting part of XSLT isn't XSLT itself, it's the embedded XPath where XSLT's power comes from. XPath is a pair of scissors for cutting out the nodes of an XML document instance you're interested in and is about as powerful (and hence horrible to get right) as regular expressions (although it's something completely different, of course). XSLT is just the framework which provides a relatively boring set of instructions and control-flow operations. And it's "clean functional" design only gets in the way every so often. Sure, coming from a Prolog and Lisp background, I know all the tricks to work around the hassle, but quite often it would be way easier to just set that damned variable *again*. If I want to do clean functional programming, I know where I can find a language without that XML syntax, thanks. Give me the unclean intermix of programming styles offered by Common Lisp anyday, please.

Being a Lisp guy just like Gary, I would be happy to use a language with parenthesis, as I have to do XML transformations quite often and the intermix of elements from different namespaces (XSLT namespace and target namespace) is mostly a pain to read and write. Using xslide, an Emacs mode for XSLT, eases the pain a considerable bit, but it still isn't really fun. And sometimes I need to hack XSLT in a proprietary system which only provides editor capabilities that know nothing about XML (think notepad-style editing capabilities) and then XSLT suddenly has the next most horrible syntax imaginable. However, the corporate world has its own rules and to be fair, the major benefit of XSLT is that you have one standard syntax for XML transformations rather than having xyz numbers of incompatible library APIs.

Update: Also in response to Gary, David Lichteblau pointed out his approach to (macro-)pre-processing XSLT stylesheets to overcome some of Gary's problems.

Recently, there was a discussion about "the rise of functional languages" over on Linux weekly news, in which one of the participant claimed that one of the major reasons why nobody uses functional languages in industrial settings would be the lack of explicit resource handling (where a resource is some supposedly "alien" object in the system, say a database handle or something like that). What he was referring to was the inability to run code on allocating/deallocating a piece of resource. Of course, some people pointed him to various solutions, in particular I recurred to the usual WITH-* style-macros in which one would nest the access to the data while at the same time hiding all what one would do on allocation/de-allocation. His reply went something along the lines that such objects may need to be long-lived (thus a WITH-macro is inappropriate) and that the only resort would be the garbage collector and that there simply is no way of running code at a guaranteed (de-allocation) time. I have to admit that I have no idea how I could code around that problem in Common Lisp (garbage collection even isn't a defined term in the ANSI specification of CL, and I'm very sure I haven't seen any mention of allocation/deallocation in it).

Now, some months later, there is a discussion in comp.lang.lisp on the topic of "portable finalizers" and Rainer Joswig pointed to this chapter in the Lisp machine manual which talks about explicit resource handling the lisp machine. From the excerpt, I can't judge whether resources are first-class CLOS objects and hence the functions to handle them are generic functions, but if so that would actually allow running code on deallocating a resource, of course with the price of having to handle allocation/deallocation manually. I really wonder if any of todays CL implementations offers the same or at least similar functionality?

Using Common Lisp, I want to split a list into two parts, in which the first resulting part has a fixed size (say 20 elements) and the rest, well, contains the rest of the list. This should also work when the list is actually shorter than the limit, which means I can't use subseq. The typically approach I would have chosen would involve the two traditional functions for doing something iteratively in CL, i.e. do, dotimes or dolist. However, this is ugly, and for the sake of learning something new, I had a look at how to solve the problem with loop.

Etch ships with drivers for the Ralink RT2570 wifi/wlan chipset in the package rt2570-source. However, for whatever reason, if I try to use that package (i.e. compile it the usual Debian way via make-kpkg modules-image and install the resulting deb), modprobe rt2570, I only see that the usb subsystem sees the adapter but I get no interface (rausb0). I then just recompiled my local CVS copy from last summer, modprobe/insmod it and everything is fine. Huh?

Update: I updated to 2.6.21.1 today, using a fresh vanilla kernel. Still Debians module compiles flawlessly, can be installed and the module installed, but no working interface shows up. Manual compiling/installing the old CVS version (probably by a month younger) works out of the box.

Today, I was bitten by this problem: Illegal :ASCII character starting at byte position 16. I had some data I wanted to exchange with my Postgres DB but somehow, my Emacs consistently lost his connection to SBCL when I hit data with special chars (German umlauts encoded in ISO Latin 1). Investigating further, it became clear that SBCL had the problem without Slime, too. I was rather surprised then to see the solution in the thread linked to above: It was indeed a slime setting that fixed the problem. On a second look, I don't encounter the exact same problem, as I have trouble with encoded data in the database, not with the initial connect. But the solution suggested by Nikodemus Siivola helps me as well. There have been at last two other threads on the mailing list with regard to Unicode and Postgres, the last one is from April this year. Somebody from the slime camp could probably explain what that slime-setting does to SBCL that it affects SBCL connection to Postgres via CL-SQL. Perhaps I'll go and have a look. Ah, the joys of open source.

Update:I was under a wrong impression. I previously had set SB-IMPL::*default-external-format* to :LATIN-1, a suggestion from the same thread. The slime setting only handles the communication issue with Emacs, but setting the variable on the sbcl side fixes the real problem.

In my workstation I still operate a Matrox G400 back from 1999. It was a state of the art graphics card for its time, and especially well supported under Linux/XFree86. Well, time went on and now everybody's using X.org. Since two days ago, my workstation joined the club, finally having been updated to etch. And then I find a discussion in the Usenet group de.comp.os.unix.linux.hardware with somebody complaining about a freezing system with X.org/mga when switching to the framebuffer console. And of course, I can easily reproduce it: Switching back to X immediately hang the system. Suspend to disk hangs up the system, too. Great.

A little bit of searching quickly revealed this horrible list of bugs for xserver-xorg-video-mga in Debian, from which one bug in particular links to this upstream bug entry. See the date of the last change to this bug? It's almost three years old! I am now trying with "UseFBDev" set to "false" and at least I could switch three times back and forth, but we will see.

Since over a month, I have a Debian Etch DVD lying around. Last night, I finally finished backing up any valuable data and started the upgrade, closely following the careful upgrade instructions given in the release notes. This worked quite well, some minor glitches have happened, though. For instance, wmsensors and wmwifi were removed, although at last wmsensors is included in etch; I haven't checked wmwifi yet. Then my mouse stopped working. Turned out, I never updated gpm.conf from my old serial mouseman configuration to the newer usb mouse I have since quite some time. This was easy to fix, though. Finally, the installation of iceweasel aka Firefox 2.0 resulted in the loss of two of my favourite extensions: SurfKeys, which for instance allows to move between tabs with "o" and "u" and Reveal, which shows mini views of the contents of other tabs. I can live without Reveal but I'm going to look for a replacement for SurfKeys (yes, I use hit-a-hint and keyconfig, but I don't know how I can configure moving between tabs). There is probably more that needs fixing, but nothing spectacular so far.

Update: The surfkeys problem can be solved (see this discussion).

Was wir seit einiger Zeit an diversen Ereignissen, Vorhaben und sonstigen politischen Hirngespinsten präsentiert bekommen, habe ich neulich ja noch als Masche abgetan, möglichst maximalen Unsinn zu fordern, um damit deutlich mehr (im Sinne von Zugriffsmöglichkeiten und Einschränkungen von Bürgerrechten) rauszuholen als sonst möglich wäre. Aber entweder sind selbst die intelligenteren Mitbürger mittlerweile total abgestumpft oder durch das ganze Terrorgefasel derart weichgekocht, dass die selbst den größten Unsinn noch durchbekommen, wenn nicht bald mal mehr "normale" Leute sich ihrer Bürgerrechte und -pflichten erinnern. Da kommt doch eine Anleitung zum Lobbyismus für Nerds doch genau rechtzeitig. Allerdings wäre es wohl nicht im Sinne von Hannos Anleitung, zu einem evtl. Termin dann ausgerechnet in diesem T-Shirt zu erscheinen (via Kristian & Fefe). Aber vielleicht ist es das Wichtigste, überhaupt mal aus dem Quark zu kommen.

I'm using XEmacs whereever I can, but for preaching to the still unconvinced, the guided tour to Emacs as of the FSF will be just as useful. Of course, XEmacs ships with a much larger portion of modes and utilities, but unfortunately, development has been quite slowly in the last years and Emacs 22 as of today has come a long way to overcome a lot of the obstacles of older versions.

Which Programming Language are You?

In an older blog post, I noted that there is no editor integration for the newer distributed versioning systems with Emacs. Turns out, I was quite wrong. First of all, there is an entire page about handling version control in Emacs at the Emacs Wiki. I haven't looked at all of them, but stumbling over DVC, I must confine that there is work under way to have a decent interface in Emacs to those new kids on the version control block. Looks as if DVC is even build or shipping with XEmacs. No more excuses around here, move along ...