My setup is:
Windows Vista
clisp 2.49
I run clisp and load asdf without any problems.
I push a directory pathname into asdf:*central-registry* and copy a shortcut of cl-ppcre.asd into the directory. Then I try to load-op it with (asdf:oos 'asdf:load-op 'cl-ppcre) and i get a response that "component 'cl-ppcre' not found". Any suggestions? Asdf is version 2.010.
Found the solution:
http://bc.tech.coop/blog/041113.html
In a few words, the problem is that ASDF doesn't like Windows' shortcuts, it wants soft links and the two are not the same. The link describes 2-3 ways of dealing with this.
ASDF is meant to support shortcuts. If the support is buggy, please contribute a fix.
That said, with ASDF2, the recommended way of configuring ASDF is to put your code in one of the standard locations, and/or to add entries to the source-registry.
Related
On Debian, I had a bunch of cruft installed in /usr/lib/sbcl/site-systems that wouldn't load because the FASLs didn't match the version of SBCL that is actually installed.
For some reason, none of these files were associated with any Debian package (this is an old computer that has been running the same Debian install for over a decade– it's on Debian Sid).
I deleted the bad systems one at a time, and for most of them, Quicklisp did the right thing and downloaded the Quicklisp version. Sometimes, ASDF would insist that the system should exist at its previous path, but restarting SBCL got past that problem.
But for one system, ASDF has persistently cached the location of its .asd file as being in the /usr/lib/sbcl/site-systems/ directory. Loading this system is impossible because ASDF will not look anywhere else, even after restarting SBCL.
I tried looking in all the paths specified in various config files under /etc/common-lisp. None of those files contain a reference to the now-missing library.
I've resorted to doing a grep -rli across all the files under /usr. I don't expect that to complete in less than a day, and it might not find anything, in which case I'll be forced to grep the whole hard drive, which might take a whole week. Hopefully, the cache isn't compressed, because then I'll never find it.
Does anyone happen to know how ASDF persists the paths of files?
After a lot of excruciating debugging, I discovered that the files in /usr/lib/sbcl/site-systems/ actually do exist. They're broken symlinks.
The files I deleted were in the similar-looking path /usr/lib/sbcl/site/, to which the symlinks pointed.
Removing the symlinks fixed all the loading errors.
A couple of ideas about troubleshooting Quicklisp, particularly if your getting bizarre behavior.:
If you use Quicklisp for any length of time you'll probably eventually use local packages, found here by default, ~/quicklisp/local-projects It's valid to symlink you're projects into that directory. If you ever rename one of your projects, of course, don't forget to create a new symlink and delete the old one
Likewise, if you rename a local project, also delete the system index which Quicklisp will then recreate the next time it runs: ~/quicklisp/local-projects/system-index.txt Doesn't hurt to delete it from time to time just to keep your system fresh.
your *.fasl files can become stale too, deleting the system cache forces quicklisp to recompile everything. On an Ubuntu system running SBCL that would mean deleting the contents of:
rm -rf ~/.cache/common-lisp
Try updating the Quicklisp client
(ql:update-client)
Potentially deleting and reinstalling Quicklisp itself at ~/quicklisp can be necessary. (It's possible to inadvertently edit source files when your debugging and using Swanks lookup definition feature, breaking installed packages that used to work. Not that I would ever have done something as careless as that.)
Also, don't forget that ASDF decends into directories looking for *.asd files. If you have a stray one that's improperly structured that can cause havoc on you build system. (See my comment above about registering local projects to Quicklisp)
Finally, don't forget to check your lisp init file, e.g. .sbclrc for any debugging or quick and dirty hacks you might have left there and forgot about.
These are all things that have worked for me at one time or another, hopefully I'm not perpetuating legend and cant on things have have long since been fixed!
I have updated quicklisp to the lates version
CL-USER> (ql:update-all-dists)
1 dist to check.
You already have the latest version of "quicklisp": 2017-06-30.
NIL
But this did not update the dependencies to the latest version, ex. Hunchentoot webserver is version 1.2.35, but I need 1.2.37 because of a bugfix.
/home/pio/quicklisp/dists/quicklisp/software/hunchentoot-1.2.35/hunchentoot.asd
How can I update the Hunchentoot to the latest release (https://github.com/edicl/hunchentoot/releases/tag/v1.2.37) with quicklisp?
Ql:quickload will first ask ASDF for locally available systems, which happens in a defined order.
I usually put all Lisp libraries that I want to be found under ~/common-lisp/ which is a standard place ASDF looks into, so it just works.
If you have some other directories, you can make these directories known to ASDF. You can for example use the file ~/.config/common-lisp/source-registry.conf:
(:source-registry
(:tree (:home "repos"))
:inherit-configuration)
This will make ASDF aware of any .asd files under the ~/repos/ directory.
You can then use asdf:load-system or ql:quickload to load such systems (the latter will also resolve and download missing dependencies).
If quicklisp has already installed a system in a different version and ASDF happens to find that version first, you might need to ql:uninstall it beforehand.
What's your general approach when quickload fails? I guess I'd like to know the line that provoked the problem, but all I'm given is a backtrace with a reference to a bytecompiled-function. How should I proceed to determine which package, file and form causes the problem?
Update
My environment is ECL in Emacs. The backtrace is provided by the SLIME debugger.
Quicklisp uses ASDF (which usually comes preinstalled), you can try to use it directly to get more detailed error. See manual.
Put (or symlink) your system in one of the standard locations, as subdirectory for example "foo" under
~/common-lisp/ or
~/.local/share/common-lisp/source/.
Try to load it
(asdf:load-system :foo)
I meet the following error. Any clue?
CL-USER> (require "asdf")
NIL
But the page https://common-lisp.net/project/asdf/asdf.html#Loading-ASDF said
The recommended way to load ASDF is via:
(require "asdf")
All actively maintained Lisp implementations now include a copy of ASDF 3 that you can load this way using Common Lisp’s require function.1
The specification for PROVIDE, REQUIRE says that the return value of require is implementation-dependant, but that it should signal an error if a module fails to be loaded. In your case, the NIL return value is not an error, but an indication that the operation succeeded.
Try (asdf:make "optima"), for example. Your environment should recognize the ASDF:MAKE symbol, but it might fail to load the :optima system. See Quicklisp to download and install systems.
By the way, you rarely need to require asdf (you don't need to do it in SBCL nor in CCL, at least). To be sure, you might want to restart your Lisp environment and see if the ASDF package exists.
I'm using quicklisp as the package management tool for SBCL.
However, sometimes I found it's not very convenient to install a package to the HOME directory of current user by ql:quickload. (For example, if I use (ql:quickload "xmls") to install xmls, other users can't use it.)
What's worse, I'd like to run the lisp code as a script. So when I use the package installed by quicklisp, I need to add the absolute path of that package uncomfortably, such as:
#!/usr/bin/sbcl --script
(require 'xmls "..../quicklisp/dists/quicklisp/software/xmls-1.4/xmls")
If I use (require 'xmls), the compiler will not work because it cannot find that package if I use the --script options.
Does anyone knows how to solve the problem so that I can use --script and require(no need to add absolute path) at the same time？
I don't know of a good solution to this problem. The solution I use is to not write scripts with Common Lisp; I usually write applications that I use interactively from CL sessions. When I do want to run things from the command-line, I use buildapp for it, and use ql:write-asdf-manifest-file to create a file to pass to --manifest-file for buildapp.
I sometimes wish there was a better solution, but it'll probably take some work by someone (hopefully not me).
I just do sudo sbcl and this way it'll be installed for every user on my PC - it's OK, because it's my home PC, so there's no danger.
One thing I could think of is maybe symlinking the directory where ql installs stuff to something that is easier to access, like $HOME/packages -> .../quicklisp/software or something?