A machine I used to use to host some web services, bots, and repositories became no longer accessible from the Internet, as a result of which I've had to move what I was serving from it; some to switchb.org, some to personal machines.

I took the opportunity to clean things up a bit, as a result of which I now have better backups, more polished services, and know a little bit more about configuring Apache — though not as much as I perhaps should.

  • My Subversion repositories are now served over HTTP, and therefore browsable; and they are now backed up daily (using svnsync triggered by a cron job) to my laptop, and thence to all its backups.

    (I wasted several minutes on remembering that cron will ignore the last line of a crontab file if it doesn't end with a newline; after listening to me grumbling about this, someone made a suggestion to end the file with a comment, so that the last line is harmless whether ignored or not, and also reminds one of the issue.)

    If you have a working copy of one of my repositories (E-on-CL, E-on-JavaScript, MudWalker, Den, etc.), here's a guide to the changed URLs.

  • My other Tahoe-LAFS volunteer grid storage node is now residing on a machine on my home LAN.

  • Finally, some simple data-querying web services I wrote for Waterpoint's word games have now been moved to switchb.org; I also took the time to prettify their URLs (no cgi-bin or .cgi) and write documentation.

I haven't yet gotten to working on the bots, darcs repositories, or miscellaneous other stuff I had there.

(Pondering moving my blog over to switchb.org as well so as to not have ads, especially now that I found I can still have LJ-friends by way of OpenID. (Hm, but reading friends-locked posts over RSS might not work since there's no username+password for LJ to accept. Anyone have experience with that situation?))

Apache configuration questions:

  1. If I have multiple variants of a document (e.g. foo.html foo.pdf foo.txt) handled by MultiViews, so the canonical URL of the document is extensionless (“foo”), how do I properly control the default variant to serve in the event that the client does not express a preference via the Accept header? (Without doing so, I found that it would serve the .txt version, whereas I would prefer the HTML.) All that I found that worked was to create a type map file named “foo” with quality values, and force it to be interpreted as a type map using <FilesMatch>. This seems kludgy to me.
  2. What is the right way to serve CGIs, not in a designated cgi-bin directory, and without any .cgi extension in the URL? I initially tried to apply mod_rewrite, but I couldn't get it to work such that /foo internally contacted foo.cgi whereas /foo.cgi redirected to /foo. I resorted to another <FilesMatch> explicitly listing the name of each CGI and doing SetHandler cgi-script.
  3. What is the right way to handle “testing” vs. “deployment” configurations, where the relevant Directory, Location, etc may be different depending on which server or subdirectory the site is set up on? I see that one may use environment variables — should I just set up variables containing the path prefixes for the particular host before including the generic configuration file?

Common Lisp provides compile-file whose purposes is to convert a CL source file into an (implementation-defined) format which usually has precompiled code and is designed for faster loading into a lisp system.

compile-file takes the pathname of a textual lisp source file. But what if you want to compile some Lisp code that's not in a file already, perhaps because you translated/compiled it from some not-amenable-to-the-Lisp-reader input syntax, or because it contains unREADable literals? You can use a "universal Lisp file", which I know two ways to create (use whichever you find cleaner):

(cl:in-package :mypackage)
(cl:in-package :mypackage)
(macrolet ((it () *program*))

Suppose this is in "universal.lisp". Then to use it:

(defvar *program*)

(defun compile-to-file (form output-file)
  (let ((*program* form))
    (compile-file #p"universal.lisp"
                  :output-file output-file)))

This is just a minimal example; you'll also want to appropriately handle the return value from compile-file, provide an appropriate pathname to the universal file, etc. For example, here's an excerpt of the relevant code from E-on-CL, where I have used this technique to compile non-CL sources (emakers) into fasls:

(defparameter +the-asdf-system+ (asdf:find-system :e-on-cl))
(defvar *efasl-program*)
(defvar *efasl-result*)
(defun compile-e-to-file (expr output-file fqn-prefix opt-scope)
  (let* (...
           `(setf *efasl-result*
                  (lambda (...) ...))))
    (multiple-value-bind (truename warnings-p failure-p)
        (compile-file (merge-pathnames
                        (asdf:component-pathname +the-asdf-system+))
                      :output-file output-file
                      :verbose nil
                      :print nil)
      (declare (ignore truename warnings-p))
      (assert (not failure-p) () "Compilation for ~A failed." output-file))))

(defun load-compiled-e (file env)
  (let ((*efasl-result* nil)
    (load file :verbose nil :print nil)
    (funcall *efasl-result* env)))

Note that the pathname is computed relative to the ASDF system containing the universal file; also note the use of a variable *efasl-result* to simulate a "return value" from the compiled file, and the use of a lambda to provide a nonempty lexical environment, both of which are features not directly provided by the CL compiled file facility.


Saturday, October 9th, 2004 12:22

Implementing the stream-IO interfaces for E. It's mostly complete, but there's an executing-blocking-code-in-the-wrong-thread bug which Shouldn't Be Happening. I'm inclined to think it's a bug in E, except that the code explicitly does things which break E's reference discipline and I'm not sure that it isn't due to that.

An RDF parsing/processing library in E, which was the subject of the previous post. Stalled because I found the design didn't allow for provenance/contexts in merged graphs.

Recently discovered: Lion Kimbro's OneBigSoup project (weblog, wiki). Lots of ideas here.

Goal, roughly: More interconnection between existing Internet-based social tools.

Pieces I'm finding interesting: LocalNames, UniversalLineInterface

I've been helping Lion with ULI tools (DICT protocol gateway, support for ULI over HTTP GET when appropriate), and talking about capability security principles.

Though I can't imagine any specific use for it yet, I wrote a ULI client on Waterpoint - $local.uli.

The current implementation of E is absurdly slow. It's an interpreter, mostly unoptimized, implemented in Java.

My project: E implemented in Common Lisp—translating E to CL code and implementing ELib with CLOS.

Many Common Lisp implementations compile source to machine code at runtime, and a sufficiently clever translation of E code should benefit from this.

Status: The Kernel-E to CL translator is mostly complete. I have a crude Updoc implementation in CL, which I use for testing the other parts. ELib is only as complete as I've needed to test the translator.

Micro-status: Trying to figure out why var x := 2; x := x returns 0 instead of 2, and yet sets the variable correctly for later code.