Archive for January 2008
A pretty good Autotools tutorial (presentation/PDF) that already tells you more than you would like to know (which, alas, is probably less than you need to know).
Ars Technica describes it as
Autotools, an intractably arcane and grotesquely anachronistic cesspool of ineffable complexity that makes even seasoned programmers nauseous.
2008-04-01: Found these:
Stop the autoconf insanity! Why we need a new build system.
What is Wrong with Make?
Make alternatives: “SCons is my preferred tool in this category and also my preferred build tool overall.”
It was (is) a fundamentally misguided idea to make up a new limited language for use with make, then another one for automake, and another for autoconf. Who has heard of m4, really? And tools that add an extra script (and sometimes a language!) for creating the input to this vicious chain are even worse. One of the useful lessons from the Lisp people is that is really easier, and better, to use a real language than to make up and parse and understand a limited one.
The sooner everyone moves away from the make/automake/autoconf madness the better.
SCons is written in Python, uses real Python for its files, and might be the future. Or it might suck. It’s too early to tell; it has only been around for a decade or so.
Found some treasures I hadn’t known of — masterpieces from the National Film Board of Canada.
Read the rest of this entry »
A talk here by a Google Talk guy:
I didn’t pay close attention, but some things caught my notice.
Google Talk started as a standalone application and became embeddable in Gmail, Orkut, iGoogle (the personalised homepage), usable from cellphones, and so on. This is no mean feat, and shows that modularity and reusability are not unattainable ideals.
It also has important lessons in scalability. Questions like “how many IM messages do you deliver?” or “how many users do you have?” might be relevant from the perspective of the product’s success, but they are not the right measure from an engineering perspective. Most of the packets on the network are presence packets, and this is the number of users × the number of buddies they have, which does not grow linearly with the number of users (think integration into Orkut).
Before deploying into Orkut, they did real-life load testing with a “backend launch” — Orkut started fetching presence status from Google Talk several weeks before launch (starting slowly from 1% of Orkut page views), without showing anything in the UI. With enough confidence and some bugs fixed, the integration was finally made visible. They did something similar with Gmail.
Sharding and re-sharding: Different users are allocated to different servers, and this can be changed easily too.
Modularity etc: Different parts (like Orkut and Gmail) know very little about each other, and interact using the same interface that the rest of the world uses, so one can be changed easily without affecting the other.
Not afraid of going low-level (TCP, epoll kernel calls, etc!)
[The code you're looking for is at the end of the post :)]
Following up on my previous post on auto-save…
GNU Emacs is one of the oldest programs existing, and it has had an auto-save-mode for god knows how many decades now, but it doesn’t quite do what I want. Like this other user, I was annoyed that it saves to a different file (
/dir/filename is saved to
/dir/#filename# while the file is being edited), and still requires you to save the file when you quit Emacs or close the buffer, thus making it not auto-save at all, but merely a backup facility guarding against Emacs crashes.
Someone at Emacswiki’s AutoSave page suggested
M-x run-with-idle-timer RET SECONDS RET save-buffer RET, but I tried that for a while and it is really not a good idea; it tries to save every buffer, even those not associated with files, like completion buffers. I considered trying to figure out how to make it run on only buffers associated with files, but then I realised that it would probably be better to modify the built-in auto-save mechanism do what I want, instead of rolling my own new one, because that was smart about things like this.
C-h f auto-save-mode is actually quite sparse compared to the usual Emacs documentation. Anyway, I figured out with a bit of looking in the source files that I could edit
make-auto-save-file-name function to modify what filename it used for auto-saves. On a bit more thought, I realised that it is usually never necessary to edit Emacs functions; you can always use hooks (or, in rare cases, advice). So this works:
(add-hook 'auto-save-hook 'save-buffer). Yeah, it will still be saving the file in the #filename#, but it will be saving it to your file too. Actually I then realised I don’t need that either. Doing
M-x apropos-variable RET auto-save RET gives several variables including:
auto-save-file-name-transforms Variable: Transforms to apply to buffer file name before making auto-save file name. auto-save-timeout Variable: *Number of seconds idle time before auto-save. auto-save-visited-file-name Variable: Non-nil says auto-save a buffer in the file it is visiting, when practical.
auto-save-visited-file-name to t seemed to do what I want. Until I actually tried to use it, and discovered that whoever added that feature probably hasn’t actually used it at all — it asks a “File has changed on buffer, really edit it? (y/n/r/h)” each time it auto-saves and you try to continue editing. You could turn on auto-revert-mode to make that problem go away, but I’m unsure if that’s a good idea: sometimes I overwrite files by mistake (
gcc hello.c -o hello.c) and having Emacs not auto-revert is very helpful in those cases. So I’ll stick with my earlier idea, which works perfectly, after being fixed by Bryan Murdock:
(defun save-buffer-if-visiting-file (&optional args)
"Save the current buffer only if it is visiting a file"
(add-hook 'auto-save-hook 'save-buffer-if-visiting-file)
Bryan Murdock also posted it.
Good software does what you want. Preferably without your having to tell it to. And it matches your mental model of what you expect things to work like.
We have come a long way since the days personal computers were severely constrained in their resources, but some traditions have not changed. The humanized weblog looks at the save icon, but I want to point out that the “saving” “feature” is itself an anachronism. There is no analogue of the concept of “saving” a file in the real world; when you write on a sheet of paper the change is permanent. Why, then, does most software require you to explicitly “save” something if you want to leave it permanent? The answer, I guess, is that a long time ago, a “save” was an expensive action (I remember seeing “Saving…” progress bars), so you wanted users to be in control of when it happened, so as to not annoy them.
Today, personal computers have enough resources that in many applications (such as text editing), there is really no reason for software to insist that you remember to “save”, so as to not lose your work. Still, programs continue behaving this way, partly out of tradition, and partly because no one gives a thought to usability.
Fortunately, the rise of applications on the web brought with it an “everything old is new again” phenomenon and programmers began to take a fresh (and naive) look at everything, which, while often causing them to stupidly repeat the mistakes of desktop programs from decades ago and generally be inconsistent, has also allowed them to throw away meaningless traditions in situations where they don’t matter.
I believe it was Gmail which started this, and now Gmail, Blogger, WordPress, Google Docs, and any number of online text editing applications now “automatically save” your work for you every few seconds, and this idea is finally (slowly) taking hold in desktop applications as well.
Words from The Meaning of Liff:
AINDERBY QUERNHOW (n.)
One who continually bemoans the ‘loss’ of the word ‘gay’ to the English language, even though they had never used the word in any context at all until they started complaining that they couldn’t use it any more.
Also, this unnervingly accurate series of corrie-words:
The moment at which two people approaching from opposite ends of a long passageway, recognise each other and immediately pretend they haven’t. This is to avoid the ghastly embarrassment of having to continue recognising each other the whole length of the corridor.
To avert the horrors of corrievorrie (q.v.) corriecravie is usually employed. This is the cowardly but highly skilled process by which both protagonists continue to approach while keeping up the pretence that they haven’t noticed each other – by staring furiously at their feet, grimacing into a notebook, or studying the walls closely as if in a mood of deep irritation.
The crucial moment of false recognition in a long passageway encounter. Though both people are perfectly well aware that the other is approaching, they must eventually pretend sudden recognition. They now look up with a glassy smile, as if having spotted each other for the first time, (and are particularly delighted to have done so) shouting out ‘Haaaaaallllloooo!’ as if to say ‘Good grief!! You!! Here!! Of all people! Will I never. Coo. Stap me vitals, etc.’
The dreadful sinking sensation in a long passageway encounter when both protagonists immediately realise they have plumped for the corriedoo (q.v.) much too early as they are still a good thirty yards apart. They were embarrassed by the pretence of corriecravie (q.v.) and decided to make use of the corriedoo because they felt silly. This was a mistake as corrievorrie (q.v.) will make them seem far sillier.
Corridor etiquette demands that one a corriedoo (q.v.) has been declared, corrievorrie must be employed. Both protagonists must now embellish their approach with an embarrassing combination of waving, grinning, making idiot faces, doing pirate impressions, and waggling the head from side to side while holding the other person’s eyes as the smile drips off their face, until with great relief, they pass each other.
Word describing the kind of person who can make a complete mess of a simple job like walking down a corridor.
I hate Google Suggest. I started searching in Firefox’s search bar for “there’s more to life than potatoes”, but the “there’s something about …” queries caught my eye, so I started typing that instead, and seeing “there’s something about Harry” and expecting a parody, I ended up reading this piece of lit crit. It’s not too deeply immersed in nonsense, and it also doesn’t mention bash.org #111338.