common-lisp-controller v4

The new light clc just got uploaded to experimental. I think I will move it from sourceforge to alioth like a proper debian package.
Still to come: (aka vapourware) asdf-install-2-deb-package and clc-build-all-packages-for-me :-)

Brown bag time

Here I was trying to understand why the unison sync between sharrow and frost didn't work. For a full hour it kept telling me to remove lockfiles that didn't exist on either machine. Then the euro dropped: it helps if in /etc/hosts you fill in the correct ip for the other machine, and not your own...

New 19a-pre3 upload

I made a new 19a-pre3 upload of cmucl to experimental. When upstream marks the CVS tag 19a-release on the 28th I hope to upload the packages soon. I cannot seem to fit the whole 'original source' with the fact that the upstream version can change when important fixes are put into CVS. This means that the upstream version will be 19a-release-20040728 with debian version -0. Ugly, not?

In other news I've been working a lot with squeak recently, especially with squeakland. Their online demos of EToys are really wonderful, just look at
this car demo.

The whole AMD64 GR just sucks. GR should be an exception, not the rule! Communication seems to be breaking down. Discussions not unfortunately... All in all I wish there were a cabal :-). So I think I will vote against.

Common-Lisp-Controller needs to evolve

clc is having problems. The design is getting Byzantine and in general much to complex to solve even seemingly obvious problems. The current design with build-daemon, cronjobs, spool directory etc. has to die. But what should replace it?

Kevin Rosenberg has a interesting idea: do not build for all users of the system anymore, just has a per-user cache of compiled packages in ~/.clc//. When you upgrade an implementation or a library you just nuke the cache directory for all users. When a user requests a library the library gets recompiled on-the-fly and if there are problems the user is dropped into the debugger so there is some hope to get useful bugreports.

The major problems are that we would be deleting files in every user's homedirectory(!) and that we would not build all libraries on a routine basis, so bugs could go unnoticed for quite some time...

IBM R40: to pcmcia or not to pcmcia

I keep having problems with my IBM R40: the pcmcia interface just will not work. Very iritatingly I keep getting:

kernel: Yenta: CardBus bridge found at 0000:02:00.0 [1014:0528]

kernel: Yenta: Using INTVAL to route CSC interrupts to PCI

kernel: Yenta: Routing CardBus interrupts to PCI

kernel: Yenta TI: socket 0000:02:00.0, mfunc 0x01d11002, devctl 0x64

kernel: Yenta TI: socket 0000:02:00.0 probing PCI interrupt failed, trying to fix

kernel: Yenta TI: socket 0000:02:00.0 no PCI interrupts. Fish. Please report.

kernel: Yenta: ISA IRQ mask 0x0000, PCI irq 0

kernel: Socket status: ffffffff

On a kernel that should be able to handle it (2.6.7-mm3) Even without acpi, apic and other magic. The only good fact is that also when using XP it sometimes behaves strangely...

cmucl 19a preview uploaded to experimental

I uploaded a preview of 19a to experimental yesterday. (I could saw the katie email today)

It is called pre1 but is based on the official pre3 version. This confusion is due to the fact that I have to remove the CVS files from the source files. This makes quickly updating the source more difficult than it should be, and I wonder how katie handles ever-changing .orig.tar.gz files. Boh. We will see.