Forget what I said about inline alloc#

Fri, 06 Aug 2004 09:36:45 +0000

Forget what I said about inline alloc. On unthreaded builds, or on a P4, it makes things slower, and we don't yet know why. Inline allocation has been disabled for the moment until someone (preferably with a better grasp of assembly-level optimization than me) looks at it.

My keyboard skills are even worse than usual, lately. After noticing twinges in my left wrist when chording sequences like C-t or C-w (which, yes, I do entirely left handed, naughty me, in my defence I can say only that my laptop has no control key on the right) I remapped the Caps lock key as Control and turned the Control key into Super. Well, that was the intention: in practice it seems a bit trickier, at least as far as GNU Emacs is concerned. But I will probably have a working Super key again just as soon as I restart X, so I guess that's one silver lining to keep in mind next time the computer crashes. Anyway, point being: I'd forgotten how many control sequences (C-a, C-e, C-k, C-t) are pretty much muscle memory in my everyday typing, and now they don't work any more. Slowly getting used to it.

Spurred by Debian#

Fri, 06 Aug 2004 09:49:18 +0000

Spurred by Debian bug reports regarding behaviour in asdf that I'm not sure I fully understand, I'm thinking about redesigning the internals to be less, well, tacky.

An asdf system is mostly a description of a bunch of source files, and doesn't say much about what the outcome should be when that system is compiled or loaded or whatever else. Partly this is intentional: users may think of new things to do with a system that the system author didn't have in mind, and shouldn't be constrained. Partly though it's just screwy: a traditional build tool for the non-Lisp world (such as make(1)) lists targets (or goals) that can be achieved given the source files and a set of rules, but asdf just has the rules. In fact we can't describe desired outcomes in asdf; not only do we have to talk to it procedurally with instructions like "apply operation foo to component bar", but to compound the sin we do this in the full knowledge that it'll at least partly ignore us: applying compile-op to a system doesn't just mean applying compile-op to each component of the system but may involve generating and reading temporary files, loading some of the files (e.g. those with macro definitions) and arbitrary other tasks. (It gets even more arbitrary when there are non-Lisp components involved, but I think that's mostly a difference of degree not of kind)

Once we have goals, and we have sub-goals, it should be simpler to express a number of problems elegantly in asdf. For example, we have a bunch of c source code files that in some circumstance we want to compile, link together into a shared library, and load into the running Lisp image. Or we'd like to define a rule that creates an "executable" from a system. I think this should help with any operation which involves intermediate files, or which produces a different number of files as output than it was supplied with as input.

Fell over#

Sat, 07 Aug 2004 12:23:01 +0000

Fell over.

Yes, indeed. In my devotion to providing you the reader with a constant stream of drivel to read here, I tripped while skating through the underpass last night when someone fell in front of me. Lost some few square inches of skin from my left elbow, ruined a tshirt, and fortuitously for blogging purposes managed to damage my shoulder in some way that makes it hurt when I raise my arm. Yes, again. Other shoulder this time, though. So, expect lots of entries typed partly onehanded with unnecessary details about bruise sizes.

Actually, I can't see any bruising yet. Thi might just be because it hasn't had time to develop yet, or I fell in some way that didn't involve a bruise, or my messing about with compression and random items from the freezer actually had an effect.

Oh well. It upstages wrist twinges, however you look at it.

Vomit frame pointer#

Fri, 20 Aug 2004 14:11:25 +0000

Vomit frame pointer

I think I've identified the (or, at least a) remaining problem with SBCL threading tests: frames with no frame pointer. Here's one. Ignore the jump to +15; that's just errno handling and not really relevant.

0x401d4550 <sched_yield+0>:     mov    $0x9e,%eax
0x401d4555 <sched_yield+5>:     int    $0x80
0x401d4557 <sched_yield+7>:     cmp    $0xfffff001,%eax
0x401d455c <sched_yield+12>:    jae    0x401d455f <sched_yield+15>
0x401d455e <sched_yield+14>:    ret    

Thread interruption works by sending the thread some signal (I forget which exactly; one of the POSIX RT signals) using sigqueue, with a function pointer in the sigval argument. The handler for this signal (which runs on the alternate signal stack, so as not to get in the way) frobs the signal context PC so that execution will continue with said function when the handler returns, and puts a couple of frames on the regular stack so that when the funct6ion returns the thread goes back to whatever it was doing before being sent the signal. All well and good so far, and means we're not executing arbitrary lisp code from within a signal handler, which as we already know Would Be Bad.

