Happy 2005#
Sun, 02 Jan 2005 23:17:26 +0000
Happy 2005. I could do the end-of-year roundup, but my lisp hacking
exploits this past year have been infrequent enough that the last
twelve months diary entries are short enough not to need summary. Or
I could do predictions for next year, but I tried that last year
with results which were on the whole undistinguished. So, well, let's
just qspeculate on what I'd like to do this year:
- Something with McCLIM, probably involving GPS tracks. That's
CLIM application programming, not McCLIM internals hacking, as far as I
can avoid it. (More on CLIM later; I had a useful conversation
with Andy Hefner yesterday, so we'll see if I can write up the
conclusions without misrepresenting him too badly)
- SBCL-wise, (i) replace fd-streams with something I can understand
and have some reasonable confidence in, (ii) whatever other
thread/runtime-related stuff imposes itself on me. If it sounds like
I'm winding down a bit on SBCL here, I must point out that (a)
realistically, I did that already, (b) it works pretty well these
days, and with all the other people hacking it doesn't really need my
further meddling. I reserve the right to change my mind on this if
Apple bring out a laptop that I like (small, thin, light, 1024x768 and
feel free to leave out the cd/dvd player to assist in these aims) and
can afford (cheap, and ideally also cheap), because then I'll need
threads on PPC.
- Finish my texinfo translator and hack up some useful texinfo
warp-to-symbol-documentation infrastructure stuff for
asdf/circle/slime/thingy.
- Follow the progress of Climacs with interest. Apart from anything
else, it's the most likely vehicle for using lisp at work that I'm
going to see for a while.
- Buy and/or make (how hard can it be? please don't mail me about
jwz's plumbing store special, I've already seen that) some bookshelves,
and reclaim some parts of the floor in here that I haven't seen for
most of a year now.
- Skate a marathon.
- Skate a marathon in a time I'm not ashamed of (although I haven't
decided what this time will be yet)
- Start cycling to work again.
- Spend more time with my guitar (another pursuit which suffered in
2004). Perhaps even learn to play it ...
loaclhost.telent.net (a.k.a cvs.telent.net) has a very ill hard disk#
Thu, 13 Jan 2005 22:52:26 +0000
loaclhost.telent.net (a.k.a cvs.telent.net) has a very ill hard disk
and is down until further notice. Right now I don't even have any
other device I can boot it from (or indeed, media to boot) so I'm
going to have to spend some time finding a cdrom drive and a suitable
Linux Alpha cdrom image to put in it before any further progress is
noted. Weekend project, i think.
No, I can't just put it in a PC. (1) I don't have one spare, (2)
the disk uses weirdo Alpha partition tables: the effort involved in
digging out a suitable machine and doing necessary kernel stuff to it
would be better spent on getting the alpha running again. Yes, it's
possible. No, "just" is not the right word.
I had certain problems at the weekend with computer suppliers: most#
Wed, 19 Jan 2005 00:26:26 +0000
I had certain problems at the weekend with computer suppliers: most
notably Simply, who told me on the telephone that thay had lots of
cdroms and disks in stock for collection from their London branch,
then in person when I got there (admitedly an hour or two later) that
they only had 160Gb drives only one kind of cdrom - not the cheap one.
So I mail-ordered instead. Nice new SATA drive arrived today;
expected tomorrow, a controller card to use with it. I've already
scanned the old disk - on finding that the partition table was
unreadable anyway I thought I might as well whack it in a PC and see
what I could get - and the good news is that the corruption was
entirely confined to the start of the disk (root partition and swap)
and didn't affect any of the interesting stuff (cvs repositories, home
directories, etc) - once I'd found the start of /export, it
restored cleanly onto the new disk. So, with any luck I should have
it all running again soon and back on the net next week. Fingers
crossed.
Not been writing much here lately (as, obviously, you can tell
easily): when I have been doing/thinking about Lisp-related stuff,
it's been about a replacement streams system for SBCL. But I barely
have anything written down yet, never mind implemented. Oh, and
the ALU Wiki is going to die
unless someone does something, but I've had no responses of any kind
to that message yet, so that shouldn't be a big deal.
Today's neat software: ddrhelp, and ddrescue, on which it depends.
Debian has defeated me once again#
Thu, 20 Jan 2005 23:57:37 +0000
Debian has defeated me once again. I have the ambition, one day, of
doing a fresh standard debian install that doesn't involve stopping
halfway through to monkey with modules or an unsupported PXE or
untarring the base system where it's not supposed to be and using a
chroot or ...
Today's alpha install has not satisfied that ambition. I can't
make the machine boot the unstable rc2 debian-installer netinst image
from CD, so I had to do a floppy install. It's 2005 and I just had
to buy a new box of floppies - how wrong is that? There isn't, as
far as I can see, any floppy images newer than woody for Debian Alpha,
so I ended up installing that and apt-get upgrading. It still hasn't
reached the point where I find out whether the SATA controller is
recognised, because it's still building the 2.6 kernel that I hope
will contain the relevant driver.
In the process of writing this entry, I just realised that I forgot
to apply the -ac patch to said kernel before building it. Bother.
loaclhost.telent.net (a.k.a cvs.telent.net) boots#
Sat, 22 Jan 2005 16:35:22 +0000
loaclhost.telent.net (a.k.a cvs.telent.net) boots! I spent entirely
too long farting around with the sata_via module before realising that
Jeff Garzik had already added support for the VT6421 back in November (and it still
hasn't been merged into the kernel, at least as of 2.6.10-ac10), but
now it seems to be pretty much all there. You can't get to it yet as
it's on the wrong side of my DSL, but as soon as it returns to the net
(next week, I hope) we should be resuming service. If you formerly
had an ssh login for it, you still have (I've copied home directories
across) and needn't resend anything, but please note that the host key
will have changed - the new fingerprint is
6a:2a:97:cf:d5:1b:da:74:14:d2:21:d8:d9:d3:48:b7.
There are probably a ton of packages that used to be on it that I
haven't yet reinstalled, but lots of those were only there due to the
machine's former career as a desktop box. If you find anything
missing, drop me a note.
Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: IBM Model: DDRS-34560W Rev: S97B
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: HDS722580VLSA80 Rev: V32O
Type: Direct-Access ANSI SCSI revision: 05:; sudo hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 38 MB in 3.03 seconds = 12.55 MB/sec
:; sudo hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 124 MB in 3.05 seconds = 40.70 MB/sec
sda is on the Adaptec 2940 that's still installed to boot from (SRM
doesn't recognise the SATA controller). Unbelievable though it may be
to anyone who's never used an Alpha SX164, anything attached to the
motherboard IDE interface was actually slower than that scsi
drive.
I'm hacking threads for SBCL AMD64#
Sun, 30 Jan 2005 00:19:50 +0000
I'm hacking threads for SBCL AMD64. I've only just started on it, but
there a couple of things I think I've decided on:
- The AMD64 sort of has segment registers insofar as %fs
and %gs still exist. However, glibc is using %fs
for its tls, and %gs is reportedly slower because the kernel
uses it for something. So, as we have some GPRs these days, let's use
one of them as base address for our thread data (specials &c)
- The original decision to use clone() instead of pthreads was
largely made on not on any objection to the pthreads interfaces, but
more on the basis that LinuxThreads (the then-current implementation
of same) is/was pretty bloody awful. We no longer have to care about
that, mercifully: NPTL is supposed to be actually quite good. So,
let's see if we can use standard(ish) interfaces where appropriate.
Of course, there's still a big gap between "uses some pthreads
interfaces" and "runs everywhere that pthreads does". Purists will
point out that the pthreadt may be a non-integral type
(e.g. a structure) and we shouldn't be comparing them with each other;
I will respond by pointing out that we're still using POSIX RT
signals, and (at least for the moment, until I can work out whether
the pthreads locks are adequate) futexes. Which probably ties it down
more effectively portability-wise than any weird architecture that
uses a struct for pthreadt.
So far after an evening's hacking it compiles host-1 and target-1,
then bails out very early in host-2 as I still haven't done any of
the lisp stuff: need VOPs for set, bind, unbind,
symbol-value etc.
Oh, before I forget: if you are running a highly loaded site on
Araneida with a mod_proxy in front of it,
ProxyIOBufferSize 131072
(where 131072 comfortably exceeds the size of your largest likely
response) seems to make a quite impressive difference to its
speed/stability.