Mathrick no PATANKO PRESS!

How very fucking cute. I just spent half an hour debugging connectivity problems on my neighbours computer — she could access the (HTTP) login page in our network, and all other types of traffic, but any HTTP connection to the outside would just die without any explanation. I went through the usual routine of gutting Norton’s Internet Shit, to no avail, then went to diagnose network connections, which wasn’t exactly helped by the fact it’d crash every time I got near the network properties capplet (yay Vista).

I went into the safe mode (with networking) boot, where I could access the network properties, but the network did fuck all. Finally, thanks to her telling me (up front) that she installed MSN yesterday to be able to talk with someone, coupled with a ridiculous (and obviously unlabelled, that’s be too easy) popup after one reboot, stating:

The Family Safety service has been disabled. Please ask the adminitstrator of this computer to enable it. Until it’s enabled, you will not be able to browse the internet. [The fuck!?]

I was able to track it down to this brilliant MS service. I have no fucking clue what it’s supposed to do, but I know what does — kills your internet without any way to turn it back on. Thankfully you can uninstall that piece of crap, which of course restored law and order. Well fucking done, MS, that’s exactly how your non-technical users are best served. Twatmonkeys.

… is whatever. A bit sad, but mostly glad to have it over finally.

PS. I apologise for my lack of reply on what exactly I dislike about git, I promise to do it when I have less taxes and friends moving out to take care of. In the unlikely event that you care, the RSS feed will tell you when I have posted a comment / post on that (I will see how much content can be squeezed out of this).

It’s things like this that make me wish there was a compulsory smack in the balls before people are allowed to use git.

I hate how it requires me to go through a 14-years training routine in Tibet before I can do something as simple as succesfully checkout and keep up to date something that’s 1) a mere dependency 2) I am building using automated tools, for fuck’s sake, and how its author, its users, and the goddamn tool itself can’t fucking NOT try to convert me to their vastly superior world view when I just want to move along and not care. I found my VCS already, so would you kindly leave me alone and go fap to your perfect tool somewhere else?

Download here.

I stayed up pretty damn late today (working on a piece of code which will get its own entry once it does a bit more of what I want it to do), and in the half-asleep state right before waking up, I considered the important problem of uniquely encoding Lisp macros as interpretive dance. I’m sure it has some important applications; I will keep you updated as more all-nighters allow me to develop the idea.

Dear IEEE 802.11,

you guys are total twatmonkeys; I wish upon you painful genital rash each time someone gets compromised because of the lame insecurity protocol you designed. Go engage in some four-way dongshake, maybe you won’t fuck that one up. Cunthuggers.

THIS IS A PUBLIC SERVICE ANNOUNCEMENT: Please don’t use MoinMoin. Using MoinMoin is actually worse than not having a wiki at all.

Tl;dr summary

It sucks so hard and will mislead your visitors in so many ways that you’re better off having a straight HTML dump with an email contact than trying to fight the hopeless failure of MoinMoin.

Detailed explanation

I’ve been using various sites using MoinMoin to keep their content for a long time. I’ve never particularly liked that wiki engine, and found it confusing on numerous occasions, but the recent re-stumbling upon a particularly egregious case of Moin going out of its way to make sure your visitors aren’t getting what you wanted to give them was the final straw: I realised that it’s the C++ of wikis — not only will it not solve your problems, it will cause new ones that will make you long for your original ones.

First off, a couple of comparatively minor offences: its UI sucks and is confusing all around. The famous combined login/register widget is a paragon of UI anti-design, its version diff widget sucks, its history view is unwieldy and doesn’t actually link to the first revision (!!), I’ve long had experiences with its search being less than helpful, and of course it uses CamelCaseWikiLinks, which all sane people agree are stupid and harmful ([[explicit wiki links]] being the only sane syntax, obviously).

Now, a far more serious sin: it comes with its DB prepopulated with filler content concerning MoinMoin itself. This alone should be enough to disqualify any wiki from being seriously considered, as it means that:

1. unless you take active steps to combat it, any actual content you have will be drowned by the completely irreleveant bullshit that makes your site look like a page about $wiki_engine (I’M LOOKING AT YOU, TRAC) instead of what you actually want to talk about
2. the wiki help and your actual content have to compete for space, and as you add yours, you have to remove the (useful, after all) links to information about how to add and edit more
3. odds are that the filler content is in the same namespace as your primary one, increasing the chances of accidental clashes between unrelated pages

Now, that doesn’t mean wikis shouldn’t come with docs, far from it. It just means they should be clearly marked as such, and available separately from any content. This way a wiki about guinea pig mating habits with no content added yet will look like an empty wiki, and not like a page about Trac (and if you think it’s not a problem, please consider that most experts on guinea pig mating habits will likely have no idea what Trac is and why it is here where they expected a place to share their knowledge about guinea pigs).

