Bela Lugosi's Dead, Jim

Things that annoy me about Perforce

Thu, 09 Jul 2009 18:24:30 GMT

Missing Features

Things that just aren't there, that shouldn't (in principle) be hard to add.

p4 resolve won't show the difference between theirs and merged. A motivating example is where you merge from a release branch (theirs) that has changed more, and more recently, than the merge target (yours). In this case I'm more familiar with the branch changes and so would like to see what else I'm getting (i.e. from the branch I'm merging into) in the eventual submit. (Perforce have an enhancement request open for this one.)
There is no command to report the current status of your working tree (like cvs -n up, bzr status etc). When writing VCS I had to write my own. p4 opened is part way there in that it will tell you what have open, but the output format is rather verbose; it lacks the equivalent of .cvsignore; and it doesn't tell you if any files need resolving.
p4 diff (etc.) won't do the equivalent of diff -N (even if you set P4DIFF!). This makes the patches they generate incomplete if there are any added, branched or removed files, which is inconvenient for review and means that they're not suitable for use with the patch program.

Interface Inconveniences

Nuisances in the user interface. Again, I don't think these would be especially difficult to change.

Perforce forms (e.g. for p4 submit) treat visually identical whitespace as distinct. So if you've configured your editor not to insert raw tab characters (because your coding standard says you shouldn't use them, for instance, which is quite sensible given the trouble they cause) then your change description will appear to be correctly formatted when you submit it but be wrongly indented when you look at it in p4 changes or whatever.
p4 submit can only take one filename pattern. i.e. “p4 submit one.c” is OK but “p4 submit one.c two.c” is not; you have to manually add files to a change in separate steps before submitting it, or construct a change listing all the desired files manually.
If a change cannot be submitted you have to modify it and resubmit it; you can't delete it and start again, which otherwise might well be more convenient. The restriction seems to be an entirely bureaucratic one, too: you can remove all the files from it and then delete it. (For non-p4 users, the “change” here means the description and metadata, which in p4 have an independent life of their own; not your edits.)
Output tends to hide important information among unimportant. For example if a p4 sync updates 100 files and only one of them requires resolving, you're likely to miss it. Summarizing the files that need resolving at the end of the list of updates files would improve matters.

Model Problems

Flaws that result from some aspect of the system's design. These might well be difficult to change. (Which doesn't make them invalid; if the underlying design of a system doesn't support useful features, then perhaps that design is itself wrong.)

There's no whole-module graphical branch history view (like gitk or bzr visualise). p4v will show you a per-file branch diagram but nothing better than that.
p4 describe and p4 diff2 don't honor P4DIFF (because they do the diffing on the server), so if you have a better diff tool than p4's built-in one (which I do) then you don't get the benefit of it.
Execute bits are not properly versioned. You can't just edit a file and chmod it, you have to use a special command to change the execute bit. That's just inconvenient, but worse is that integration (merging) doesn't copy the change, so you have to change it on every branch separately.
If the server is running slow or is down, all operations that are in any way related to version control are affected. Since there is no client-side state or caching other than file contents, this includes non-mutating operations (diff, history, etc; even testing whether a file is in version control).

(Yes, some of these problems exist to some extent in some other version control systems too. That doesn't mean they're not annoying...)

Things that aren't annoying

The need to p4 edit isn't a big problem in practice (even though it sounds like a nuisance if you're not used to it), given adequate editor integration.
It doesn't crash. As a rule the problems seem to be design flaws (such as those above) rather than implementation bugs.
It's usually fast.

The Green Man

Mon, 22 Jun 2009 19:52:27 GMT

View Poll: #1419599

Weird Bash time behavior

Mon, 22 Jun 2009 12:34:57 GMT

richard@araminta:~$ cat busy.c
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char **argv) {
  struct timeval now, end;
  sleep(atoi(argv[1]));
  gettimeofday(&now, NULL);
  end = now;
  end.tv_sec += atoi(argv[2]);
  while(now.tv_sec < end.tv_sec || now.tv_usec < end.tv_usec)
    gettimeofday(&now, NULL);
  return 0;
}

