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
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,
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
Sat, 07 Aug 2004 12:23:01 +0000
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
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
;;; XXX Should handle interrupted frames, both Lisp and C. At present
;;; it manages to find a fp trail, see linux hack below.
I'm hoping there's some better way to do this in the absence of a
sensible frame pointer; I can't help feeling that testing whether the
return address is in lisp space or not might be a start.
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:
- 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.
- 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.
- 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.