One google search I wish I'd done a few days ago is for "dabs#
Sun, 03 Oct 2004 01:57:35 +0000
One google search I wish I'd done a few days ago is for "dabs
returns". Now I have to attempt to get my refund or replacement
item from a company that has (a) no customer service telephone number,
(b) an average 1-2 day turnaround on email: I'm not expecting
this to get resolved soon.
Off to Paris tomorrow (work trip). I was somewhat annoyed when
this trip was arranged as it didn't involve a Friday away, hence no
opportunity for Pari
Roller. Every cloud etc etc though: but I tried my skates on
yesterday and got about ten feet across the carpet before deciding
that it was too painful still to be entirely a sane idea - so, maybe
that's not so bad. Normal walking around is now pretty much fine, but
the boot presses into my leg exactly where the sore spots are (this is
probably not a coincidence) making any robust attempt at a sideways
push into an exercise in ocular irrigation.
Araneida 0.9 released#
Fri, 08 Oct 2004 17:31:06 +0000
- Portability to multiple lisps:
- SBCL, as before
- OpenMCL, threaded handlers only
- Allegro, threaded handlers only
- Armed Bear Common Lisp, threaded handlers only
- CMUCL, serve-event only
- CLISP, serve-event only
- LispWorks, threaded (from Jochen Schmidt, based on Portable AServe)
In particular the CLISP support is a bit of a hack; timeouts are still
notably missing, and you must run (araneida:host-serve-events) after
you're done running start-listener on all of your listeners.
(Brian Mastenbrook, Jochen Schmidt)
- SERVE-EVENT fixes so that non-Araneida fd handlers can be
added/removed during request handling. More than slightly kludgey,
and less than entirely thread-safe, but this can be blamed mostly on
the nature of serve-event. (Brian again, and Luis Oliveira)
Back in the UK#
Fri, 08 Oct 2004 17:31:59 +0000
Back in the UK. Currently in Kent somewhere, I think.
Alan Cox on writing better software is a good read; even going so#
Mon, 11 Oct 2004 13:11:33 +0000
Alan Cox on writing better software is a good read; even going so
far as to recommend the use of modern languages (GC, type safety,
etc). Probably doesn't tell you anything you don't already know, but
comes as a refreshing change after some of Linus's more widely quoted
"you have to be a Real Programmer to hack on Linux" comments.
An example of this is, with locking, instead of having one function
for taking a lock and another function for releasing the lock, which
inevitably means that someone always has an error handling or an
unusual case where they forget, you have a single function which calls
another function locked; it takes the lock, calls the function, and
drops the lock.
Unless the function performs some kind of non-local exit, at least.
Makes you glad to have UNWIND-PROTECT (that's finally in
Java, for any readers I have left that don't speak Lisp) - and of
course WITH-LOCK-HELD. C++ has that whole
resource-acquitision-is-initialization pattern thing instead, which
probbaly does the job just as well.
(I'm so mellow today. I think I'm sickening for something)
Discuss: what relation does taint checking have to type
checking/inferencing? Both are about carrying attributes of an object
around with that object, and in operations involving that object,
combining the object attributes in some way (some fairly trivial way,
if it's just a single bit that says 'tainted') to get the attributes
of the result. It might (though I'm not sure it's necessary) be
desirable to `untain' an object in-place, whereas it's rare to want to
change its type (although even then I can think of several systems
I've used CHANGE-CLASS in).
Marilyn Manson's cover of "Personal Jesus" is such a missed#
Sat, 16 Oct 2004 10:50:28 +0000
Marilyn Manson's cover of "Personal Jesus" is such a missed
opportunity. It sounds just like the original with guitars.
Johnny Cash should have done it instead.
OK, I've said that before
(Yes, I know it's no longer possible for Cash to sing anything else
he hasn't sung already. You needn't email me just to point that out)
Edit: OK, it turns out he has covered it. Many
thanks to all the people who've corrected my appalling lack of
knowledge. You can stop now ...
Replacement cpu is here#
Sun, 17 Oct 2004 00:36:12 +0000
Replacement cpu is here. After a short some inspection of the various
bits of computer I'd managed to order, I realised that (a) no fan, and
(b) motherboard too large to fit the case in which I was planning to
install it. Rectified this situation with short trip down Tottenhan
Court Road. Put everything together. Worked first time too, good grief.
After reading a little on the difficulty of installing debian
amd64 with debootstrap (seems you need to be running a 64 bit kernel
to do it successfully) I decided that if I was going to write an ISO I
might as well take the opportunity to install Ubuntu.
First impressions, then: installs from a single CD. After a fairly
non-taxing text-mode installation (involves one reboot) which
automatically found my graphics card, mouse, network and audio, it
boots straight up into some form of graphical login screen with a picture (taken
from above) of two attractive women and a bloke with no chest hair and
better abs than mine. Admittedly, as I have none to speak of that's
not really a great description, but they're the kind that would
naturally draw the eye if it weren't already being drawn down the tops
of the two ladies. After logging in, you get some kind of Gnome
desktop with Firefox as default browser. I'm not sure how long I'll
stick with it (I'll at least be finding the focus-follows-mouse option
if it has one, and installing a real xterm toot sweet) but we'll see
how it goes. Expect to see various comments on particularly good/bad
aspects in forthcoming days, if it has any, but it does seem pretty
slick so far.
I call that a successful weekend#
Mon, 18 Oct 2004 10:21:58 +0000
I call that a successful weekend. As previously reported, I have a
working computer at home again. The ubuntu default desktop lasted
about two hours before I reverted to my old sawfish/xterm ways: I have
a real reason and a rationalisation for this, which are respectively
(a) it was taking over a minute to start emacs at login and I couldn't
see why; (b) I wanted to bind the key labelled 'Ctrl' to Super,
instead of to Caps Lock, and couldn't see an option in the
configuration doodads. Turns out the emacs problem was probably
because I had localhost as 188.8.131.52 in /etc/hosts: I have no
idea how that happened.
Still and all, I managed to dust off the sbcl amd64 port and start
to page the details back into my brain. Assuming I'm hacking on the
right version, I may even have something to commit (define-instruction
forms for various sse instructions we need, albeit currently with
slightly dodgy^W^Wmassively broken disassemblies) today or tomorrow.
In other news, I am mostly not lame any more. Spent an hour or so
on Sunday skating in slow gentle circles around the shallow end of
Road: as long as I don't try doing anything complicated with the
left leg, it's manageable.
Clé RIB validation#
Mon, 18 Oct 2004 12:59:23 +0000
Clé RIB validation
This may not be so interesting to most of my usual readers, but is
added here in the hope that (a) Google will find it, (b) French Google
users will be able to understand it. The French banking system has a
thing called "Prélévement Automatique", which is
essentially an authority for a third party to help themselves to your
bank account at regular intervals. UK readers will recognise it as a
Direct Debit; I'm sure other countried have similar things. To to set
this up you need 23 characters of bank codes (5 char code banque, 5
char code guichet, 11 char numero de compte, 2 digits clé) ,
and it turns out that the last two of them are a checksum. I spent a
while looking around web pages written in languages I have no
particularly good grasp of (French, VB, PHP, some Clipper/Foxpro
thing) looking for details on how to calculate it, and eventually
transliterated a PHP example to arrive at the following:
create or replace function fr_calculate_cle(varchar,varchar,varchar)
returns char(2) as '
code_banque ALIAS FOR $1;
code_guichet ALIAS FOR $2;
num_compte ALIAS FOR $3;
instring = translate(lower($1||$2||$3),
cle := 62*to_number(substr(instring,1,7),''9999999'');
cle := cle+ 34*to_number(substr(instring,8,7),''9999999'');
cle := cle+ 3*to_number(substr(instring,15,7),''9999999'');
return substr(to_char(97-(cle % 97),''00''),2);
' language 'plpgsql';
If there's any better way to make postgres output a 2 digit zero-padded
number without a leading space, I want to hear about it.
<lisppaste> dan_b pasted "will the madness please fuck off and die#
Wed, 20 Oct 2004 21:10:54 +0000
<lisppaste> dan_b pasted "will the madness please fuck off and die?" at
<cliini> This is probably something we should show to people who ask if
+there's something like CPAN for lisp. Show them that and ask "like this?"
Thu, 21 Oct 2004 02:47:29 +0000
Subject: Re: CMU CL or SBCL on (FreeBSD/)AMD64 any time soon?
Gareth McCaughan <email@example.com> writes:
> But I don't want to find myself without a decent zippy
> Lisp implementation. Several different people seem to have
> done work on making SBCL run on AMD64 in the last N months
> (generally for Linux rather than FreeBSD); what's the
> current state of the world?
Since acquiring an amd64 machine of my own last weekend I've dusted
off the SBCL work I was doing earlier in the year (many thanks to
Kevin Rosenberg for ssh access to his machines, but it's a lot more
comfortable developing locally than over the internet, not to mention
that the appeal is so much greater now I own a machine that it'll run
You asked about "current state" rather than "progress", which I like,
becuase otherwise I'd have only have been able to say "it'll be done
when it's done". So:
If you're familiar with the SBCL build process I can tell you that
when I left off last it was generating plausible-looking
cross-compiled core files that got maybe two thirds of the way through
the cold-init process (at the end of which is a repl). After that all
that remains is building PCL, which is allegedly portable, and the
contrib modules, which are mostly actually portable if we limit
ourselves to considering sbcl-on-different-architectures.
After picking it up again on Sunday, I broke it utterly by deciding to
rewrite the floating point support to use sse2/sse3/xmm (faster, more
predictable, less weird) instead of the legacy x87 instructions. That
work is mostly complete at least in that it's now back to the point of
generating plausible cross-compiled cores, but (whether due to new FP
or to having simultaneously forward-ported the branch by several
months) it dies at about the second function call. This could be
considered a regression.
- 64-bit lisp word (yes, big cores)
- 61 bits of fixnum.
- uses all 16 registers
- sse for floating point (16 xmm registers)
Big known issue between here and the goal: bignum support, which is
still based on 32-bit words. Other than that it's mostly a question
of seeing what crops up.
I don't know much about the FreeBSD amd64 port, but unless they've don
something really weird I can't imagine it being much work to get SBCL
up on once we have a working compiler and runtime.
As others have mentioned, the x86 port of SBCL (at least on Linux)
runs fine[*] under a 64 bit kernel if furnished with appropriate shared
libraries. On my machine it takes around 9-10 minutes to build itself
including all contribs: I don't know objectively how zippy this is,
but it's about a sevenfold improvement on the box it replaced, so I at
least am content for the moment.
[*] Actually, fine except for threads. But if you're on freebsd you
don't get them anyway, so I mention that mostly for completeness'
All's well that ends well#
Thu, 21 Oct 2004 19:03:18 +0000
All's well that ends well. And while this is not actually over
yet, dabs can now at least tell me that they're intending to
credit my card "within the next few working days".
Which is, um, only 7 full days after they picked the parcel up, or
three weeks after I received the incorrect order. Next time I'll be
buying from somewhere that still answers the phone - or at bare
minimum, takes less than 24 hours to reply to email.
Announcing the TRIVIAL-SOCKETS interface for undemanding network clients#
Sun, 24 Oct 2004 02:25:13 +0000
Announcing the TRIVIAL-SOCKETS interface for undemanding network clients.
Having once already tried to define a flexible networking
interface that would anticipate most of the weird stuff that people
might want to do with an underlying BSD sockets interface, I'm now
going to the other extreme: TRIVIAL-SOCKETS has one exported function,
which takes a hostname and port to connect to and returns a stream.
FOO> (with-open-stream (s (trivial-sockets:open-stream "www.google.com" 80))
(format s "HEAD / HTTP/1.0~%Host: www.google.com~%~%")
"HTTP/1.0 200 OK
OK, you get the idea. Mostly unimplemented so far (it kind of works
on SBCL, but not totally), but please see texinfo spec and so forth at
never going to be sb-bsd-sockets, but we could still aspire to write a
spec in English that's a bit tighter than the CLOCC PORT stuff. And
make it asdf-installable, of course.
Sun, 24 Oct 2004 19:42:17 +0000
has (some degree of) support for SBCL, CMUCL, CLISP and Allegro. I
don't have a machine readily to hand on which I can run OpenMCL
(actually I have an imac and two broken G3 powermacs, but none of
them are plugged into anything) but its socket interface looks pretty
similar to ACLs, so I'm sure it won't be hard to add that one. ABCL
would be a nice addition, if anyone feels like it.
Subject: ROBOTS meta tag and transient information#
Tue, 26 Oct 2004 01:14:56 +0000
Subject: ROBOTS meta tag and transient information.
I run a couple of Wiki sites which are regularly crawled by Google:
ww.cliki.net and alu.cliki.net. They feature highly in relevant
searches and overall I'm pretty happy with this state of affairs.
You're no doubt aware that the less ethical of the "search engine
optimisation experts" spam their URLs onto pages of unrelated but
high-PageRanked wiki sites in the hope that the Google bot will
index and follow the links to their sites before the wiki's regular
users spot and revert the changes. Some people think it's the next
big thing after blog comment spam.
So, I would like to minimise use of my wikis as unwitting link farms
for spammers. One approach I'm considering is to insert a
<meta name="ROBOTS" content="NOFOLLOW">
html head element when I serve new versions of pages. In 24 hours
it's pretty much a given that someone will have noticed and reverted
the spam: result, the google karma does not spread to these
undeserving cases. Once a page has lasted 24 hours without subsequent
edits, I'll stop sending out the meta tag and Google can index the
page as normal thereafter.
The downside: this will be less than ideal if the google bot caches
meta tags between one run and the next; i.e. if having once seen that
it shouldn't follow links from www.cliki.net/index, it remembers that
and never follows them again despite that on its next visit the header
is no longer there.
So, at last, my question: does your bot cache robots meta tags between
runs, and if so for how long and is there any way that a web site can
ask it not to? If it doesn't, it seems that this would be a
reasonable approach for a lot of wiki engines to help reduce one
source of pagerank spam - and when spammers realise this is happening,
they'll (eventually, maybe) stop spamming the said wikis. With luck
and a following wind, everyone wins.
Let's see if we get a reply ...
Wed, 27 Oct 2004 00:56:34 +0000
> Thank you for your note. While we appreciate your efforts to help maintain
> the quality of our index, we don't personally review individual sites, nor
> do we comment on webmaster techniques or the details of our search
> technology beyond what appears on our site.
which ranks right up there with Dabs in the
less-than-stunningly-helpful department. They did recommend that I
look at their "newsgroup discussion forum for passionate Google
users", but frankly I don't have it in me to get especially passionate
about someone else's search engine, and I tend to be disturbed by the
company of those who are. Nigritude ultramarine my ass.
In the spirit of JFDI for which Lispers everywhere are known[*], please#
Wed, 27 Oct 2004 02:09:40 +0000
In the spirit of JFDI for which Lispers everywhere are known[*], please
find included-by-reference an asdf-installable trivial socket
[*] For the avoidance of doubt: yes, this is sarcasm.
Since we're talking about SBCL 1.0, my 2p#
Thu, 28 Oct 2004 21:17:13 +0000
Since we're talking about SBCL 1.0, my 2p. This is my personal
wishlist for things I want to make happen between now and 1.0 - or at
least, for interfaces I am unsatisfied with and would not like to have
to retain forever.
- extensible streams and stackable stream translations
- a socket layer (replacing and/or based on sb-bsd-sockets)
in which a stream can be a socket.
- hide the sb-threads interface, recommending instead something
that deals in the same kinds of objects as bordeaux-mp
I'm also thinking about (or anyway, idly toying with the idea of)
writing an extensible texinfo -> foo translator, so that we can easily
do things like hyperspec.el for all texinfo documentation. That could
be done at any time really, though, and I'm not short on other stuff
to do first.
Thu, 28 Oct 2004 23:17:04 +0000
(with-server (s (:port 8913 :reuse-address t))
(with-open-stream (c (accept-connection s))
(format c "This is a compliant though pointless implementation
of the finger protocol~%"))))
Presently only implemented for SBCL, and doesn't handle errors yet.
I'm going to sleep now, so please feel free to grab it from CVS and
fix either or both of these omissions before I next get a chance.
The first sentence of this entry is in the nature of a #lisp
in-joke. If you're not a channel regular, I apologise.
Charles Stewart has CLRFI Snippets#
Fri, 29 Oct 2004 10:53:36 +0000
Charles Stewart has CLRFI Snippets. I think it's good that the CLRFI process has
visibility (i.e. that people are saying "this should be a CLRFI"
instead of "this should be in the next revision of the standard"), but
writing a decent proposal is a lot more work than simply suggesting
one should be written, and even getting constructive feedback has been
a battle. My previous experience has been - to paraphrase Ghandhi's
oft-quoted saying - that first they argue with you about the package name, then they take your text and use it without attribution. If
stage 3 is "then you win", we haven't reached that just yet.
Why trivial socketry: the motivation#
Fri, 29 Oct 2004 11:22:40 +0000
Why trivial socketry: the motivation
Essentially, it's part of a plan to make a CL-based system that is
good for interactive use in a Unixy setting. There are more than a
few other things that I expect will also be necessary: this entry
talks mostly about the repl
- the unix shell uses short command names ("wc", "nc", "ls") to
minimise typing. Minimising typing is good, but I still have the
typical Lisper's attitude to abbreviations that says there are many
ways to abbrev. a word and only 1 2 spell it out in full, so guessable
i/fs shld nt use abbrvs. So I propose instead, given also that we
have buckets of cpu these days that Thompson and Ritchie weren't
blessed with, that the repl has smart symbol completion bound to the
Space key. This needs to be sufficiently smart that it can expand
``dpd Space'' to default-pathname-defaults.
- the general effect of the preceding will be to make for some very
long command lines, and navigating through them using only cursor
left/right will take ages. It may make sense to have cursor up/down
move within the current command instead of recalling history entries,
but at any rate there needs to be some attention paid to this aspect.
- a magic bracket key to close all open parens and submit the
form. Probably C-Return or similar.
- this one may be mildly controversial if you're a Lisper, but: how
often have you mistyped something and realised after you hit return
but still long before the error message comes back? Sometimes when
using a unix shell (especially on a slow link), I can typo, hit
return, hit cursor up, fix the problem and press return again before
I've read the error message, and in such circumstances I really don't
want a debugger to spring up and disrupt my flow. On the other hand,
the debugger is invaluable for real errors, so I'm not sure what the
right answer here is. Perhaps pressing Return again (i.e. entering an
empty line) should exit the debugger; it wouldn't be hard to adapt my
muscle memory to pressing RET a second time before editing the command
- one or both of the following: previous expression results to be
automatically named (like gdb's $1, $2, ...) so that they can be
referred to in later commands, or a simple way to create and assign
them by hand. In either case, the variables need to be visible in the
repl but not in functions called by it, and to stay around until the
- More to follow as it occurs to me, I'm sure. A good idiom for
doing what unix pipes do, for one thing.
Sat, 30 Oct 2004 22:14:53 +0000
is out now. Available on your preferred cCLan mirror if and when said
mirror next updates from ftp.linux.org.uk (must do something about
that one day: if you recognise a site in the list at the cCLan redirector
that's under your nominal control and it doesn't have trivial-sockets
0.2, please either rectify that or mail me and ask to be removed from
the list), it includes client and server socket support for Allegro
CL, CLISP, CMUCL, LispWorks, OpenMCL and SBCL, as well as client-only
support for ABCL.
Some time in the near future I will compile a table containing all
the options involved in the opening-a-socket-stream task that a user might
reasonably want to frob, and all the various common lisp implementations
in which they might want to frob them, and find some way to beat each of
the various vendors around the head until their particular column
is not full of "unimplemented in this lisp". in the meantime, the
last section of the manual should give you a pretty good idea of what I'm getting at.
0.3 will have timeouts.
I don't know whether linking to interseo.com#
Sun, 31 Oct 2004 12:54:37 +0000
I don't know whether linking to interseo.com
and transwell.net with the link text "wiki spamming bastards"
will tag them appropriately in the eyes of Google or whether they'll
just be glad of the extra pagerank. So, I haven't. But nevertheless,
they or someone attempting to promote their services are indeed wiki
spamming bastards, and though I obviously don't condone
vigilante violence in any circumstances, I should probably advise any
prospective customers of interseo.com or transwell.net
who may have arrived here for whatever reason that the said
interseo.com and transwell.net are risky people to do
business with as sooner or later some more precipitate net citizen is
going to e.g. firebomb their offices. And then what will happen to
your "top ten google hit, guaranteed"? My advice is that instead of
using interseo.com or transwell.net you find some
company that's not associated with such disreputable practices as wiki
Oh, that goes for navisolutions.com as well.
P.S. If you've had problems with these names turning up in
inappropriate places on a wiki you read too, feel free to link to this
article. The permanent URL is https://ww.telent.net/diary/2004/10/#31.46477