Useful iso 8601 tool

When trying to convert people to start using ISO 8601 a very useful tool in the ISO 8601 implementation page that lists code for a myriad of languages.

sync ; sync ; sync

I managed to get a picture of me in the blogger.com profile, so if you want to scare small children you know where to look :-).

I should decide to what conference I try to go this summer. There is debconf 5 in Helsinki (note the title "See you in hel") which is July 10 to 17. Or I could go to LSM 2005 which is in Dijon (much closer) and from July 5 to 9 and is in general a hotbed of Common Lisp activity. I'll wait a little more until the programms pan out, but after the Danish disaster of last year I doubt I can convice my wife to go to Helsinki. She wants Calabria :-).

I made almost no progress with the lazy memory allocation in sbcl. I think I know where the problem is, but I don't have enough time to check it out :-(. Also I wonder why nobody seems to care about this problem. What do you do on a 64 bit machine, do you start by allocating 2**41 bytes? Does the OS permit this? What does root think of this? Or do you want to have to select at startup how large your image might become? If not, you need lazy allocation.

Found the USB problem

I've been having USB problems with my own kernels recently. Now I found why. If you cannot use your USB memory stick, in my case my Iomega stick with 2.6.* and you get the message "uba: device 9 capacity nsec 0 bsize 512". It could be because you enabled BLK_DEV_UB. If you do the ub driver kicks in and it seems to dislike memory sticks with avengence. The debian images have this disabled already.

Now I only need to find out why my configuration causes the transfer to the PL3507-based 1394 bridge doesn't work my my kernel and does with the debian image. Sigh.

Heisenbugs

Lazy sbcl has one heck of a heisenbug. It compiles itself,passes the test but fails in the compilation of a new version. When you strace it the error (file not found) becomes a sig11. When you ltrace it the place moves, also when you gdb the lisp. :-( But I can trigger the bug now by hitting calculating 100000! in the stupid way. It hits the stack guard in the normal version. In the lazy version it hits the guard, starts an error and then gets a sig11 !
This will some time to resolve, time I don't have :-(.

links

People asked for links about my previous post.

• Not being able to boot a debian installer on a "difficult" platform that requires loading a firmware to boot or to install: "If it made any sense at all for a mainboard's BIOS to loaded by the Linux kernel at boot time with a non-free firmware blob, the current consensus (on debian-legal anyway) seems to be that Debian would not support it"
• Thinking that we can "force open" the firmware: "They can open their specifications or we'll fucking implement around them and eventually drive them out of the market."
• PROM good, firmware on CD bad: here
• Extending the GPL to hardware: "..taint his filesystem.."
• A loading non-libre firmware makes the loader non-libre: "...counts as a dependency..."
• Signs that two "groups" are forming: "You are the only person I've seen express views similar to mine on debian-legal."
• It is acceptable to refuse to run on hardware that uses non-DFSG firmware: "Users don't have to install firmware/bios/whatever before linux runs in the normal case. That is the difference."
• The non-existing loading firmware step in debian installer and again refusing to run on difficult platforms: here

Please note these links are just part of a discussion, but the general trend seems set and until there is an "official" policy on this that is all there is to go on.


Finally debian installer was getting hardware aware enough to "just work", with pride I could point people to the test releases and hear they would see all the hardware. What are we going to say to people come next release?
"You cannot install if you have an USB ADSL modem because we don't have the source."
"I don't need the source, I just need to load the firmware"
"Without the source the system is not pure, we don't support non-pure systems"
"But that is the only system they sell here"
"We are the guardians of pureness, nothing can exist that is not pure"
"Your DNA is not readable by me, it is not a preferred form for modification"
"Oh, I'll just pop out and kill myself"


This seems to have become a rather long post. Sorry for that.

Debian is turning into LispOS!

From "we should only use DFSG software" we went to "we should only ship bytes that are DFSG compliant" and now the fanatics went as far as to suggest that only "free" hardware should be really supported and that telling users to load non-existing firmware from unavailable sources during a non-existing step in the debian installer process is acceptable. :-(
Soon we will see post claiming it is "easy" to create a completely new architecture with FPA's and that we should only use that. I have seen this all before in the "LispOS" groups that always seem to degrade into "we should design a scheme/lisp/foo system from the gate up!". The nutters then leave the group, never to be seen again. The bad thing is however that the sane people also left the group, to continue working on attainable goals. I hope Debian can resist so long...

lazy allocating sbcl

Compare:

$ ps -p 19100  -o pid,pmem,rss,size,sz,vsz,args

  PID %MEM   RSS    SZ    SZ    VSZ COMMAND

19100  0.9  9988  6772  8758  35032 ./src/runtime/sbcl --core output/sbcl.core --userinit /dev/null

with

$  ps -p 19114 -o pid,pmem,rss,size,sz,vsz,args

  PID %MEM   RSS    SZ    SZ    VSZ COMMAND

19114  0.9  9732 859548 221711 886844 sbcl --userinit /dev/null

I patched sbcl to allocate all memory only when it actually needs to use it, not at startup. The resident size is the same, but the virtual size is quite smaller. The patches are quite ugly, but the resulting sbcl seems to survive the test-suite without problems.
I do think there is a need to add thread awareness to the patches and if someone ports this back to cmucl I can close bug 282716.
Expect an email tonight :-).

//apparent success (reached end of run-tests.sh normally)

Joy!

(edited slighly. Oh it is "Van Eynde, Peter")