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")

Unix squeak image

The apt-get archive for squeak seems to have gone, and the image it used does not provide the joystick interface I want to use, so I decided to have a look at rebuilding squeak with the library.
Next time people complain it is difficult to build cmucl they should be pointed at trying to build squeak! There is a rapport of a build problem with autoconf/automake that seems to have been ignored for months. I've tried to work around it but it seems almost hopeless.
It must be because I'm not in the same grove as the squeak hackers but to me it seems a disorganized, chaotic project that I fail to penetrate. Just look at the wiki page for downloading squeak and notice the self-doubting nature of that page. A shame really.

So now I can claim a link to p*rn!

According to this lemondor entry the p*rn search engine Booble uses cmucl and PG to talk to postgreSQL. The meaning of cl-html-template even suggests it is a debian machine.

Well. At least it is not the Bush campaign :-).

People stealing code everywhere

It seems that Monsanto tried to steal a wheat variety from Indian farmers. Somehow I hope they get seriously fined for this, but I do not think the Indian farmers will get compensation for infringement on their IP.