The problem, I suspect, is that when we interrupt the thread during execution of a function which isn't using a frame pointer, the stack that we build on top of it is bogus-or-at-least-unusual. This is not a problem usually - it's a good enough frame that we can unwind through it and let the original function continue working - but it does sometimes stop us from being able to look up the stack to find things like catch tags in preceding frames. Which is necessary to the implementation of,among other things, QUIT - therefore TERMINATE-THREAD doesn't always work that well.

Relevant piece of SBCL that needs grokking: SB-DI::X86-CALL-CONTEXT. Expectation-setting comment from sources:

;;; Try to find a valid previous stack. This is complex on the x86 as
;;; it can jump between C and Lisp frames. To help find a valid frame
;;; it searches backwards.
;;;
;;; XXX Should probably check whether it has reached the bottom of the
;;; stack.
;;;
;;; XXX Should handle interrupted frames, both Lisp and C. At present
;;; it manages to find a fp trail, see linux hack below.

For the record, I was wrong#

Mon, 23 Aug 2004 12:41:46 +0000

For the record, I was wrong. We don't find catch tags by searching the stack; we maintain a linked list starting at CURRENT-CATCH-TAG. This is good news insofar as searching the stack is not a precise science and it might not have been possible to fix things if we had been chaining through stack frames. This is bad news in that I can't find what's clobbering the aforesaid CURRENT-CATCH-TAG, so although I have no doubt it's possible to fix things, I presently don't know how. In other words, don't expect a fix for 0.8.14

In other news:

1. I'm playing with Eclipse again: rationalisation for this is that something strange happened to sawfish on my last apt-get upgrade, so I think I'd like a window manager that Debian doesn't know how to break.

2. More episodes involving minor skin loss; arm still aches a bit but seems to be getting better; no visible bruising. Bought new skates a week or so ago; left them at home this morning (it was raining) and only realised how much improved the fit is when I went out at lunch in the old ones to get a sandwich.

3. I am 30. It doesn't seem to be much different.

cvs.telent.net downtime, imminent#

Wed, 25 Aug 2004 17:18:22 +0000

cvs.telent.net downtime, imminent.

cvs.telent.net is hosted by my employers. Due to an office move this weekend, the network it's attached to is going away. Indeed, the box is also going away, but won't immediately be reunited with the network when it arrives in its new home. Downtime will be from some time on Thursday 26th; limited access (essentially just ssh, cvs-over-ssh, and mail) will be available from mid next week, and full availability (anon cvs and cvsweb) we're not sure when. Worst case estimate is Novemeber, I think, though obviously we're hoping it'll be considerably sooner. If it does take a while I may look at enabling anoncvs over ssh as well.

In short, if you're reliant on anoncvs for any of CLX, araneida, cliki, or anything else on that machine I'd forgotten about, now would be a good time to cvs update.

This does not affect www.cliki.net or any of that stuff; that's all elsewhere. This is just for access to source code.

I said earlier that I'd write something about protocol-oriented#

Mon, 30 Aug 2004 14:09:09 +0000

I said earlier that I'd write something about protocol-oriented programming. Then I decided that it'd be more fun to send it to ll1-discuss instead of posting it here. In the process of penning it, I came across this article by Mikel Evins, which (a) says everything I wanted to, and (b) more, and (c) was written more than ten years ago, so decided I didn't need to.

I'm going to add my 2p summary anyway, based on the previous #lisp discussion that also led to Christophe Rhodes' LSM2004 presentation: a protocol is an defined communication across an ownership boundary, in which both sides have expectations of the other. This "equal peers" clause is what sets it apart from an API, in which the expectation may all be one-directional. Trivial example: consider the unix sync() call - the client doesn't have to do a whole lot, but the requirement on the implementation is strong. Conversely, in qsort(), where the client provides the comparison routine, both sides have something important to do if the job is to get done.

(Of course, simply having used a protocol somewhere doesn't mean you're thinking in a Protocol-Oriented manner any more than having used a function somewhere means you're programming Functionally. Some languages have better support than others for different ways of thinking. Your Mileage May Vary. There Is No Silver Bullet. Objects In The Rear View Mirror etc etc)

For other stuff about protocols (and especially stuff that predates the current flurry), Google Groups might be a good place to start. Here's an article by Scott McKay to be getting on with. Lots of protocol discussion hapened in comp.lang.dylan too, unsurprisingly.