This programs sleeps for a number of seconds and then busy-waits for a number of seconds.

richard@araminta:~$ time ./busy 0 1 | time ./busy 1 2 | time ./busy 4 3
0.63user 1.36system 0:03.00elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+133minor)pagefaults 0swaps
1.00user 1.99system 0:07.00elapsed 42%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+133minor)pagefaults 0swaps

real    0m7.016s
user    0m1.932s
sys     0m4.088s

Superficially it would seem that:

busy 0 1 slept 1s and busy-waited 2s
busy 1 2 slept 4s and busy-waited 3s
busy 4 3 slept 2s and busy-waited 6s

Of course this isn't the case at all, and the different output formats are a hint as to what's really going on. Bash interpreted the first time as applying to the whole pipeline (which does indeed survive for 7s and consume 6s of CPU) while the second and third only apply to the individual commands. The whole-pipeline output of course has to appear last since the computer can't predict the future.

In other words, the actual grammar honored by the shell differs sharply from the natural reading of the command. Bash's interpretation is both documented (in man bash) and allowed by a weird exception in the specification, but if you were naively expecting time to behave like every single other command, you'll be quite surprised (if you notice at all). If you don't notice then you'll misled into thinking that the wrong element of your pipeline needs optimizing.

Allowing time at the start of (some or all) compound commands would have been less surprising and more useful, and still allowed timing whole pipelines (when bracketed).

More Python character encoding braindamage

Thu, 18 Jun 2009 13:22:43 GMT

rjk@rackheath:~$ python -c 'print "møøse"'
møøse
rjk@rackheath:~$ python -c 'print u"møøse"'
mÃ¸Ã¸se
rjk@rackheath:~$ locale
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=
rjk@rackheath:~$ python -V
Python 2.5.2

(...but it's the same in 2.6.x.)

I think it's interpreting each byte in the (actually UTF-8¹) input string as a Unicode code point in its own right, though another (philosophically different but pragmatically essentially identical) possibility is that it thinks all input strings are encoded using ISO-8859-1.

¹ and don't give me the nonsense someone came up with last time about Python having no way to know how the input is encoded. It does have a way, that's what LC_CTYPE is for.

Sat, 13 Jun 2009 13:45:36 GMT

Rubik's Cube Menger Sponge and Crossword For Multidimensional Aliens

Stupid Apple

Tue, 09 Jun 2009 18:18:06 GMT

chymax$ ls -lL /usr/X11/lib/libXdamage.*
-rwxr-xr-x 1 root wheel 88496 2009-03-13 00:38 /usr/X11/lib/libXdamage.1.1.0.dylib
-rwxr-xr-x 1 root wheel 88496 2009-03-13 00:38 /usr/X11/lib/libXdamage.1.dylib
-rwxr-xr-x 1 root wheel 88496 2009-03-13 00:38 /usr/X11/lib/libXdamage.dylib
-rwxr-xr-x 1 root wheel   936 2007-09-24 05:39 /usr/X11/lib/libXdamage.la
chymax$ grep ^library_names /usr/X11/lib/libXdamage.la
library_names='libXdamage.1.dylib libXdamage.dylib libXdamage.1.0.0.dylib'

Complete the song trilogy

Sat, 30 May 2009 22:07:01 GMT

New Order/True Faith
Nik Kershaw/I Won't Let The Sun Go Down On Me
???

Safari 4

Sat, 23 May 2009 20:07:05 GMT

I downloaded the Safari 4 beta.

The obvious visual change is that tabs now replace the title bar. AFAIK this feature first appeared in Google Chrome. It seems a sensible use of vertical space.

I have a complaint about Apple's implementation of the idea though: when you have more than a few tabs (depending on the width of the window), the first thing to disappear is the close button towards the left. Fair enough, but when you hover over the tab (for instance to select it) the close button reappears. Since until you're there there's no visual indication you need to avoid that part of the title, the result is lots of accidentally closed tabs. Worse, there appears to be no undo close tab option.

In fact the closed tab will be the first thing you see in the history page, so it's not that hard to retrieve it. But you lose any state that you had in that page (unlike Firefox's undo close tab option, which does preserve at least some of the state).

