A view from the hill

One of the bigger practical problems with unit testing is isolating the test coverage. Say, you want to test a piece of code from the middle (business) layer. Let's assume further the piece of code under consideration makes some calls to lower level code to retrieve some data. The problem of test coverage isolation is now that if you "simply" call your function, you are implicitly also testing the lower level code, which you shouldn't: if that lower level code gets modified in an incorrect way, you would suddenly see your middle level code fail although there was no change made to it. Let's explore ways to avoid the problems in Common Lisp.

There is a very good reason why you would also want to have such test dependencies to ensure your middle level code still works if the lower level code is extended or modified. But that is no longer unit testing: you are then doing so-called integration tests which are related, but still different beasts.

Now, I was facing exactly the typical dreaded situation: I extended an application right above the database access layer which had not seen much tests yet. And of course, I didn't want to go the long way (which I will eventually have to go anyway) and set up a test database with test data, write setup and tear-down code for the db etc. The typical suggestion (for the xUnit crowd) is to use mock objects which brings us finally on topic.
I was wondering if there are any frameworks for testing with mock objects in Lisp, but a quick search didn't turn up any results (please correct me if I've missed something). After giving the issue a little thought, it seemed quite clear why there aren't any: probably because it's easy enough to use home-grown solutions such as mine.

I'll use xlunit as the test framework, but that's not relevant. Let's look at some sample code we'll want to test:

(defun compare-data (data &connection)
  (let ((dbdata (retrieve-data-by-id (id data))))
    (when (equal (some-value data)
                (some-db-specific-value dbdata))
         t)))

The issue is with retrieve-data-by-id which is our interface to the lower level database access.
And note that we'll use some special functions on the results, too, even if they made just be accessors.
Let's assume the following test code:

(use-package :xlunit)

(defclass comp-data-tc (test-case)
  ((testdata :accessor testdata :initform (make-test-data))))

(def-test-method ((tc comp-data-tc))
  (let ((result (compare-data (testdata tc))))
    (assert-equal result t)))

Now the trouble is: what kind of testdata you'll need to hide between that call to make-test-data depends on the database that's going to get called by compare-data. So what we'll do now is to use mock objects and mock functions. Let's define a mock-object mock-data and a mock-retrieve-data function, which will simply return a single default mock object.

(defclass mock-data ()
  ((id :accessor id :initarg :id :initform 0)
   (val :accessor some-db-specific-value :initarg :val :initform "foo-0"))))

(defun mock-retrieve-data (testcase)
  (format t "Establish mock for retrieve-data")
  (lambda (id)
      (format t "mock retrieve-data id:~A~%")
      (find-if #'(lambda (elem
			(when (equal (id elem) id)
			  elem))
                    (testdbdata testcase))))

Why that mock-retrieve-data returns a closure will become clear in a second, after we've answered the question how these entirely different named object and function can be of any help. The answer lies in CLs facility to assign different values (or better said) definitions to variables (or better said to function slots of symbols). What we'll do is to simply assign the function definition we've just created as the function to use when retrieve-data is going to be called. This happens in the setup code of the test case:

(defclass comp-data-tc (test-case)
  ((testdata :accessor testdata :initform (make-test-data))
   (testdbdata :accessor testdbdata)
   (func  :accessor old-retrieve-func)))

