Bought two new ATX power supplies; one for my usual desktop box,
and the other for the Alpha. In principle this means I now have a
comfortable machine to resume hacking sbcl amd64 on, and I have a new
(old) loaclhost.telent.net which will host telent cvs (clx, araneida,
cliki, etc). The plan is that my
wonderful employers put it on their
freebie-hosting-for-employee-boxen network.
Slowly rewriting the threading section of the SBCL Manual. (a) in
texinfo, to see what it's like; (b) in English, so that other people
may see what it's like
Suffering from cold-type-thing on Friday: sore throat, headache,
etc, so took tube home instead of riding. Feeling better by Sunday,
so went skating. Much fun, albeit at a
slightly slower pace than I'd been commuting in previous weeks. So,
I'm going to try at least the first half of the Friday Night Skate this week. (If
you're reading this and likely to be there on Friday or Sunday, drop
me an email and I'll wear something distinctive like my purple SICP
tshirt).
Lost again on way home from work today. Careful examination of the
junction where I should have turned right, if I were riding my morning
route in reverse, revealed that it was a one-way street. So, wandered
a little further up the road, found another right turn, rode aimlessly
for a while. Eventually pointed myself in the right direction with
the aid of a couple of maps in convenient bus shelters. Less lost
than Thursday, but extra time with an A-Z will still be required
It's now 0:26am. If this entry comes out dated at 5am, blame the
rtc/apm handling in Linux 2.6, which has a nasty intermittent tendency
to decide that it can get through two seconds in as long as it takes
the wall clock to dispatch just one. In the fact of that kind of
drift, ntp just curls into a foetal position and whimpers.
This evening I went to the scheme uk
meeting, to discuss "threading implementations in Common Lisp
(probably with a certain amount of focus on what to do with special
bindings).". The Schemers were, of course, rightly horrified at the
whole concept of dynamic bindings, but once over their initial shock
that any language should have something so evil, we did have an
interesting discussion. (Slides here,
slide viewing software and general discussion of same here.)
One of the reasons I wanted to talk about special variables in the
presence of smart people is that it's been a contentious point for
SBCL threading lately. We're agreed on the general concept: a special
has a global value and may additionally be dynamically bound
per-thread; threads only see the global value if they don't have
bindings. What there seems to be some contention over (and looking
back over my diary entries over the last couple of months I see I've
referred to this before) is the initial values that a new thread gets
when it starts up: are they (a) the values in the thread that called
MAKE-THREAD, or (b) the global values?
Presently we take the calling thread's values. I originally wrote
it this way because it didn't occur to me to write it any other way,
but in fact there are arguments both ways. If we take the calling
thread's values, it becomes very simple to set up a new thread's
environment if it needs to do anything special:
or indeed to not set up the new thread's environment, instead
letting it share the caller's objects. For example, we currently
arbitrate access to the listener's io streams using a mutex bound to
session-lock: when a thread T1 wants to get input or to start the
debugger or similar, it first attempts to grab session-lock; the
user can then ask the current owner of that lock (which presumably is
in a repl) to release it so that T1 may interact. If a new thread T2
is never going to use this listener (perhaps it's going to create its
own listener; that seems a fashionable thing to do lately) it merely
has to create a new lock and rebind session-lock to it. This is
only possible if each newly created thread gets its specials from its
parent: a truly global session-lock* would be a pretty useless thing.
The alternative is to do what apparently every other threaded CL
does. (Despite what you may have read about SBCL's attitude to
backward compatibility, this is actually a pretty compelling argument
on its own.) Here's one example of a situation, loosely based on an
actual SLIME problem, where that would work better: you've written an
alternate listener that stores, say, a stream connecting it to emacs
into emacs-io. IO on this stream must obey a particular protocol
where requests are responded to in sequence. If the user types
something into your listener that happens to start a thread, that new
thread inherits your emacs-io handle, and if it then wants to print
something on this stream (or worse yet, read messages from it) -
perhaps because it's triggered the debugger - it will almost certainly
be talking out of turn.
I'm actually now not totally convinced that I've explained the
SLIME situation correctly, because if I have I think that's their
fault, and it certainly seemed more convincingly an SBCL issue at the
time it was explained to me...
Anyway, what's interesting is that despite the fact I've slowly
come round to thinking that global values would be more sensible, the
Schemers pretty much universally said "current values" when I asked
them. So, hmm. There also seemed to be fairly strong consensus on
how much locking the library should do around things like stream
buffer and hashtable access (less, rather than more), which is
gratifying.
I have nothing to do this weekend. That's not actually true; there
are lots of things I could be doing, and I'm ignoring all of them in
favour of a mostly unbroken 4-day sbcl amd64 hacking stint.
(Took break for skating on Friday; stopping also for skating again
on Sunday afternoon, and possibly later this afternoon for cleaning
the bearings in the skates if I can figure out how to get them out of
the wheels)
In the meantime, no real news yet. Spent the first day and a half
of my four day hackathon trying to figure out whatstate I'd laft the
tree in last time.
I'm mobile again. My new laptop battery and PSU arrived yesterday
just as I was leaving for work, so after a complete charge and
discharge last night (more to find out how long it would go for -
about three hours - than out of any real deep-seated belief that the
battery technology demands it), I now have wireless power along with
my wireless networking. Spent a little too much time last night
wandering around the house saying "yay! no wires!" when I should
instead have been grovelling over amd64 stack frames.
The stack frame in question (for %MAKE-HASH-TABLE) actually
seems to have little or nothing wrong with it; at least, after I fixed
MOVS to output appropriate REX prefixes (prefices? prefaces?) where
needed. Somewhere in the middle of it, though, I'm getting a pointer
to the middle of some vector where I should be getting the boxed float
1.5. This is probably a fault in floating point (which is directly
lifted from x86) or in the allocator. I hope it's the allocator. I
know how that works already.
For the past few years I've been sneering at PHP
based mostly on little more than a cursory glance back in the late
1990s sometime. As I recall, after realising it had different
database glue functions for each kind of supported database - instead
of using some kind of switch a la Perl's DBI - I fairly swiftly
decided it wasn't for me. That impression has since been reinforced
by Aaron Crane's UKUUG presentation (link above) and Rasmus Lerdorf's
infamous comment on compiler technologies.
Well, for one reason and another (day job) it's time to revisit
that decision, so expect bits of PHP to be littering this diary in
future days. The rules are that I will only be commenting on things
which I find either significantly clever or apparently stupid, but I
reserve the right to demonstrate apparent stupidity to the world
without having first investigating whether said stupidity vests in PHP
or in me. So, first up is this entry in php.ini:
; When floats & doubles are serialized store serialize_precision significant
; digits after the floating point. The default value ensures that when
; are decoded with unserialize, the data will remain the same.
serialize_precision = 100
Even supposing that there's some reason the numbers have to be
serialised readably and you can't just save the bits (unless PHP is
expected to run on non-IEEE systems, I think this is unlikely), it
still only takes
two minutes with Google to find a better approach.
There is a PHP mode for emacs. It's available separately, or at
least not part of my Emacs installation, and claims to be "mostly
concerned with setting up syntax colouring" - it leaves indentation to
the C mode that it's based on. I'm not getting warm fuzzies from the
thought that PHP has been around all this time and still nobody with
elisp clue has wanted to spend significant time on it.
Sod that then, I'll use C mode.
This impressed me:
Now the new, combined mode will be invoked if any of the above mentioned files are opened or created. To reduce the indentation problems, always open php regions in your files as follows:
<?php />/;
This will stop psgml-mode from messing with the indentation in the php-mode subregions (it thinks the <?php-tag is immediately closed again) and un-confuse php-mode's parser (which think's the wierd stuff it just read ends at the ";"). :-)
OK, No more PHP whinging. After three days of reading PHP references
followed by a relaxing(sic) weekend spent staring at x86-64 assembly,
I'm starting to see why it is the way it is; at some future date I
will regale you all with my opinions, but in the meantime I'm still
thinking.
(Which is not to say that I think it's that way for good
reasons, just that I don't have quite thw same expectations as I
started out with)
After some fairly extensive googling I seem to have fixed the problem#
Tue Apr 20 18:05:25 2004
Topics:
After some fairly extensive googling I seem to have fixed the problem
on my laptop that makes the clock run too
fast. Somewhere in 2.5, the Linux people decided to use the TSC
for a time source instead of whatever was previously being used (the
PIT, or the 8042, or something). My laptop continuously varies CPU
speed to save the battery (and without informing the kernel in any way
that I know about, so the CPU_FREQ stuff is no help), which makes the
TSC go up and down and round and round, or something. After rebooting
with the option clock=pit it seems to be much happier.
Except that /proc/cpuinfo now says
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 0.000
which seems ... wrong. But that's just cosmetic, whereas the clock
drift was causing actual problems.
I've pretty much stopped reading comp.lang.lisp (did I mention this#
I've pretty much stopped reading comp.lang.lisp (did I mention this
already? oh, ok, not for several days), but I do occasionally point
google groups at it to make sure I'm not missing anything. Lately
there seems to be a lot of talk about producing Linux CD-based Lisp
environments: in short, what I was trying to do (and to charge money
for) six months
ago. Not being in a position any longer to see this through (nor,
happily, being in quite such a pronounced need for new revenue
streams), I can not only give the world the benefit of my
experience(s),
but the code that goes
with them. Enjoy.
I have done no Lisp development lately, beyond intermittent (and
not especially successful) poking at amd64. Lonix meeting (pub) on
Wednesday, uk-lispers (pub) on Thursday, Friday Night Skate (followed
by pub) on Friday, GLLUG saturday (followed by - can you spot the
pattern? yes, more alcohol) and skating to Greenwich (scroll down) on Sunday. Followed .. ok,
you get the picture. Monday morning awoke sore, slightly sunburnt
and dehydrated, but more annoyingly, unable to raise my right arm
above shoulder height without wincing: managed to fall on it
(actually, tripped and rolled on it, I think; I'm a little unclear on
the details) yesterday.
dillo b0rked. At least, dillo from emacs using my special recipe now
renders the window, starts a second dillo thread for hostname
resolution, then gets killed by SIGHUP for reasons not completely
obvious to me. So, no hyperspec lookup, and time for bed.
Yesterday's entry may have been ambiguous. I didn't fall on my
shoulder because I was drunk - indeed, I fell on my shoulder several
hours before getting drunk. I fell while skating, which I claim is in
some way morally superior.
If you get an error updating cliki, this is intentional#
If you get an error updating cliki, this is intentional. I've
temporarily set it read-only, due to the actions of some pubescent
wannabee who replaced upwards of twenty pages with pornographic
images. Will reenable it as soon as something shiny distracts him and
he pisses off elsewhere.
The good news is that apparently there is no bone damage in my
shoulder (got it x-rayed today). The bad news is that even soft
tissue damage may take 6-8 weeks to heal, and in the meantime every
time I raise my arm above shoulder I get a stab of pain the likes of
which I wouldn't wish on anyone except possibly wiki vandals. So not,
really, in a very good mood.