Older blog entries for crhodes (starting at number 64)

We did quite well for last year.

Yesterday, after meeting Oxford physics people during the day to discuss moving forward on our projects, I met Dan for dinner, and the 2003 SBCL (UK branch) AGM. Two is quorate, yes.

So, let's see:

  • Native threads: check.
  • Better, faster, more integrated CLOS: check.
  • GenGC on non-x86: partly done.
  • Contributed modules infrastructure: check.
  • More ports: check.
  • Linkage Tables: partly done.
  • State of the Implementation: oops.
  • XREF: sort of.
which isn't a bad strike rate considering the various other things that happen in people's lives. As for this year, well, 64-bit will probably happen; some form of Unicode support will probably happen; I will write up some of the stuff that's important; and I hope that we'll release that dream of software writers: version 1.0.

ANSI saith:

Using :absolute or :wild-inferiors immediately followed by :up or :back signals an error of type file-error.
As we have discovered, we need an Oracle (no relation) to interpret this mystifying pronouncement. What it would appear to mean is that at some point between creating a pathname with such a deviant directory structure and attempting to use it to discover something about the filesystem using standardized operators, a conforming Common Lisp should signal an error.

So far, so good. However, as the n+1th evidence of a severe mismatch between the Common Lisp "portable" pathname standard and any kind of Unix, it should be pointed out that the pathname named by "/../" (that is, in Lisp terms, (:absolute :up)) has well-defined semantics.

In practice, this means that I'm extremely reluctant to detect this error early (as might otherwise be the good citizen implementation); I don't want to throw an error from MAKE-PATHNAME or MERGE-PATHNAMES, because pathnames made this way could still be useful, albeit not through the standardized operators. In particular, feeding one of these deviant pathnames to SBCL's POSIX interface layer is a perfectly valid thing to do, and I think I want to support that.

So instead, we have to detect accesses to the filesystem of one of these pathnames. Which is, of course, harder, but fortunately for my sanity (working with CL pathnames sucks) not all that hard — it only touches three different places in the code rather than one. To whomever implemented the first version of CMUCL pathnames: thank you.

So today I decided that we probably ought to move forward rather than be stuck through forces beyond our control, so I kludged around the GC problems. SBCL CVS HEAD should now be roughly well-behaved, and certainly shouldn't be so laughably fragile as it has been for the last week.

This will unblock some of my current work, such as improving the performance of SBCL on various benchmarks, and a better interface for compile-time customization of diagnostic messages. I hope it also unblocks other people's stuff, but it's been quiet (though not silent, fortunately) recently.

There are a couple of other things I feel I should comment on. Firstly, Edi Weitz has ported ASDF-INSTALL (briefly: a lisp tool for downloading "third-party" libraries) to a bunch of other (i.e. not SBCL) Lisps. As a lisp programmer, this has to be a good thing, because it means the constant whiners about lisp being hard get one more rebuttal... of course, I'm slightly disappointed that one of SBCL's killer advantages is no longer so clear.

The other thing is the notion that there is no "good" free Lisp (by which here I mean Common Lisp). I'm not sure, but I think perceptions are skewed, maybe by something like the Moon on a Stick phenomenon: people seem to accept problems in software they've paid for much more readily than in things they haven't — or, rather, I think they make an implicit calculation based on cost of the value of incremental improvements.

Maybe I should just sell SBCL for $200 a throw, or somesuch. It would be nice, if buyers could be found...

10 Jan 2004 (updated 12 Jan 2004 at 17:38 UTC) »

First, I started doing this diary weblog thing, and it was good. Nobody much noticed what I was doing, but it warmed my ego, and gave me a place to note little things that I discovered. Then I noticed that it seemed to be taking off; what was more surprising to me at the time was that they seemed to be being read.

Now, I'm actively being sought out, along with a number of people (well, online presences) with aligned interests. My wisdom is now being disseminated to a wider world out there. I'd better be more careful what I say.

(The irony of a diary entry free of Lisp content, discussing a Lisp diary aggregator, is not lost on me).

8 Jan 2004 (updated 8 Jan 2004 at 13:31 UTC) »

Aargh.

