For the record, I should add that in the following (chronologically
preceding) entry, I was not making fun of "bziki__"'s typing. (My
typing is, I freely admit, too bad for me to be able to do that to
anyone else). I was making fun of the content.
SBCL 0.7.13 is out (or at least, tagged. Not sure if it's been
announced outside of sbcl-devel yet). SBCL 0.7.13.{1-3,5} contain
various fixes and refactorings made during the course of thread
development, and now it's time to fork another thread branch from
0.7.13.5 and carry on.
So after cleaning up the CVS mess left over from yesterday's
merging exercise, I checked out a fresh copy of Araneida, built a new
threaded SBCL, and hacked around a little.
When using apachebench for microbenchmarking your web server, the
easiest way to get a really good requests/second figure is of course
to use a really small file. I was seeing 90-130 requests/second at
times, but each response is something like 240 bytes long, so, well,
yeah.
When ab complains about failed requests due to "length",
what it means is that some of the documents returned were of different
length to the first response. Obviously if your test document is
anything like this
one, you can expect 91 alleged failed requests in the first test in
a fresh image.
So, as you'd guessed, I'm using apachebench as a basic smoke test
to flush out the most obvious threading issues in SBCL. So far I
found
that my spinlock_get in C actually didn't (didn't spin or
lock, in fact),
that there was some thread-unsafe code to allocate new
buffers for file-streams,
that my db-sockets hack to allocate new
sockaddrs in Lisp space really needed to be protected with
without-gcing,
but that it wouldn't have made much difference
if it had been, because without-gcing doesn't actually disable
garbage collection any longer.
Fixed the first three, kludged around
the last - now it would work if atomic-incf were actually atomic
instead of just a placeholder for incf.
All told it's going pretty well right now, so there's bound to be
some horrible problem cropping up soon.
This lame excuse for a web crawler is editing cliki pages.
Automatically. Specifically, it's stripping out carriage returns from
the body, which as you can imagine makes it difficult to see where the
paragraph breaks are.
I don't know if the fault here is with WebSPHINX itself
or someone's custom crawler based on it, but if people are going to
write software that doesn't actually work, they should not let it out
on the internet. Really.
Oh, and I might also point out that the pages in question contain
Some aspects of CLX are deeply tedious to experiment with, because
changing them requires hacking around with macros, then you need to
rebuild all of CLX to make it notice the macro definitions have
changed.
But still, after a couple of pints I don't care quite as much
Here's a screenshot (which I
admit is dull and ugly and when will CLIM hackers learn that picking a
font other than Courier is 80% of the work of producing kewl
screeenshots) showing McCLIM running in SBCL/native threads. Some
work is still needed: it busy-waits. CLX has some horriblehorrible locking macros.
psql: FATAL: cannot write init file -- relation tuple form
Would it have hurt so much at least to say where this init
file was going to be written? Maybe also the value of errno?
It turns out to mean "/var is full" .
I don't know why I bothered to set this machine up with more than
one partition anyway ...
To those of my readers who don't as a matter of course go on and check#
I might add that pervasive use of getters/setters feels a lot less
ugly in a language where the syntax to update an attribute looks just
like a method call anyway -
(creditcard-number my-card) => "4123412341234129" ; a slot read
(creditcard-type my-card) => "VISA" ; a function call
(setf (creditcard-number my-card) "5455555555555555") ; a slot write
(setf (creditcard-type my-card) "mastercard") ; an error
;;; ... but, oh, look
(creditcard-type my-card) => "Mastercard" ; it already knew
Actually, I lied. The particular system I took those examples from
uses MOPpery to store all its data in a Postgres database anyway, so
none of the above is necessarily a straightforward assignment
under the covers.
Actually, I lied twice. Those aren't my (or, as far as I know,
anybody's) real credit card numbers either. Sorry, folks.
One of the things I am really looking forward to, given a natively#
One of the things I am really looking forward to, given a natively
threaded Lisp implementation, is the possibility of writing, acquiring
or just plain waiting for a text editor that can be customized in a
slightly saner language than elisp. In particular, right now, I would
like a comint mode that either (1) only retains n line sof output, or
(2) (preferably) doesn't eat 30% of my cpu appending lines to the
comint buffer when it gets large. Where large is around 250k lines,
at the moment.
I think I must have been busy lately. I just can't remember much of
what I've been doing.
Not that this is the problem that keeping an online diary is
supposed to solve, or anything. Oh well. Speaking of online diaries,
Is the active
user-base of Advogato incompetent? Well, yes. I was going to post
a followup saying "I used to hesitate before posting Advogato articles
because they'd get taken apart by knowledgeable people, but now I
don't bother to post them at all because they get taken apart by
people who just don't have a clue." But then I realised that
it would get taken apart by people who just don't have a clue. As
Mark Jason Dominus said, "Forget
what I said about the damn iterator pattern, already"
06:54:53 <Krystof> so the big question is: "what does the next
version get called?"
06:55:07 <Krystof> 0.7.14.1? 0.8.0pre.1?
06:57:10 <Krystof> (well, maybe that's not the big question)
06:59:16 <wnewman> I haven't noticed any response to my mention of
0.8.0 on the mailing list, so it seems to be only you and I who care.
07:00:40 <wnewman> If the SB-PCL:CLASS stuff lands, and Dan either
puts in threads or doesn't care, it's OK with me if the next release
is 0.8.0, and it's ok with me if it takes more than a month.
07:00:40 <wnewman> which hopefully gives everyone concerned enough
leeway
New SBCL (0.7.14) was released on Monday, and was probably notable
chiefly for being, as you see here, the last release before 0.8.
Unless you're using bit vectors, in which case you could get some kind
of 100x speedup, which I think is worth noting. 0.8 will have better
PCL integration, and (experimental probably-not-enabled-by-default)
native threads on x86 Linux. Yes, that's right, it's merge time.
Mostly this is an exercise in arranging the source such that threaded
and unithread sbcl can be built from the same code base, and (for
bonus points) that the code in question is reasonably free of Weapons
of Mass #define
Also London and Oxford meetings of (minimally overlapping) subsets
of the UK-Lispers list. At (or arguably, after) the latter of these,
Christophe fixed SXHASH on PPC, so it no longer returns 0 for symbols
whose names are less than 4 characters long.
Started cycling again last weekend, for the first time since, um,
last August. The saddle on my bike is
less comfortable than I remembered it as having been, but I expect
I'll get used to it again.
It's summer. So says my laptop, anyway. I can't remember what
timezone this colo box thinks it's in, though.
Spent some time yesterday and today attempting to determine why
SBCL unithread-build-of-threaded-code didn't: a variety of silly bugs
which nobody is interested in reading about