The top sites page makes is effectively an adaptive bookmarks page, showing thumbs of the dozen sites Safari thinks you visit most often. It's initially populated with the NYT, Amazon, Apple, Wikipedia, CNET and various others. Wikipedia presumably got there for free but I did wonder if the others had to pay and if so how much. As you can see from the linked screenshot it's already accumulated a few of the pages I've visited recently.

The history page uses Coverflow (something that's turning up increasingly often in Apple software). Seems quite convenient and allowing visual recognition of pages is nice.

As in earlier Safaris, text entry boxes (such as Livejournal's update form) are resizable, a nice touch that I wish Firefox would pick up.

The advertised "full page zoom" buttons don't exist, though there are menu and keyboard versions. Zooming in randomly jumps around the page, making it very inconvenient to actually use the feature.

Hovering over a link still doesn't reveal what the destination is, unlike Firefox. It seems like a little thing but actually once you're used to it, not knowing for sure where you're going next makes browsing feel surprisingly uncomfortable.

It actually uses more memory than Firefox (RSIZE is the amount of real RAM used, VSIZE counts swap as well and is generally less interesting). It does seem to use less CPU when idle (where "idle" for a web browser means "running various bits of Javascript"), which would lend a bit of plausibility to Apple's performance claims if it weren't for the fact that visiting a page on Apple's own website took around 30s to load (and then proceeded to lag way behind user input, and SPOD some of the time, when scrolling) where Firefox managed to produce it just like that.

(I think it must be something about that page, since other pages don't produce the same problem. But you'd think they'd test it against its own website!)

Fair-weather friends?

Sat, 23 May 2009 15:09:54 GMT

(i.e. lots of accounts friended me and then evaporated).

Emacs for Macs

Sat, 23 May 2009 14:56:40 GMT

Mac support for Emacs (or possibly the other way round) has been a bit of an issue for a while.

The shipped /usr/bin/emacs only runs in a terminal, lacking any kind of GUI support, which is OK for quick edits but rather inferior for extended work.

Compile your own Emacs with X11 support (or use someone else's, e.g. Fink) and that works, but then you're at the mercy of Apple's deranged X11, which gets on badly with Spaces and has very poor cut and paste integration with native applications.

For a while there's been Aquamacs, which bills itself as a Mac-friendly version of Emacs, but I never really got on all that well with it.

A particular problem is that if you type anything while a selection exists, the selection is replaced with what you type. This is Macish enough but if you created the selection using the keyboard rather than the mouse then you can't make the selection go away with the keyboard - you have to use the mouse. The result ends up being a lot of undoing, even after months of use.

It also doesn't tell you what size your window is when resizing and creates new windows (frames, in Emacs's own terminology) with a size matching the last one. So getting a window of a particular size can be rather fiddly.)

Recently fanf mentioned the NextSTEP port of Emacs (or OpenSTEP, if you prefer) which has now been merged into the trunk of Emacs. NextSTEP's direct descendant is of course OS X, so this is a Mac-native Emacs.

The source can be retrieved via CVS. It built an Emacs.app without any trouble. It act much more like my muscle-memory expects Emacs should (no more destructive and un-dismissable selections), but also has concessions to the local OS - for instance it supports native cut and paste using ⌘C, ⌘X, ⌘V etc. Window size behavior is more sane and usable too.

Complaints so far:

Trying to save a buffer that doesn't already have a filename offers by default to save it somewhere in the guts of Emacs.app, which isn't very useful.
Mac-native means of entering “special” characters don't seem to be available. C-X 8 RET works fine, with tab completion over Unicode character names, but making ⌥⌘T behave as normal would be nice.

These are pretty minor; overall it's a clear improvement over what came before. Perhaps Apple can be persuaded to included it in future releases (with a link from /usr/bin/emacs into the depths of the application bundle)?

Stupid Microsoft

Sat, 23 May 2009 12:37:40 GMT

Further to the instructions here, I'd add that you will need to randomly re-install the new layout from time to time, as Windows randomly breaks or removes it without even telling you.

Meow

Tue, 19 May 2009 22:13:07 GMT

Fitzroy St, lunchtime.

Malign hypercognition disorder

Tue, 19 May 2009 22:09:58 GMT

View Poll: #1402533

You have to choose one of good and evil; black and white comic-book morality here.

Does my indentation level look big in this?

Mon, 11 May 2009 15:11:40 GMT

View Poll: #1398064

Don't lose your head

Mon, 11 May 2009 12:57:49 GMT

View Poll: #1398014

Yes, they really were that color

Sun, 10 May 2009 17:46:11 GMT

/usr/sbin/sendmail

Thu, 07 May 2009 15:50:29 GMT

View Poll: #1396328

Money can't buy you happiness

Thu, 07 May 2009 13:10:13 GMT

You're cycling¹ along and you spot a coin or note on the ground. Presumably whether you stop to pick it up depends on its value, so how much does it have to be before it's worth stopping, dismounting, picking up, remounting, and picking your speed back up?

View Poll: #1396261

¹ If you don't cycle, assume some other means of transport that's comparably inconvenient to interrupt.

Welcome to the machine

Mon, 04 May 2009 21:35:44 GMT

...yes, I'm attempting to make a dent in my photo backlog. I spent very little time taking pictures for the first part of the year, a bit of a shame having bought a new camera towards the end of 2008, but got going properly in April without simultaneously getting back into the habit of doing anything with the output.

Hemmed in

Mon, 04 May 2009 21:29:02 GMT

Suburban decay?

Mon, 04 May 2009 21:24:52 GMT

So much for the Great Schism

Sat, 02 May 2009 16:47:08 GMT

Pope not giving you the answer you want? Try another one.

The Pope had still not granted a dispensation for the marriage of Prince Edward and Anne Neville; Louis's patience had lone since been exhausted, and in desperation he had sent the Grand Vicar of Bayeux to procure one from the Eastern Orthodox Patriarch of Jerusalem. This arrived in December, at which time the King moved to Amboise where the wedding would take place.

(from Alison Weir's book on the Wars of the Roses.)

en_LOLCAT

Fri, 01 May 2009 20:30:34 GMT

21:03 <ewx> .oO{en_LOLCAT}
21:06 <crazyscot> ENOENT -> INVISIBLE FILE
21:07 <crazyscot> ENOSPC -> DO NOT WANT
21:07 <ewx> ENOMEM -> they be stealing mah bucket
21:09 <crazyscot> EINTR -> Im in ur systemz interruptin ur callz?
21:11 <ewx> EFAULT -> O RLY?
21:16 <col> ECHILD -> I MADE YOU A PROCESS, BUT I ATED IT
21:19 <col> EIO -> O HAI, I BROKED YOUR DISK
21:21 <crazyscot> EEXIST -> ALREADY HAZ CHEEZBURGER

…any more?

lj2news

Fri, 01 May 2009 20:23:43 GMT

lj2news users may be interested to know it appears to work fine with Dreamwidth. (Or possibly vice versa.)

rjk-nntp-tools (0.10) unstable; urgency=low

  * Separate Keywords: with commas rather than spaces.
  * Documentation updates.

 -- Richard Kettlewell <rjk@greenend.org.uk>  Fri, 01 May 2009 20:30:02 +0100

Two questions

Tue, 28 Apr 2009 10:47:50 GMT

1) What is the best thing since sliced bread (which apparently dates back to 1928)?

2) What was the best thing before sliced bread?