I spend time fighting SourceForge's Compile Farm (actually, I have few complaints about this aspect of their service; I think I'm getting more than I pay for) to build two different versions of SBCL for MacOS X, so that I can investigate the problems of RUN-PROGRAM on the PPC.

However, I can't reproduce the problem. At all. No matter how hard I try, all my RUN-PROGRAMs work fine.

<chandler> Krystof: is the machine you're trying to duplicate it on a dual-processor machine?
<chandler> Krystof: if so, you won't be able to

So. How annoying. SourceForge's Compile Farm machines are clearly too good...

Alright, alright, an update. Not that this will make people complaining that this previously good "lisp rss feed" has dried up, because...

... I am currently finding out what real people do in real jobs. In one of these amusing setups where I get responsibility but no tangible benefits (i.e. scads of $$$) I am working in Derivative Research for a French subsidiary of a major British(ish) Bank. It's kind of interesting; I've learnt a lot about approximating integrals. Living in France has its compensations, too.

While we're at it, I have to revise for my viva. Seriously. And the schedule isn't ideal; I finish my stage on Friday 12th of December; my viva is tentatively scheduled for Saturday 13th of December in a different country. Lucky Eurostar is now really fast.

All this means that lisp work requiring more than superficial thought is going to proceed slowly for at least the next few weeks. Simple things that I'm doing: a better INHIBIT-WARNINGS, better bignum printing, and applying other peoples' patches.

Thesis minus 0 days.

Good thing it's ready, eh? Actually, it went to the binders on Wednesday, so it was with a certain amount of relief that I closed down that emacs instance on Thursday morning and was not told that I had unsaved changes in any buffers, and would I like to save the changes?

Now, all I need to do is find something to do with the rest of my life. Oh yes, and contend with Saruman the viva voce examination.

* most-positive-fixnum

1152921504606846975

Well, that one was satisfyingly straightforward. Known suboptimalities:

* (1+ most-positive-fixnum)

-100000000000000000*,,,*')*1207959552 * (compile nil '(lambda () 1))

INTERNAL ERROR * (gc) fatal error encountered in SBCL pid 30918: GC invariant lost, file "gc-common.c", line 277

I think it's safe to say that it's not quite working yet.

The lisp system I work on, SBCL, sometimes shows its age. Although SBCL per se has only been around for five years or so, it is an evolution from CMUCL, itself an offshoot from Spice Lisp, which was started in the early 1980s, borrowing from the heritage of 1970s lisps.

Given this history, it's not entirely surprising that the codebase (200kloc of lisp, plus about 10kloc of C and assembler) isn't 64-bit aware. However, today's applications are definitely nudging the space requirements; Lisp is apparently "big in bioinformatics", and fairly obviously there they'll want to be dealing with large databases.

So, a couple of months ago, Dan and I had a quick hack at porting our existing alpha backend (which was originally crafted as a 32-bit application) to be fully 64-bit. We got far enough to be executing plenty of lisp code, but not quite up to the point that the REPL was functional.

Time passed. Various bugs in the alpha backend were fixed, and so (why not?) I tried again yesterday, merging the previous branch with CVS HEAD. After conflict resolution, the addition of the necessary specialized array types, and three or more bugfixes (plus commenting out of things that break weirdly):

/entering TOPLEVEL-REPL
/about to set up restarts in TOPLEVEL-REPL
/entering REPL
* (* 2 3)

6 * most-positive-fixnum

11520460975

Waitaminute! That doesn't look nicely big enough for a 64-bit lisp. Well, not quite everything is working, despite getting to the REPL; here, the printing routines are slightly broken. The most positive fixnum is meant to be (1- (ash 1 60)) (leaving four bits for tagging objects); that number is 1152921504606846975. So, compare and contrast

1152921504606846975
1152xxxx0460xxxx975

Other things that appear not to work include the compiler itself; clearly, the utility of a compiler-only implementation of 64-bit lisp without a functioning compiler might be viewed as "limited". Since I'm technically unemployed at this point, I'm taking offers of funding...

Thesis minus 8 days.

I tell a lie: it wasn't that bad after all.

Thesis minus 23 days.

55 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!