ubuntu too?

A user asked if the p.d.o repository would work with ubuntu. A quick check showed that it would not work (libc version conflict), but I guess this is just a false dependency and a quick rebuild should solve it. But I would rather not keep up with 2 build systems and 2 bts. So googling for 'debian developers faq to ubuntu' got me nothing.
I fear I will have to start listening to Queen and talk to the MOTU :-).

Repository for cl packages

To keep the momentum in the cl packages during the freeze I created a apt-getables repository. Add

deb http://people.debian.org/~pvaneynd/cl-packages ./

to /etc/apt/sources.list to get updates Common Lisp packages.

To slime or not to slime

I have mutilated the slime package of Sean Champ with the current CVS HEAD of slime, changed the version number to something without epoch and I'm actually pretty happy with it.

The moral problem now is to upload it, or not. There is a dire need for slime in debian and the package seems to work correctly. The problem is that the packager seems unresponsive to email already for quite a while and I don't want to hijack his package. Should I just bite the bullet and upload or wait a little more... Sigh.

European Common Lisp Meeting

Yesterday I went to the ECLM, which has out-grown Arthurs living room by a very wide margin indeed: 92 participants!
The talks were interesting and diverse. PrimeTrader looked like a real killer-app, but I must admit that I was confused when people starting laughing at the "simplified architecture" because I agree with the 'simple' part. My day-job must do more damage to my judgment then I feared.
The Slime and sbcl presentations both gave me a strong urge to package up some stuff, while the Linj (a non-DFSG free Lisp to Java and back converter) was impressive. Next time I'm forced to write Java I know what to do. For climacs I see a strong future not (only) as a general editor, but as a framework on which people can build LL editors. When the problem becomes too complex for a gui you need a LL, and if you need a LL, why not use an editor that 'knows' you LL and can make editing code a breeze?
The weak-references talk was good because it gave people clear instructions on how to solve most weak references related traps, while the presentation of the two CL vendors was impressively optimistic from the both of them. I've seen other feelings being transmitted.
Last and most importantly: I won a raffle and I could buy a signed copy of Practical Common Lisp and I must say the quote by Xach is correct: the book feels and reads really nice. Impressively nice in fact. I think it will convert people to CL just by the quality of the work itself! Oh, and it is also a nice CL book :-).
Several people insisted to buy me a drink for my debian work. I'm stunned...
My only regret is that we had to leave before I could chat with more people. The way back was a lot longer and slower then how we came, but still I managed to get home before 23:00.

Lazy allocating sbcl, part II

After working on this in my spare time for a long time, I have something that almost works. The lazy sbcl 0.8.20.5 patches will with the following customize-target-features.lisp: :sb-lazy-linkage-table-space, :sb-lazy-dynamic-space, :sb-lazy-read-only-space, :sb-lazy-static-space, :sb-linkage-table-space. They change the specific allocations for that space so the memory is only allocated when it is needed. The net effect is:

$ diff -u /proc/13546/status /proc/13598/status
--- /proc/13546/status  2005-03-18 07:14:16.085383120 +0100
+++ /proc/13598/status  2005-03-18 07:14:16.085383120 +0100
@@ -1,18 +1,18 @@
 Name:  sbcl
 State: T (stopped)
 SleepAVG:      88%
-Tgid:  13546
-Pid:   13546
+Tgid:  13598
+Pid:   13598
 PPid:  8211
 TracerPid:     0
 Uid:   1000    1000    1000    1000
 Gid:   1000    1000    1000    1000
 FDSize:        256
 Groups:        4 6 20 24 27 29 44 109 111 114 1000
-VmSize:          886848 kB
+VmSize:           33624 kB
 VmLck:        0 kB
-VmRSS:     9160 kB
-VmData:          860116 kB
+VmRSS:     8804 kB
+VmData:            6900 kB
 VmStk:        8 kB
 VmExe:      104 kB
 VmLib:     1416 kB
@@ -22,7 +22,7 @@
 ShdPnd:        0000000000000000
 SigBlk:        0000000000000000
 SigIgn:        0000000000000000
-SigCgt:        0000000b000034fe
+SigCgt:        0000000f000034fe
 CapInh:        0000000000000000
 CapPrm:        0000000000000000
 CapEff:        0000000000000000

There are 2 gotchas:

• The patch is at the wrong place (linux-os.c) because there is no abstraction layer for 'get memory' and 'handle memory fault'.
• There is voodoo going on with the dynamic space: if I just allocate one page on every fault the system gets strange errors like 'file is not there' when renaming. If I allocate 10 pages on every fault (like in the patch) it works. This seems to be that sometimes the system needs the memory without first touching it. With the cmucl lazy patches this was due to system calls pointing to unallocated memory, but this does not seems the case here. I should investigate this further.

The good news is that the system build itself a dozen times without problems, and passes all the tests I've thrown it.

So Alexander I would translate "Beutelratte" as "pack rat".

new sbcl package

I've uploaded a split sbcl package. There is now a sbcl-common package that contains the architecture-independent parts of sbcl. You can grab a copy at the new-sbcl directory on people.