Again, the new machine comes with Red Hat, and after ascertaining that
it boots using grub and an initrd I really don't fancy replacing it
with Debian remotely. But nor, to be honest, do I want to continue
depending on a probably-soon-to-be-unsupported Red Hat version for
anything beyond a bare minimum set of services.
and another useless error message for the collection:
Jan 29 15:16:52 eval sshd[878]: PAM rejected by account configuration[9]: Authentication service cannot retrieve authentication info.
(In this case, it turns out to mean "when you renamed the user
you're trying to ssh in as, you forgot to update the shadow
file")
Most of my time lately has been wrestling with posix job control
stuff, so that multithreaded SBCL behaves somewhat less than
completely stupidly when two threads want to read from the same tty at
once. Not incredibly exciting, although I might some time soon be
persuaded to write a few words about the xterm -S option before I
forget how it works again.
Last October at ILC I foolishly volunteered, along with a bunch of#
Last October at ILC I foolishly volunteered, along with a bunch of
other community-minded people, to do something about the state of the ALU web
site. Since then, we've argued a little on the mailing list,
agreed a plan of action (management types may wish to add "going
forward" here), and then kinda sorta run out of momentum, as far as I
can tell. Ah well.
So last week I proposed a change in project scope -
The Official Site now becomes a site containing only Official
Information (ALU board members, mailing list archives, constitution,
minutes etc).
The CLiki site that we were using internally to prototype the new
site now becomes public. Because of this it won't contain the
Official Information (see above), but will feature (new updated
versions of) all of the incredibly useful but ever-so-slightly
outdated information on the rest of the old ALU site.
This suggestion seems so far to have had more positive feedback
(some) than negative (none, yet), which I am choosing to view as a
mandate from the ALU to go ahead.
ALU.CLiki.net is the actually-not-new
new site, which presently is both ugly and missing large chunks. But
that can be fixed. Go and fix it.
Expected-to-be-FA Q #1: how does this relate to the official CLiki?
CLiki is a place for "links to and resources for free software
implemented in Common Lisp and available on Unix-like systems": the
ALU site is for everything else. Clear? Some tolerable scheme for
inter-cliki linking is on my TODO list, along with everything else.
Some of the existing CLiki content (documents, tutorials, lisp
success stories, prospective de facto standard discussion, etc) is
expected to be moved across as time allows.
On the general subject of CLiki, the TUNES project are now using it, and
have hacked in some neat-looking features like a per-page edit
history. Hope to get those changes marged back into baseline soon.
Something I've been meaning to get around to for a long time: a#
Something I've been meaning to get around to for a long time: a
"contrib" module system for SBCL. This is for "code which does not
form part of SBCL itself, but which is sufficiently closely associated
with it that it would not be sensible to run it as a completely
separate project". Which is to say, code that gets its hands dirty
with SBCL extensions or internals. So far we have a BSD socket
library, a defsytsem, and (thanks to Kevin Rosenberg) an ACL-style toplevel, all of which can be
called up using REQUIRE. More info from contrib/STANDARDS in the SBCL source tree.
Now I'm trying to figure out what the status of CLX is these days.
Further to yesterday's portable CLX news, here's a unportable CLX for
SBCL users. Will be more use, right now, if you're tracking SBCL in
CVS, but there's a new release due at the end of the month, so it's
not long for the rest of the world to wait. It includes all the
patches that I posted to the portable CLX list yesterday
After uploading that, I spent a couple of hours fiddling with
Portable Hemlock. That runs in SBCL now too (patches are on their way
back to Gilbert).
Re: NYC LOCAL: Tuesday 11 February 2003 Lisp in New York City: Lispers gather to eat and drink#
Newsgroups: comp.lang.lisp
Subject: Re: NYC LOCAL: Tuesday 11 February 2003 Lisp in New York City: Lispers gather to eat and drink
References: <3E4689E1.708@nyc.rr.com> <3e47332d.120992159@netnews.attbi.com> <877kc7n90s.fsf@noetbook.telent.net> <877kc7blda.fsf@ix.netcom.com>
From: Daniel Barlow
Date: Tue, 11 Feb 2003 05:50:11 +0000
Message-ID: <87znp3l624.fsf@noetbook.telent.net>
User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.2 (i386-debian-linux-gnu)
Cancel-Lock: sha1:ncgGPtz9RG9Poh/XpT/kAVQnZik=
In-Reply-To: <877kc7blda.fsf@ix.netcom.com> (Gabe Garza's message of "Tue, 11 Feb 2003 02:23:58 GMT")
--text follows this line--
Gabe Garza writes:
>> CLiki is a Wiki1 - there is only one namespace. So, your name is
>> guaranteed unique. If you change the name, put a note on the old page
>> and I'll go round and garbage collect eventually.
>
> If the ALU web site--or part of it--is going to be a subset of CLiki,
> is CLiki's mission statement going to be changed to to accomodate
> commercial Lisp's and non-Unix Lisps's?
Good question. The term "CLiki" is overloaded, which is probably
going to get confusing
* CLiki as a piece of software (which you can download and,
eventually, after much cursing, install on your own servers) is
freely usable for any purpose
* The CLiki installation at www.cliki.net continues to be for "free
software implemented in Common Lisp and available on Unix-like
systems"
* The CLiki installation at alu.cliki.net, on the other hand, is
"produced by the ALU with and on behalf of the Common Lisp users and
vendors community". Yes, that includes commercial Lisps.
In short, they're two completely different sites. You can tell by the
ghastly background colour (replacement suggestions welcome, btw).
They don't don't share pages. Eventually I hope that the ALU one will
shift to the new ALU web server, when that's running. So in that
sense, no change in the direction of CLiki is required.
What I expect to see happen is that some of the information currently
on www.cliki.net will start moving to the ALU site. For example, many
of the documents referenced on www.cliki.net are non-free(sic) and
would be better off on the ALU site - likewise some of the news about
commercial or Windows implementations is not really relevant to
www.cliki.net either, and can migrate across. Some past attempts at
"community standards" have been made on www.cliki.net, which again
might be better off in a place where people don't feel they need to buy
into some ideology to participate.
I don't yet know exactly what this is going to do to www.cliki.net in
the long term[*]. It may live on independently, or it may fizzle, or
it may end up as a view onto the ALU site showing only the pages with
a tick against "bruce perens says you won't go to hell for reading
this". I have my own plans (which don't involve it dying off just
yet), but mostly it depends on where the contributors want to take it.
[*] OK, medium term. In the long term I'm really hoping that we won't
need to be using Unix any more.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
<lemonodor> thanks for not notifying me about my dns service expiring,#
<lemonodor> thanks for not notifying me about my dns service expiring,
dotster.
<lemonodor> so anyway, if lemonodor.com doesn't work there's
heavymeta.dyndns.org as a fallback
I'll write some more text that's not PRE-formatted soon, I promise.
In the meantime, this has been a public service announcement for
whatever portion of the Lisp screenshot pr0n audience also read my
SBCL ramblings. Spread the news.
In other news, I've been trying to page SBCL/threads back into my
brain. This morning in the shower I made the executive decision to
punt on all the POSIX job control stuff
It's complicated. I don't think anyone really ever intended that
multiple tasks produced with CLONE_VM should be in different process
groups.
It's messy to debug. ptrace() reparenting makes
strace(1) a lot less useful than it might be, and
fprintf(stderr,"...") is not so helpful either when it causes
the process in question to get SIGTTOU
It's probably just going to confuse the shell, which expects to
do this stuff itself.
So, decided to adopt a much easier approach towards getting
"non-foreground" threads to ignore ^C: they can ignore SIGINT. Does
anyone ever send SIGINT other than from the keyboard anyway? Please
tell me they don't.
It's looking marginally more believable now. I stripped all the unix
process group stuff I could find, which was wonderfully cathartic
At various important places when we are shortly about to do
input (e.g. printing the toplevel prompt, or entering the
debugger) we need to check that we own the stream we're going
to read from. fd-stream gets a new slot that contains a
sb-thread:mutex
MAYBE-WAIT-UNTIL-FOREGROUND-THREAD (bad name) does this for
the debugger. For the repl, at the moment we just hook it
with something unnamed. That needs fixing
Because it also needed doing, I also rewrote the mutex to use
an actual queue (and signals) instead of having each waiting
thread sleep a bit and retest and sleep a bit and ... (I
broke timeouts in the process. But that can be fixed, we just
need to pass timeout info down to sigtimedwait())
There's some fairly icky code duplication between C and Lisp,
and a fill-in-the-gaping-hole stub routine for spinlock
acquiring on the C side. The ideal here would be to teach
Lisp the necessary signal mask manipulation stuff and avoid
having to do C at all.
Still need to enable/disable SIGINT handlers when things go
into/out of foreground. But first I need some sleep
Of course, when one thread wants to talk to #<FILE-STREAM for#
Of course, when one thread wants to talk to #<FILE-STREAM for
"the terminal" {9004749}> and another wants to talk to
#<FILE-STREAM for "standard input" {9004539}>, how does
Lisp know they're actually the same file underneath it all? They even
have different descriptors.
We can use fstat and test device/inode for equality, I guess. It's
going to lose on sockets (not on Linux, by inspection, but e.g. OSX
has no inodes for sockets) and probably other stuff too. In the worst
case all we really need to support is ttys (and tell people to use
ptys if they want sane interactive behaviour) but it hurts to be so
ugly.
Pet peeve right now: packages (or distribution packaging policies,#
Thu Feb 20 17:31:12 2003
Topics:
Pet peeve right now: packages (or distribution packaging policies,
where applicable) that don't include the documentation. This is the
kind of thing you only really find the need for when away from the Net
(like now, on a coach). Surely Debian could include a
"documentation-package-for" as one of its package dependency types,
then I could put something in my apt configuration to say "always grab
the docs as well". I can see some kind of (steadily weakening)
argument for not making it the default, but for most people it's not
as if disk is a scarce commodity any longer.
Oh well. I spent rather a long time already today on recompiling
CLX - think my battery is about to go flat anyway. Now that still
is a scarce commodity.
So I think I can probably get this into SBCL 0.7.13 (which will be#
So I think I can probably get this into SBCL 0.7.13 (which will be
released on Sunday, all being well) by claiming it's a bugfix for
my very old
standaloneize-file hack.
* (require :sb-executable)
NIL
* (with-open-file (o "test1.lisp" :direction :output) (format o "(princ \"hello world\")"))
NIL
* (compile-file "test1")
; compiling file "/home/dan/test1.lisp" (written 21 FEB 2003 07:04:41 PM):
; compiling top level form:
; /home/dan/test1.fasl written
; compilation finished in 0:00:00
#P"/home/dan/test1.fasl"
NIL
NIL
* (sb-executable:make-executable "hello" *)
T
0
and then in the shell:
:; ./hello
hello world:;:; time ./hello
hello world
real 0m0.089s
user 0m0.060s
sys 0m0.020s
Yes, that bold green thing really is my shell prompt. The point is
that I can select commands by triple-clicking them and then paste them
into any other xterm.
Plan c (d? e? I may have lost count, actually) for stream locking in
threaded SBCL. Let's just have a lock, and keep it in a special
variable, and rebind the special variable when we open a listener on a
logically different device. Not only is this simpler, but it stands a
reasonable chance of working no matter what kind of stream it was -
ttyname() doesn't know that /dev/tty is /dev/pts/4
(for example), so it wasn't really ever going to work in any useful case.
For the record, I should add that in the following (chronologically#
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