(defmethod set-up ((tc comp-data-tc))
  ; set up some test data
  (dotimes (number 9)
    (setf (testdbdata tc)
             (append 
                  (list 
                      (make-instance 'mock-data 
                            :id number 
                            :value (concatenate 'string "value-" number)))
                 (testdbdata tc))))
  ; establish our mock function
  (when (fboundp 'retrieve-data)
    (setf (old-retrieve-func tc)
             (fdefinition 'retrieve-data))))
  (setf (fdefinition 'retrieve-data)
           (mock-retrieve-data tc)))

(defmethod tear-down ((tc comp-data-tc))
   ; After the test has run, re-establish the old definition
   (when (old-retrieve-func tc)
      (setf (fdefinition 'retrieve-data)
           (old-retrieve-func tc))))

You can now see why mock-retrieve-data returns a closure: by this way, we can hand the data we establish for the test case down to the mock function without resorting to global variables.

Now, the accessor fdefinition comes in extremely handy here: we use it to assign a different function definition to the symbol retrieve-data which will then be called during the unit-test of compare-data.

..Establish mock for retrieve-data
mock retrieve-data id: 0
F
Time: 0.013


There was 1 failure: ...

There is also symbol-function which could be applied similarly and which might be used to tackle macros and special operators. However, the nice picture isn't as complete as one would like it: methods aren't covered, for instance. And it probably also won't work if the function to mock is used inside a macro. There are probably many more edge cases not covered by the simple approach outlined above. Perhaps lispers smarter than me have found easy solutions for these, too, in which case I would like to learn more about them.

While I'm usually a happy VC user (the SCM mode of Emacs) as the next guy, I recently haven't always been so happy. In particular when I'm working on a larger set of changes in multiple files (using Subversion or Mercurial), the commit-per-file approach of VC just doesn't cut it, because usually you want to commit all changes you have to make for a fix or feature to happen in a single transaction. That's simply not possible with VC, so I usually fall back to the command line. That I can then use Emacs for the commit message is only a slight quantum of solace.
An integration of SCM features into dired (which I happen not to be a big fan of, btw.) looks to me like the obvious way to go. I'm hence very happy to learn that this is more or less happening (or has already happened) with the past-Emacs 22.1 version, according to this blog entry on manipulating changeset-based VCS from within Emacs. It's unlikely that this will be up to match Tortoise or TortoiseHg, but still ...

The Release Warp Lyrics


It's astounding, time is fleeting
Madness takes its toll
But listen closely, not for very much longer
I've got to keep control

I remember doing the Release Warp
Drinking those moments when
The blackness would hit me and the void would be calling
Let's do the release warp again...
Let's do the release warp again!

It's just a bug to the left
And then an error to the right
With your hands on your keys
You bring your fixes in tight
But it's the pelvic thrust that really drives you insane,
Let's do the Release Warp again!

It's so dreamy, oh fantasy free me
So you can't find me, no not at all
In another dimension, with capitalistic intention
Well-secluded, I see all
With a bit of a mind flip
You're there in the bug slip
And nothing can ever be the same
You're spaced out on sensation, like you're under sedation
Let's do the Release Warp again!

Well I was typing down the plan just a-having a think
When a snake of a marketeer gave me an evil wink
He shook me up, he took me by surprise
He had a business plan and the devil's eyes.
He stared at me and I felt a change
Time meant nothing, never would again
Let's do the Release Warp again!


(... with sincere apologies to The Rocky Horror Picture Show by Richard O'Brien)

Ah, holiday time, the time when you finally have some time on your hand. Time to hang around at beaches ... and to read some nice books. This time, I had four books with me, but found just enough time to finish two of them -- there was also swimming and sun bathing to do, mind you.

The first one, "The bed room secrets of the master chefs" by Irvine Welsh is a novel constructed around one interesting idea: what if you could transfer all your personal disasters over to the one person you're hating the most? Although it would be equally valid to say that the novel is constructed around the question what damages permanent alcohol abuse can do to your body, but something along this line is probably the connecting issue of Welsh's books anyway. What I particular liked about this book is the way in which Welsh describes the figures to encounter in British (or make that Scottish) pubs: judging from the few times I've been to a pub in the UK it's easy to take the picture Welsh is painting for real. A note of warning: if you don't like "explicit content" this is not a book to your likening and if you don't happen to be a native speaker (I'm German) this is not the easiest book to pick up. Funny and very recommended if you like pub novels.

The second book I've read is "Gangleader for a day" by Sudhir Venkatesh, subtitle "A rogue sociologist crosses the line". It's an autobiography and a fascinating one. Sudhir Venkatesh wanted to find out more about urban poverty in Chigaco and got to take a very close look into the ghettos of modern America. He befriends a gang leader in Chigaco and learns about how the people in the poor projects manage their lives. Although his writing is a little dry, the characters and stories are fascinating. It's of course a very particular look at american society, one which teaches you respect for the poor, but still one which doesn't increase my respect for the american society and its politicians as a whole. Well worth a read.

As you might have noticed, the software (serendipity) behind this blog has been updated, resulting in several new features. I'm not sure yet if I'll keep the ranking functionality (too few readers anyway to be useful), but the tags are unlikely to go away soon.

Update: as you might have noticed, the tags haven't been to stable. Automatic keyword parsing has have its unfortunate side effects. There still might be some wrong tags. Update2: And all categories are gone. Hooray. :-((

Ah, and the provider is now called weblog-writer.net instead of 1on.de.

Debian just published an update to their stable distribution etch dubbed etch-and-a-half. The big news here for everyone not accustomed with Debians release cycle anyway is that it's the first time that it's not only a point release that fixes security issues but it's an update to the stable release that gasp adds support for new hardware, too. It even brings important fixes for some applications.

First of all, that's a tremendously good step in the right direction. In the past I've been bitten more than once by the long release cycle of Debian, outlasting all care taking of hardware compatibility. It's the primary reason that the only machine under my direct control running Debian is my rusty private workstation at the moment, all other machines needed newer drivers and hence are installed with Ubuntu. So, if Debian finally realizes that it has to change something to support newer hardware that's more than welcome.

However, it's not really etch-and-a-half. It's not much more than a new kernel which I would compile regularly from kernel.org myself anyway. Admittedly, there are also two new xservers (for nv and intel), but that's still not very helpful for people with newer ati hardware, for instance. But I'm a developer and much more than any hardware hassle I'm much more bitten by really outdated development tools. I've written only one blog entry about the issue, but it's a topic that most developers could write books about -- or maybe not, most of them probably just compile newer versions as needed and are done with the issue. This looks like the easy way out but it doesn't really solve the issue: if you've got to deploy your software you'll need to ensure that what you need is there. But using newer versions of base libraries forces you to deploy them yourself, which also means that you got a problem whenever a security issue will be found in those libraries. On the contrary, with system libraries you don't need any manual deployment of libraries you're only using and you can hope to participate of all system updates. So, in my eyes that's clearly a big advantage for using system libraries. But with Debian (and etch-and-a-half doesn't change this) you're stuck with older libraries which a) might lack long wanted functionality and b) are incompatible with versions from other vendors, which is a pain if you need to deploy on different platforms. Now, granted that the latter problem is not only tied to the age of libraries, but it would be a lot smaller if Debians general release cycle wouldn't be that long. I know of software vendors who have thus decided to develop for Ubuntu but not for Debian, in order to minimize portability issues due to library/functionality mismatches between platforms. To me, that looks like quite high a price to pay.

James Hague blogs about how writing a spellchecker used to be a major feat of software engineering, the main point being that memory was a main problem that's no longer an issue today. While that is certainly true, the two issues (memory, spellchecking problem) are not as much related as James claims.

Without making it explicit, he makes the assumption that for spell checking to work you have to use a dictionary consisting of entire (correctly spelled) words. That would have been a very unwise way to go in the 80ties and it still is nowadays. /usr/share/dict contains roughly 240.000 words and you find that impressive? I don't. The real number of words of a language is much larger, which is easier to see in languages like German where you can easily build compound words. Hence, linguists typically try to capture as much information as they can in word building rules.

This will leave you with three things: a dictionary of words which are not built according to the generally applicable rules (for instance necessary for foreign words prominent in your language of choice), and a set of stems, basic building blocks of words. Quite to the contrary of James' claim that 3-5 lines of Perl are everything you need, the thing to keep in mind here is that this is the only way to solve the "spellchecking problem": any full-form approach to spellchecking is doomed to fail because a language's vocabulary does not consist of a closed set of words. How else could publishers of dictionaries go on selling new versions of their dictionaries every year? Another point is that in some languages (e.g. German) some aspects of spelling might be dependent on context (grammatical and semantical context). I.e. in order to be able to decide whether it's correct to write "Fahren" you need to have a basic understanding of the grammatical composition of the sentence it appears in: it might be a noun derived from "fahren" (to drive) or it might be situated at the beginning of a sentence (and sentence boundary detection is not always trivial either). Now, if your spellchecker just checks a dumb list of words it can't decide whether "Fahren" is correct or wrong.

With regard to the implementation issue, using a non-full form approach also helps: The nice thing is that you don't have as much redundancy and you can spellcheck a lot of words you've never heard of just by following the rules. Unfortunately, the number of stems is still huge if you want to do achieve a good rate, so of course clever tricks to deal with the list of stems is still required. There are of course still different routes you might take to implement spellchecking: what ispell or aspell are doing, for example, is mostly using a full-form approach using only minor modifications to recognize some simple word production rules. This is not what you will find in state-of-the-art spell checkers.

Catbert and privacy

This started out as a reddit reply to Alex Iskold's article about semantic search engine technology. Alex suggests that the reason why we haven't seen the semantic web as overtaking as the search technology of today is because of two points: that they won't provide better search results today and that the current semantic search engines have UI problems. At the same time, he claims that (wrt. to the search results) "emantic search is going to be big and it is going to help us answer questions that we simply cannot answer today - complex, inferencing queries asked over the entire web as if it was a database." I think that the UI point is irrelevant, or perhaps only relevant at this point in time.

I agree with the search result point, but I'm much more sceptical about the future results to expect.

I've tried Compiz with Metacity again and switch it off after a day -- again. I'm not willing to do without working software suspend just for some graphical whizz. I've been using Metacity for, I think nearly two years now, on my work computers and have somehow accomodated to it's various glitches (for instance the unusable keyboard settings). On my trusty home workstation, however, I've stuck with WindowMaker, which I think I've been using roughly since 1997 (I can't remember the version number, but it was fairly low). Unfortunately, development seems to have stopped -- since quite some time there is no sign of activity on the webpage and the mailing list archive is dead.

Yesterday, out of a current frustration about Metacity, I installed a naked current version of WindowMaker on one of my machines, under Ubuntu 8.04 (don't try to make WindowMaker work under Gnome: While WindowMaker does "work" under Gnome, it is really crippled. For instance, the keyboard setting know nothing about WindowMaker but still override your keyboard settings via, say, WPrefs.). Nearly everything worked as expected, but there were two glitches: the menu didn't reflect the installed software. Having customized the thing under my Debian system, I knew that this was supposed to work with the update-menu script, but that was missing. Some web-searching revealed that for some reason or other Ubuntu no longer installs the menu(-xdg) package. The other glitch was a very old complaint: That WindowMaker doesn't ship with a virtual desktop switcher or pager. You don't need to tell me about the different philosophy of WindowMaker, I know all about it. However, I've been using Fvwm and OpenLook (OLVWM) too long.

I could use gnome-panel (which I've done before in the past), but of course that brings me those two panels that make sense for Metacity and besides it also means that I would still depend on gnome. I've did quite a bit of looking around to find out what all the cool Fluxbox, Openbox etc. users are using and finally found fbpanel (the trick was to search for "taskbar" instead of "pager"). So, finally thanks to netwm support (which I think is in WindowMaker since 0.90), the one missing bit from WindowMaker is finally there without Gnome. Oh my, I'm finding this out really late.

John Goerzen blogs about (how to start) cycling to work. As I'm now back in Freiburg, in which anybody not cycling will be treated as an anti-social enviromental sinner, I'm using my bike a lot more, including cycling to work, hence I'm interested. Basically, I'm fine with what John has put together, but I would like to share my own experiences.

First of all, I'm concerned with Johns reference to cycling helmets. It is not so that helmets are required for cycling. I believe that this misconception is a common reason why people in recent years have come to believe that somehow cycling is a dangerous activity in the first place, while statistics clearly say it's not (in comparison to other activities, obviously). For instance have a look at a collection of facts around the danger of cycling. There is also some doubt about the usefulness of cycling helmets, have a look at the results of the helmet law in Australia. Now, whether one decides to where a helmet or not is up to you, of course, but the main fact to keep in mind is that cycling is in no way particularly dangerous.

John also mentions that for safe travel a key point is visibility, to which I whole-heartedly agree. However, Johns's sentence starts with "Unless there are dedicated bicycle-only lanes or paths ..." which should be taken with a grain of salt. There are studies, which I unfortunately had more than once the chance to verify, that bycicle-only lanes add a risk of their own. First of all, more often than not, you will not be as visible as you should be, especially if the lane is behind parking cars . Next, any biker on such lanes should take good care of any interference with pedestrians and/or car traffic. Especially where such lanes cross exits of garages and houses or when cars are parked directly beside the lane, be extra careful. I generally don't like bike lanes because more often than not they're in a shape no car driver would accept, but that's not the real point: the point is that bike lanes lure you into feeling extra safe while adding in some little surprises of their own.

But there's also another point to be made wrt. visibilty: Being visible alone won't save you, i.e. you can't trust that others will always behave correctly just because you do. Instead it's a lot more important that you are aware what other traffic participants are doing instead of making them aware of what you're doing -- only the first option is an active one, the second is just passive.

Now that we've dealt with the safety issue, let's talk about the fun. How fast you're going is up to you. I find that I can't really go slow (well, at least I feel like I'm not slow and there are not too many people going faster). I like a light and fast turn, so I use a relatively low gear -- think Lance Armstrong, not Jan Ulrich. And I shift gears really often so that my pace stays more or less the same regardless whether it's going up or down. Of course, this is only possible if you have relatively many gears. Don't expect too much from yourself btw: it's okay that you feel exhausted after a seemingly small way at first. It's also okay when you don't use the bike every day right from the start -- actually it might make a lot of sense to take a break between your riding days, depending on your fitness and the amount of cycling you have to do.

Of course, going quite fast by bike means that I'm sweating -- bringing spare clothes helps. And another point: if the weather is hot (there is currently wind from Africa blowing all the way up to Germany which means it's unusually hot these days), go early in the morning when it's still relatively cool. I would also suggest taking rain clothes with you, regardless of what the weather report is saying. I use a bike bag in which I take my rain clothes, some repair stuff and an air pump. I never really unpack it, so that's simply not an issue.

Another point: try to find a nice way to ride. This might require trying several alternative routes, but if you're lucky you might find a route that is fun to go. This helps to keep the motivation up. I know what I'm talking about, since in my old job in Mannheim I didn't use my bike as much as I should have because there simply was no nice route for me to work -- I always felt a little hunted on the road. Now, in contrast here in Freiburg, I've found a route which goes besides the river Dreisam for about five kilometers which is just nice in the morning, which means that I'm far more motivated to go the 10km way here than the 3km in Mannheim.

Die ARD-Sendung ttt - Titel, Thesen, Temparemente vom 25.5.2008 war bemerkenswert: Es gab drei Beiträge (abrufbar via der neuen ARD-Mediathek), die sich mit der Manipulierbarkeit der Medien beschäftigen. Im ersten Fall ging es um die vermutlich inszenierten Bilder eines von Israelis erschossenen Palestinenserkindes, als zweites um den ersten Fernsehkoch im deutschen Fernsehen, der so gut wie nicht kochen konnte und dann gab es noch eine Diskussion mit einem Sozialwissenschaftler und Historiker zum Themenkomplex.

Besonders diese Diskussion hat es mir in zweierlei Hinsicht angetan: Sehr nett fand ich die explizite Auflösung der Studioillusion, sprich: man hat mal kurz gezeigt, dass die zwei Diskutierenden in einer Blue Box standen und der Professor auch noch eine Kiste zwecks Größenangleichung untergestellt bekam. Die "Diskussion" war dagegen eher fad: Zwar wurden einige alte manipulierte Aufnahmen gezeigt, aber die eigentlich interessanten Fragen wurden nicht diskutiert: Wie häufig findet Medienmanipulation statt? Und warum und durch wen findet sie statt? Wie glaubwürdig sind die heutigen Nachrichtensendungen und Zeitungsberichterstattungen, mal ganz abgesehen von im Web-generierten Nachrichten? D.h., die eigentliche Metaebene, auf der man diskutieren könnte, in wie weit unser Verständnis der Welt von Medienmeldungen geprägt ist, die selbst dann suggestiv sein können, wenn sie nicht bewusst manipuliert sind, wurde leider nicht erreicht.

Aber das zu erwarten wäre vielleicht auch zu viel des Guten. Zum einen war ttt schon immer das eher seichte Unterhaltungsprogramm der Kulturmagazine im Ersten. Man mag beklagen, dass die Kulturreport-Sendungen verschwunden sind, aber de facto hatte es da eh schon eine starke Annäherung der Inhalte gegeben. Anyway, im Vergleich zum Rest muss man für diese Reste von Inhalt im Fernsehprogramm ja dankbar sein. Und zum anderen würde die Diskussion solcher Fragestellungen möglicherweise zu viel unangenehme Folgen mit sich bringen: Schließlich hat das Fernsehen (das öffentlich-rechtliche im Speziellen) ein Interesse daran, weiterhin als glaubwürdige Nachrichtenquelle zu gelten. Von daher war es fast schon wieder erstaunlich, dass das Thema mit immerhin drei Beiträgen recht umfangreich aufgegriffen wurde.

Steve Yegge blogs about XEmacs needs to die and I would like to add my own little comment on the issue. First, perhaps some background: I'm a long-term XEmacs user, since about 1995, I think. I started hacking Elisp around 1996, implementing a major mode for the Otter theorem prover and various other stuff. Since 1997 or so, I had been somewhat active on the xemacs-beta mailing list, reporting build successes/failures, participating in discussions etc. and even writing an article on the then-new XEmacs port to Windows in the german iX magazine. So, perhaps, I'm a bit biased towards XEmacs. That I've been using XEmacs instead of Emacs had a lot to do with two factors: at my university, the local Emacs guru used XEmacs and provided a very complete configuration to start with. To start hacking Prolog source didn't require any configuration on my side at all. When I tried to re-establish that configuration on my own linux box, using Gnu Emacs was totally out of the question, which is basically the second reason: XEmacs came with a lot of batteries included, whereas Gnu Emacs only came with a directly dying low battery at best. And third, the XEmacs interface experience was a lot friendlier than with the naked Gnu Emacs.

Now, at the time I was actively following XEmacs development, XEmacs had a whole lot of man power behind it, with lively discussions and an exciting movement of adding new features. At the same time, RMS discussed switching Gnu Emacs to Guile (a scheme dialect), which me, as a Common Lisp user, scared me off even more. Around 2002 or so, my spare time for XEmacs dropped to zero, so I unsubscribed the development mailing list and was just a happy user. Until two seemingly unrelated things happened: first of all, Unicode was no longer to be ignored and it was obvious that the Mule (multiple languages for emacs or some such) for XEmacs wasn't up to the task, especially not on Windows. That was quite a problem for me back then with the then current stable XEmacs 21.4. Now, six years later, XEmacs 21.5 is still not there (aka released as the new stable version) and it's unicode support still sucks (not so much as it did, say, two years ago, but it still fails a lot of tests from Markus Kuhn unicode test suite). The second development was that the Emacs team, which I had only barely been aware of previously, somehow gained a enourmous momentum and catched up a lot of ground, where XEmacs had been the leader by far. In particular, as of Emacs 22, nobody in its sane mind could argue against the fact that the current Emacs handles Unicode etc. far better than XEmacs (this is especially true for XEmacs 21.4 on Windows, but even the current beta XEmacs 21.5-b28 on Unix isn't where it should be). This seems to be directly related to the fact that a lot of the key developers of the end of the last century no longer actively participate in XEmacs development. I think only few people from the XEmacs crowd would argue against the impression that XEmacs development has more or less cringed to a halt and the distribution of development power between Emacs and XEmacs development is nowadays reversed to the situation from the 90s.

That being said, I still stick with XEmacs. Last time I tried using Gnu Emacs (that's the Emacs 22 from Ubuntu Hardy), I still found that I'm far more accustomed with the XEmacs intrinsics on how to perform specific actions than with how it works in Emacs. And I never got around to clean up my mess of configuration files to properly support the various flavours plus adding the extension libraries that still don't ship with Emacs (Slime, for instance). Finally, with more and more users switching to Emacs, there has to be someone reporting problems,

Now, back to Steves blog post: I think he has some valid points in it, but for the most part I disagree. First of all, while I agree that Eclipse and similar IDEs are still not at the greatest enemy to Emacs (regardless of flavour). I'm currently again using Eclipse at work and it's a pain finding out how to properly associate an unknown file extension with some specific editor (mode). And it's a memory hog that results in unbelievable handling (on my dual core 2GB equipped desktop) that is even worse than my first XEmacs experience on my 486/33 with 8MB ram in 1995. Eight megs and constantly swapping? Hah! I can't believe that even today I have to hear that Emacsen would be too complicated, given that for any task/configurations I spend endless time searching/clicking through the gazillions of settings in Eclipse.

However, I also don't believe that a marriage between Emacs and some web-browser is the way to go. There are much more pressing issues to move Emacs into the next century than switching from Elisp to <whatever>. If you're interested in extending your editor, you have to learn about the way how to do that. But that is totally independent from the question which editor you're going to use in the first place.
What is a much more pressing need in my opinion is finally implementing multi-tasking for the (X)Emacs core. Still being locked in a single-threaded application model is sooo 1990s. It's not becoming more and more ridicuosly, it's utterly unbelievable.

In one other point, though, Steve is right on track: the divergence between APIs is becoming a bigger problem with every passing day. I think it's very unfortunate that a) Emacs developers don't let them inspire by the existing APIs in XEmacs and vice versa and b) that there are too few XEmacs developers that merge current Emacs enhancement into the XEmacs codebase (the other way 'round is always problematic due to license issues).

So, before I would consider pursuing a major architectural change like XUL or some such for Emacs, I would first work on the much lower-hanging fruit of narrowing the gap between the two flavours. It's a pity I myself only have the spare time to write such blog posts instead of actively working on code towards that goal.

In case you're interested in continuation-based web development with Common Lisp, it might be of interest to learn that Drew Campsie has voluntered to take over UCW development. Marco Baringer, initiator and maintainer of UncommonWeb (aka UCW) seemed somwhat relieved that finally somebody with more time on his hand steps up to take over.

That Marco hadn't had the time to keep pushing UCW is quite obvious from the mailing list archive. Lately Attila Lendvai seemed to me (an innocent external observer) to had pushed UCW foreward, however, as he Attila announced, he wants to go into a different direction than Drew.

I've been using ucw-dev during the last two years and the current situation really called for a change, in my opinion. UCWs main problem, as I observe it, is lacking documentation and clearly stated goals which way UCW will go. The automatically extracted documentation doesn't contain information how the bits fit together and all tutorials are a) incomplete, b) outdated as far as they are targetting ucw-dev, whereas development has mainly happened in ucw-ajax. However, it was not all clear that ucw-ajax really would become the main line of UCW.

I like UCWs component architecture a lot and will eagerly follow what is going to happen. With two prominent developers such as Marco and Attila more or less leaving the project, it will be interesting to see with how much activity development will happen from now on.

Dell is selling Ubuntu equipped systems since about a year now and seems to be quite happy with it. Whatever that effectively means, at least I can tell that I'm quite happy with Linux on Dell systems, too.

Through the last five years, I've been using Linux on a number of Dell systems. Under my personal control there have been three laptops (Dell C610, D610 and a Latitude 640) and a desktop (Optiplex 755), on which I have been running Debian Sarge, Ubuntu Dapper, Feisty and now Hardy. We also had several Dell servers at work running more or less smoothly with Debian (sarge, etch). Using Linux wasn't always without problems: I had trouble with built-in modems, PCMCIA ISDN cards and acpi/hibernation. For example, on my private Latitude 640, I have trouble suspending at all, because of the ipw3945 driver for the wlan. But the important thing to note is that basically all problems were really small and never of a size requiring me to use some other OS in the first place.

The only real issue is not with Dell per se, but more with my favourite OS, Debian: over the years, and especially with the ever-lasting sarge release, getting Debian to run on a recent system got more and more difficult. That's the main reason why I've been using Ubuntu on all recent hardware I had contact with: it's more or less (more so than less) a Debian system but does run on modern hardware. Main issues here were graphics adapters, sata/scsi hostadapters and network/wifi cards, or to put it otherwise: too old kernels, too old X.org. Both problem sources can simply be solved by using a recent version of Ubuntu. Sorry, Debian, but your release cycle is just too long to be acceptable. Granted, all these problems are mostly an issue when installing a new system, but it's not always possible to plug in some old disc with a working version of Linux.