diary at Telent Netowrks

Last October at ILC I foolishly volunteered, along with a bunch of#

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 -

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#

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.

Cool stuff:#

Sun, 09 Feb 2003 05:01:35 +0000

Cool stuff:

Time I was in bed#

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).

Newsgroups: comp.lang.lisp#

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:  <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,#

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
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.

CLIKI IS NOT A LIVEJOURNAL SUBSTITUTE#

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

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#

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

Of course, when one thread wants to talk to #<FILE-STREAM for#

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.

Pet peeve right now: packages (or distribution packaging policies,#

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.

So I think I can probably get this into SBCL 0.7.13 (which will be#

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.

; /home/dan/test1.fasl written ; compilation finished in 0:00:00

  1. P"/home/dan/test1.fasl" NIL NIL
  2. (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#

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.

Social#

Mon, 24 Feb 2003 18:15:09 +0000

Social Problems Of Lisp:

<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

For the record, I should add that in the following (chronologically#

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.

Fun with threads#

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.

  1. 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.

  2. 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.

  3. 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 annoys me -#

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.

⟪Jan 2003 Mar 2003⟫