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.

nugget of code

Suppose you have a feature debug that you use to turn on debugging, and that if debug is on *features* you want to araneida not to cache your responses for a day. Then you can use the following code:

(araneida:request-send-headers

   request

   :content-type "text/html"

   ;; cache this page for 24h

   #-debug #-debug

   :expires (+ (get-universal-time) (* 60 60 24)))

The #-debug #-debug will exclude both expressions that follow. Another neat trick I've learned from Erik Naggum.

presentation is online

I've put the Benelux lisp meeting talk online, together with source here.

common-lisp-controller problems

It seems some users tried to get help for clc via cliki. Too bad I didn't pay so much attention to that page lately.

So I published the clc package on alioth a bit more and created two mailing-lists for people to subscribe to. In 6 to 24 hours they should get created.

Most people complain of a lack of RPM's or the ease of adding local packages. The problem with the latter is that I don't have a rh system, nor do I wish to create one. And build farms don't seem to exist. The problem with the last issue is deeper. asdf-install doesn't define user specific system directories for any implementation that isn't sbcl. So to 'fix' clc we have to modify asdf-install or make the world more complex by dividing them in clc-enabled (with user packages) and non-clc-enabled (no user pacakges unless you run sbcl). Sigh.

Let's make it a point to chat about on sunday...

Actually users complaining means that I have users! Good >:-).

pg

Of course I notice a bug in pg's extended query support while writing the presentation about it. Sigh.

4GB is not enough?

I have a 4GB vmware-ed XP partition that I tried to upgrade to SP2 today. In vain. After downloading it for the 3rd time it told me instead of "installation failed because there is not enough space on your harddisk" the slightly better "you need an additional 493MB of free space to install XP". Sorry? There is nothing installed except the base of XP on this partition and it is too small to even containt that.

That and the problems I've been having today to get a minimal install of RHAS 2.1 makes me believe nobody is interested in the maxim "small is beautiful". Or as I think "less code are fewer bugs".

skynet pop3 servers don't like Linux anymore.

Since a week pop.skynet.be refuses to send me my email if /proc/sys/net/ipv4/tcp_window_scaling == 1. I opened a ticket for this, but the response was 'please visit www.google.be'. Yeah. Now I've heard from anyother geek who was wondering why he didn't get anymore email via his official mailbox.

So in the end I decided to dump those losers and got me a fastmail.fm account. They have https/imaps/smtps access, even through proxies on port 443, sieves, spamassassin etc. It is so much better then the skynet crap.

I wonder how long it will take them to realise something is wrong. Pretty long I guess, as most people seem to use their useless webmail interface...

google me: postfix smtp sasl/tls problems

If you get errors like:

warning: SASL authentication failure: No worthy mechs found
send attr reason = Authentication failed: cannot SASL authenticate to server XXX[YYYY]: no mechanism available

Then the problem could be that the sasl modules are not installed. A quick 'apt-get libsasl2-modules' will solve that.

an adventure

I'm trying to install our old laptop with debian for my mother-in-law. She will take it back to .it and use it from there. This should be simple, but there are so many problems to overcome: get a descent IM system for her to use (gaim?), configure the "alice" adsl connection with alcatel usb modem without having nor the modem, nor the certainty that the details are correct and last but not least: give her some easy way to use the system. This could be...entertaining.

On the other hand, giving her windows 98 in dutch would create even more problems I think...

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.

Updating .asd files to handle locked packages

cmucl 19a will have package locks. Several libraries try to modify locked packages, for example cmucl-clx, hemlock etc. So I'm adding these stanzas to the asd files:

#+cmu

(defclass cl-modifying-file (cl-source-file) ())



#+cmu

(defmethod perform ((op load-op) (c cl-modifying-file))

  (ext:without-package-locks

     (call-next-method)))



#+cmu

(defmethod perform ((op compile-op) (c cl-modifying-file))

  (ext:without-package-locks

     (call-next-method)))



#+cmu

(defmethod source-file-type ((c cl-modifying-file) (s module))

  "lisp")

Normally in src/tools/build-utils.sh there is (setf lisp::*enable-package-locked-errors* nil). But for .asd packages that might get loaded by the user, such a modification of the system cannot be.

So 19a will have to wait a little more before appearing in experimental.

No LSM for me

I cannot go to LSM 2004, client has some deadlines in the week ;-(. I still hope to go to Sane 2004 tho.

The cmucl 19a package is slowly getting there. It already compiles, but I still have to check if everything is included, that the scripts still work etc...

created new cmucl packages

When common-lisp.net is back up I'll start with packaging the new 19a release...

CRM114 failed and burned because of libtre4 failure

in unstable. A bugreport has been send..

First post

I've deviced to split my blogs. My personal blog will put lisp and debian related stuff here...