Download external packages in Common Lisp using SLIME on Debian

Question

I am using SBCL 1.0.56 on Debian compression, with cl-swank / slime 1: 20120420-2 (Debian version number). These are all current versions unstable.

I'm having trouble downloading third-party CL packages. The documentation for using CL on Debian (and, indeed, the more general CL using Linux documentation) is sketchy, inconsistent, and deprecated, so I will summarize what I know. That is where I am.

Debian installs binary packages (e.g. cl-split-sequence) in /usr/share/common-lisp/source . In the case of a split sequence, this is /usr/share/common-lisp/source/cl-split-sequence .

The .asd file (here /usr/share/common-lisp/source/cl-split-sequence/split-sequence.asd ), which, as I understand it, gives instructions for implementing the CL about version and dependencies, looks like

 ;;; -*- Lisp -*- mode (defpackage #:split-sequence-system (:use #:cl #:asdf)) (in-package :split-sequence-system) (defsystem :split-sequence :version "20011114.1" :components ((:file "split-sequence"))) 

Now, when you run slime, enter the following two lines in the REPL works without problems

 (require :split-sequence) (split-sequence:SPLIT-SEQUENCE #\, "foo,bar") 

(require :split-sequence) calls (I think) a built-in copy of ASDF inside SBCL, which apparently looks like split-sequence.asd . This is probably SBCL specific, see General Lisp in the Debian Chapter 3 -Libraries Guide . It is worth noting that this page, which is as useful and detailed as everything I have seen, often refers to CLC (Common Lisp Controller), but it seems that Debian is moving away from this. See the Redesign of the Common Lisp Controller , which I don’t quite understand. Anyway, none of the documented commands for using CLC work for me. However, CLC is still available on Debian. In addition, the user mailing list is dead - see Users Clc Archives

On the first call (require :split-sequence) it compiles, and (on my system, possibly Debian-specific) the resulting fasl placed in

~/.cache/common-lisp/sbcl-1.0.56.0.debian-linux-x86/usr/share/common-lisp/source/cl-split-sequence/split-sequence.fasl

those. the file is placed under the cache in the file system, which mirrors the location of the source source. The obvious question is: how does the system know where to look for a package? This is one thing I'm not sure about. It looks like the search paths should be given in /etc/common-lisp/source-registry.conf.d , which is part of Debian's ASDF, but the closest is 01-common-lisp-controller.conf , which is just

 (:directory #p"/usr/share/common-lisp/systems/") 

It may be difficult somewhere, but I would like to know.

In any case, once this ASDF file is in the cache, it does not compile again, but the REPL does not see it after running the slime, unless require again.

Now if i put the lines

 (require :split-sequence) (split-sequence:SPLIT-SEQUENCE #\, "foo,bar") 

In the file, say seq.lisp , and load it into REPL with Cc Ck, I get an error and trace starting from

 The name "SPLIT-SEQUENCE" does not designate any package. [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR] 

therefore, I came to the conclusion that the package was not loaded correctly. I tried options like

 (asdf:oos 'asdf:load-op :split-sequence) 

and

 (asdf:load-system :split-sequence) 

but not bones. Oddly enough, suppose we have a line

 (require :split-sequence) 

in the file - type require.lisp for clarity. Then loading require.lisp does not give an error and then it types

 (split-sequence:SPLIT-SEQUENCE #\, "foo,bar") 

works on REPL! However, without loading require.lisp , typing the previous line does not work in REPL.

So in conclusion, how can a package be successfully loaded into a script? I am also interested in the problem mentioned above about how ASDF finds the location /usr/share/common-lisp/source/ , but this is more of a side issue.

Answer 1

Cc Ck compiles the source file, and then downloads the compiled file.

A Lisp source file contains definitions and calls. The file compiler looks at the file and creates code for it. But he does not fulfill it.

If your file contains a REQUIRE call, it is not executed at compile time. It will be executed if you later download the compiled file. If the next Lisp form in the file then uses some package that will be available after calling REQUIRE , it simply does not exist at compile time, since REQUIRE has not been executed yet - thus, an error occurred while reading while compiling.

Basically there are two solutions:

• Perform all necessary REQUIRE operations before compiling a specific file using the necessary functions.
• run the REQUIRE command at compile time. That EVAL-WHEN :COMPILE-TOPLEVEL tells compilation to execute subforms at compile time.

#+:sbcl(foo) means that (foo) is read only when :SBCL is a character in the CL:*FEATURES* list. It is used so that the compiler sees this code only when it is SBCL.

Compiling Common Lisp code requires more caution because:

• You can execute Lisp code during file compilation and thus change the behavior of the file compiler.

• packages (which are namespaces for characters) that are used in the source code should be known to the reader of the file compiler.

Answer 2

Found the next post, Zach Beane Blog - Creating a small general Lisp project that linked to http://common-lisp.net/~loliveira/ediware/ediware.lisp

Copy the code at the top of this file. So running Cc Ck in slime in this file loads the split-sequence and runs the int (split-sequence:SPLIT-SEQUENCE #\, "foo,bar")) code int (split-sequence:SPLIT-SEQUENCE #\, "foo,bar"))

 #+:sbcl (eval-when (:compile-toplevel :load-toplevel :execute) (require :asdf)) (eval-when (:compile-toplevel :load-toplevel :execute) (asdf:oos 'asdf:load-op :split-sequence)) (defpackage #:seq (:use #:cl #:split-sequence)) (in-package #:seq) (print (split-sequence:SPLIT-SEQUENCE #\, "foo,bar")) 

However, I do not know what these magic spells do. Would anyone like to explain maybe in a different answer? I will answer this because it is the answer to the question, but it is not complete, because I do not understand why it works. I will gladly accept the explanation of this script.