However, in case of MoinMoin, the above is not the worst it does. No, it takes the idea of filler content and does things with it that make Trac look like the well-behaved, helpful boy from the neighbourhood. But first, I need you to do the following:

• pick a non-English language you understand
• make sure it’s one of:
  • Danish (this one I’m using myself, as I’m learning it)
  • Russian
  • Japanese
  • Hebrew
  • Portugese
  • French
  • Spanish (different from others, but still confusing as hell)
• the following will specifically not work for our demonstration (you will learn why in a moment):
  • Chinese [zh], German (these are almost enough, complete but not self-contained)
  • Swedish, Norwegian Bokmål [nb] (not self-contained and significantly shorter)
  • Finnish, Korean, Dutch, Slovenian (redirect to English)
  • Italian, Polish, Greek, Norwegian [no], Nynorsk [nn], Arabic, Farsi, Czech, Slovak, Sangro, Lithuanian, Latvian, Estonian, Icelandic, Serbian, Hindi, Punjabi (absent)
• if you know none of the suitable languages, just pick one that looks the least strange to you
• make sure that the language you picked is your preferred browsing language

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
(no, seriously, do it, I’ll wait)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Okay, now we have you browsing in $language, go to http://codeville.org/doc/. You’ll notice that:

1) It talks about wiki and MoinMoin and a couple of other wiki engines
2) It’s completely in $language
3) It doesn’t give you a slightest hint that it’s NOT WHAT CODEVILLE AUTHORS INTENDED. Not a language selector, not a link, not even a URL in the addressbar. NOTHING.
4) There’s not even a way to find the original English front page. Site map, title index, word index etc. are all buried deep under layers upon layers of irrelevant pages about MoinMoin and twenty translated copies thereof (that is, after you wait 2 minutes for them to load).

The only way to see the actual intended content if you happen to be using one of the unlucky languages is to guess that it’s not really right, then guess the content will be probably in English, then guess that you can go there by manually entering the English root’s name in the URL bar, then guess the name of it, backtrack a couple of times on misses (like MainPage, StartPage) until you get to the correct one (ie. FrontPage), then vow solemnly never ever to use the goddamn thing again.

It also means that the entire site can, silently and untraceably, transform completely depending on a hidden, essentially random variable the site admins will likely never discover and know to fix. It is also enabled by default (I have previously discovered and reported the exact same problem on Revctrl wiki, it has since been fixed).

Bottom line: in order to have MoinMoin even remotely resembling something useful, you have to essentially unbreak it on two separate levels, one of which is hidden so deeply that it can go undetected for years. Straight HTML, email, IRC, paper printouts, clay tablets, smoke signals, ANYTHING is better because at least what you see is what you get, unlike with MoinMoin.

Note also that the above is based solely on the problems I’ve been able to notice and track down based on my experiences with MoinMoin as a user. I have no idea what else you have to unbreak as an admin and what other problems might be lurking in other places, but I’d be very surprised if it turned out to be otherwise flawless.

PS. If you have read the entire post, you’re welcome and encouraged to go back and try with different languages and report the results back to me, so I can expand the known working / non-working list. In order for a language to be suitable for the demo purposes, the translation has to exist, and be self-contained (which is defined as “doesn’t immediately suggest that something is amiss and doesn’t link directly to the English version”). It doesn’t mean that non-self-contained translations are not an issue, but I want to make sure the first impression gives the proper idea of the magnitude of the problem.

Things I did this easter: go to church, drink, THROW SNOWBALLS.

Life is good.

Just a quick drop: if you use paredit.el for editing in your Lisp buffers (as you should), and you happen to also use CUA-mode (which rocks, btw), you probably know that by default they don’t play together too well. Well, I’ve finally got fed up with that and wrote some glue to fix them up. Details and code can be had from this c.l.l post

Update: For some reason WP disabled comments when I first posted this. Fixed now.

There’s a thread on c.l.l going, in which people try to find a reason macros haven’t caught on for the past 30 years, despite their immense usefulness. One of the cited arguments was this statement by one of the men in charge of Java process:

The advantages of Java is that it easily serves as a lingua franca - everyone can read a Java program and understand what is going on. User defined macros destroy that property. Every installation or project can (and will) define its own set of macros, that make their programs unreadable for everyone else. Programming languages are cultural artifacts, and their success (i.e., widespread adoption) is critically dependent on cultural factors as well as technical ones.

My claim is that this is about as true as C++’s approach to performance, in which people copy things all the time, because that’s what manual memory management makes them do. Just consider the “design patterns” omnipresent in Java. What is a macro, if not a structured transformation of source, following certain pattern? Of course, I’m saying nothing new here, but I just stumbled upon a particularly good demonstration of why “macros decrease legibility of code” is utter nonsense. Consider this snippet:

