Mon, 03 Feb 2003 22:42:27 +0000
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.
Last October at ILC I foolishly volunteered, along with a bunch of
Fri, 07 Feb 2003 19:04:18 +0000
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.
Something I've been meaning to get around to for a long time: a
Sun, 09 Feb 2003 05:01:35 +0000
Cool stuff:
Cool stuff:
Mon, 10 Feb 2003 03:26:23 +0000
Time I was in bed.
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).
Time I was in bed
Tue, 11 Feb 2003 05:50:58 +0000
Newsgroups: comp.lang.lisp
Subject: Re: NYC LOCAL: Tuesday 11 February 2003 Lisp in New York City: Lispers gather to eat and drink
References: <b254kl$6on$1@panix2.panix.com> <3E4689E1.708@nyc.rr.com> <m3vfztdx96.fsf@localhost.localdomain> <3e47332d.120992159@netnews.attbi.com> <zKycnb95RN1JwNqjXTWc-w@speakeasy.net> <877kc7n90s.fsf@noetbook.telent.net> <877kc7blda.fsf@ix.netcom.com>
From: Daniel Barlow <dan@telent.net>
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 <g_garza@ix.netcom.com> 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
Re: NYC LOCAL: Tuesday 11 February 2003 Lisp in New York City: Lispers gather to eat and drink
Wed, 12 Feb 2003 21:13:26 +0000
<lemonodor> thanks for not notifying me about my dns service expiring,
dotster.
<lemonodor> so anyway, if lemonodor.com doesn't work there's
<a href="http://heavymeta.dyndns.org/">heavymeta.dyndns.org</a> 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.
<lemonodor> thanks for not notifying me about my dns service expiring,
Tue, 18 Feb 2003 18:18:49 +0000
CLIKI IS NOT A LIVEJOURNAL SUBSTITUTE
Ahem. I feel better for having said that, though.
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.
CLIKI IS NOT A LIVEJOURNAL SUBSTITUTE
Wed, 19 Feb 2003 06:31:42 +0000
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
It's looking marginally more believable now
Thu, 20 Feb 2003 02:15:11 +0000
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.
Of course, when one thread wants to talk to #<FILE-STREAM for
Thu, 20 Feb 2003 17:31:12 +0000
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.
Pet peeve right now: packages (or distribution packaging policies,
Fri, 21 Feb 2003 19:05:39 +0000
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.
So I think I can probably get this into SBCL 0.7.13 (which will be
Fri, 21 Feb 2003 19:39:06 +0000
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.
Plan c (d
Mon, 24 Feb 2003 18:15:09 +0000
<bziki__> why am i complaning ??? i'll tell you why. because the
+attitud of the room sucks. you guys are really not trying to help, you
+are just try to educate user i how to learn. and that is not part of
+this idea. the idea behind these chat rooms is whenever someone has
+already looked in the books/docs/mans and did not find what he/she
+needed - or - he/she are in serious need for immdiate help.
“serious need for immdiate help”, indeed
Social
Thu, 27 Feb 2003 00:18:40 +0000
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.
For the record, I should add that in the following (chronologically
Fri, 28 Feb 2003 03:17:54 +0000
Fun with threads. No, really. No sarcasm.
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.
Fun with threads
Fri, 28 Feb 2003 04:13:28 +0000
This annoys me -
68.74.156.60 – - [28/Feb/2003:02:08:44 +0000] “POST /edit/db-sockets HTTP/1.1” 200 164 “-” “websphinx.Crawler” www.cliki.net “-” 0 seconds
68.74.156.60 – - [28/Feb/2003:02:09:21 +0000] “POST /edit/Graphics%20Toolkit HTTP/1.1” 200 178 “-” “websphinx.Crawler” www.cliki.net “-” 1 seconds
68.74.156.60 – - [28/Feb/2003:02:09:48 +0000] “POST /edit/CORBA HTTP/1.1” 200 154 “-” “websphinx.Crawler” www.cliki.net “-” 1 seconds
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
<meta NAME=“ROBOTS” CONTENT=“noindex,nofollow”></meta>
in the head element, so robots really have no business being there
anyway.
This annoys me -
Tue, 04 Mar 2003 00:34:08 +0000
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 horrible
horrible locking macros.
Some aspects of CLX are deeply tedious to experiment with, because