(restart-bind
    ((retry
      (lambda () (throw 'retry nil))
       :report-function
       (lambda (stream)
         (write "Retry reading the record." :stream stream))))
  (catch 'ok
    (loop do
         (catch 'retry
           (throw 'ok
             (unless (read-record)
               (error "Record not available.")))))))

Just try analysing it, how fast can you find out what exactly it does? Aren’t braided catch/throws fun? Now consider the same snippet using a macro:

(with-retry (:report "Retry reading the record.")
  (unless (read-record)
    (error "Record not available.")))

Not only is the code 4x shorter and uses idiomatic naming conventions and code structure, the macro also comes with a docstring and parameters to let you easily influence the working. And most importantly, you only have to understand it once. Whereas in Java every time you encounter a similar-looking snippet, you have to analyse it to see if it’s actually the same thing, or subtly different.

So, to sum up with a checklist, the macroless code is:

• More verbose
• Really complex and confusing
• Hard to spot and identify reliably
• Not documented
• Must be re-invented each time you need it
• Does not ultimately prevent convoluted code from coming up. If your code needs retry functionality, then so it does, and no amount of “ours is a simple language for the masses” can change it. Though if you make it sufficiently painful, people will probably find ways to dillute the apparent complexity amongst modules, only compounding the problems, and/or pretend they don’t really need their program correct, because it’s such a massive PITA to do it.

Now, to be fair, this is not to say that macros can’t be hard — very often they are, because you generally use macros to solve problems that would be even harder without them. You don’t deny surgeons access to endoscopy because they might not be skillfull enough to handle it — instead you make sure they are or have to find another trade. There’s no reason to treat programmers differently.

Saying “macros make code unreadable” is like saying “race bets can only be done on manure-covered floor, or else you won’t know you’re dealing with horses”.

Admit it, your Web 2.0 experience hasn’t been full up till now, has it? But now, with Chattr here, you can fix that and talk like a real Web 2.0 weenie with no effort. Its full glory can be had here.

Executive summary: yes, it’s an XChat plugin, no, it has no use.

(with-christmas-gifts
  (visit family))
(setf *money* 0)
(print ";_;")

Working on a project with a rather deep directory hierarchy, I finally got tired of my prompt overflowing the line and wrapping around. So, here’s a handy bash function to put in your $PS1. It should be noted that I did not write it, I only wrapped it up in a function and added some aesthetic options, but all the hard work and bash hackery was done by BearPerson from #bash.

# Produces the same effect as \w in $PS1, but makes sure that the
# result length doesn't exceed $1 chars. If any dirs are omitted, they
# are replaced with [...]. Optional $2 turns on ANSI VT100 escape
# sequences to dim the [...] part. Optional $3 specifies the colour
# code to dim to (otherwise 02, "dim")
bound_pwd ()
{
    limit=${1:-40}
    ansi=$2
    colour=${3:-2}

    regex="~$|~?/.{1,$limit}$|/[^/]*$"
    pre=$([ $ansi ] && echo -n "\[\033[${colour}m\]")
    suf=$([ $ansi ] && echo -n "\[\033[0m\]")

    CANDIDATE="${PWD/$HOME/~}"
    [[ $CANDIDATE =~ $regex ]]
    [[ $BASH_REMATCH != $CANDIDATE ]] && CANDIDATE="$pre[...]$suf$BASH_REMATCH"

    echo $CANDIDATE
}

To use it, either put it in your .bashrc, or in a file that is sourced by .bashrc, then replace \w in your $PS1 with $(bound_pwd). Personally I use $(bound_pwd 25 1) to get at most 25 chars, with VT100 colour codes.

Obligatory screenshot:

Update: If you use VT100 colours, remember to surround the bound_pwd invocation with \[ \], otherwise non-printing characters will confuse bash and make it wrap lines incorrectly

Update 2: The above update was wrong. It’s actually more complex than that, and due to the fact that bash doesn’t exactly have coherent escaping semantics, I had to rework the function. If you use VT100 colours and have downloaded an earlier version of bound_pwd, you have to download it again, it has changed. Additionally, to have it really work, you have to add this function:

set_ps1 ()
{
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:'"$(bound_pwd 25 1)"'$ '
}

And in .bashrc, add this:

# Yes, it's silly that ; alone is not valid syntax
PROMPT_COMMAND="${PROMPT_COMMAND:-true};set_ps1"

Make sure it’s the last line to set PROMPT_COMMAND. Especially if you’re on Debian/Ubuntu, as their default .bashrc sets it conditionally.

Following up on my CGI-Lisp work, here’s a short recipe on how to route the entire Apache traffic to a CGI handler. This is not trivial because of a few problems that need solving:

1. mod_actions will fall into infinite loop if you try to associate a handler with <Location /> (as will mod_rewrite if you attempt to rewrite /.*)
2. mod_rewrite will not execute CGI scripts by default
3. mod_rewrite only serves physical paths under DocumentRoot (and it’s good practice not to have /cgi-bin/ under DocumentRoot)

These can be all solved, but require some searching and reading into the meaning of various options, so I’m posting a ready solution here:

<VirtualHost *:80>
    ...
    DocumentRoot /var/www/
    ...

    RewriteEngine On
    # PT means "passthrough" and will allow mod_rewritten URLs to be matched by
    # virtual locations, not just physical paths
    # T= specifies mime-type to ensure the CGI handler will be executed
    # sock.cgi is the handler we want to handle the entire traffic
    RewriteRule ^/(.*) /cgi-bin/sock.cgi/$1 [PT,T=application/x-httpd-cgi]

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory "/usr/lib/cgi-bin">
        AllowOverride None
        #Add whatever options you normally use for your /cgi-bin/
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>

As an added bonus, it seems that the REQUEST_URI sent is the URL before rewriting, so you don’t have to do anything special to filter out /cgi-bin/sock.cgi from it.

Following the best agile methodologies, with rapid turnaround, short deliverables, tight customer feedback loop and probably something else involving “leveraging” and “assets”, I’m we’re proud to announce CGI-Lisp 0.5, the latest incarnation of the market-leading, award-winning product in the mod_lisp-compatible CGI-to-Lisp bridges space.

I call it 0.5 because I think it pretty much complete, but not enough to insist there are no bugs to be fixed or additions to be made.

Highlight of changes:

• POST now considered working. I haven’t actually done anything to make it so, but I tested it and mapped enough variables to have it actually useful (and it turns out to be working out of the box otherwise).
• Much more complete mappings. It should have most of the variables anyone cares about now.
• Tested a bit more. And by tested I mean “played with several Hunchentoot applications and found them not breaking horribly”.

I’m happy to announce the first release of CGI-Lisp. It’s a small hack that allows you to trampoline webserver requests into a long-running Lisp process, just like mod_lisp (and using the same protocol), except that it runs as a CGI handler. So you can run it on shared hosting.

The code was stolen from Rob Warnock, who hacked it years ago. I in turn hacked it into speaking unmodified mod_lisp, which allows it to be used as a drop-in replacement:

It’s been extensively tested by running it on exactly one machine in exactly one scenario. That means it will quite possibly break for you. If you still ain’t scared, grab the tarball here.

Update: so yes, I realise you hate GLib and can’t install it on your server. Debugging it was sufficiently annoying, though, for me not to be willing to put up with the sorry excuse for string handling of plain C. And I don’t think it will be very useful without handling POST anyway. I will probably fix that later on, but I don’t have the time now.

Update 2: I rewrote it not to require GLib. It’s slightly slower than before, but not much, and it’s good enough for me. POST non-handling still needs fixing though. You can grab the updated version from the same place.

Ladies and gentlemen, the C++ FQA Lite!

If you hate C++, you’ll have a great time reading this brilliant and amusing rant that rings just so true. Occasionally you’ll weep when it rings a little bit too true, invoking painful memories.

If you love C++, it’s a big flaming rant, but written with technical competence that easily shadows everything else out there that’s been written on the subject. You can’t claim any knowledge of C++ without having read it. And chances are that it’ll make you not love that sin against all good and just before it’s too late. Just think about it, the author is still trapped inside the warped world of C++, dealing with errors that have defeated everyone else on his team. The FQA is really a desperate cry from inside the asylum for you to stop while you still can. Think about it, you’ll be endlessly happier if you do.

If you don’t care about C++… Well, lucky you. But if you know someone who likes C++ more than they should (that is to say, at all), consider doing them a favour and pointing them to the FQA. Friends don’t let friends use C++.

In case you don’t know it yet: Peter Seibel’s Practical Common Lisp is the best Common Lisp tutorial around. It’s also a great book on its own, and a recommended reading for anyone looking to pick up a new programming language (and Common Lisp is a recommended language for anyone, too :). Go read it.

My personal method of reading is, as it lack traditional textbook problem sections, to follow along with the problem specifications, but not with the code, and only compare the results once finished. This was the way for me to avoid lazily reading, but not actually comprehending, the code.

Also, if you choose to read the web version (there’s a dead tree edition to be picked up from Amazon, y’know), you will want to install the greasemonkey script for footnotes hyperlinkification. And be sure to read it to the end, including all the practicals. A fair body of the code from the book got packaged into separate libraries and is actually used by many projects, this way you will be gathering knowledge of some very useful and widely employed packages.

And one final tip for any would-be Common Lisper: CLHS is your friend. Learn to read it today.