Add a restart that allows using SYSTEM-APROPOS for cases when a user has attempted to load a system using the name of a project instead of the system name i.e "commonqt". For example:

debugger invoked on a QUICKLISP-CLIENT::SYSTEM-NOT-FOUND:
  System "commonqt" not found

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: Search for systems similar to "commonqt" instead.
  1: [ABORT] Give up on "commonqt"
  2:         Exit debugger, returning to top level.

Specs:

• Ubuntu 10.04 Lucid Lynx
• CLISP 2.44.1 (Ubuntu package version 1:2.44.1-4.1ubuntu3)
• Quicklisp beta

Trace:

$ sudo apt-get install clisp
$ wget http://beta.quicklisp.org/quicklisp.lisp
$ clisp
$ (load "quicklisp")
$ (quicklisp-quickstart:install)
...
; Upgrading ASDF to version 2.014.6

** - Continuable Error
DEFPACKAGE QL-CLISP: There is no symbol EXT::PROBE-PATHNAME .
If you continue (by typing 'continue'): This symbol will be created.
The following restarts are also available:
TRY-RECOMPILING :R1     Try recompiling impl
RETRY          :R2      Retry compiling component ("quicklisp" "impl").
ACCEPT         :R3      Continue, treating compiling component ("quicklisp" "impl") as having been successful.
SKIP           :R4      skip (LET # #)
STOP           :R5      stop loading file /home/andrew/quicklisp/setup.lisp
ABORT          :R6      Abort main loop
Break 1 QL-IMPL[3]>

Attempting to continue by entering :r3 results in creating more errors.

Nu is an Objective-C variant of Common Lisp.
http://programming.nu/

Does the quicklisp-client phone home to report library downloads? Privacy issues aside, it would be cool to see who's using my code.

Note, this issue can not be tested in current version of the quicklisp-client because of the issue #48 (i.e. due to the issue #48 ql:quickload for such an asdf system fails always, not only the first time).

How it was few days ago:

1. Precondition: iterate is not installed
2. (ql:quickload :iterate-tests)

To load "iterate-tests":
Install 1 Quicklisp release:

iterate

335,496 bytes in 1.68 seconds (195.48KB/sec)
; Loading "iterate-tests"
Unhandled ERROR is signaled: Component "iterate-tests" not found

cl-test-grid status for ITERATE: FAIL

I.e. quicklisp downloads and install the system :iterated. But fails to load iterate-tests.

1. Preforming (ql:quickload :iterate-tests) when iterate is already installed succeeds.

On a fresh install, I get this:

* (ql:quickload "cxml")

; Fetching #<URL "http://beta.quicklisp.org/dist/quicklisp/2011-12-03/systems.txt">
; 113.23KB
==================================================
115,947 bytes in 0.06 seconds (1952.23KB/sec)
; Fetching #<URL "http://beta.quicklisp.org/dist/quicklisp/2011-12-03/releases.txt">
; 157.61KB
==================================================
161,394 bytes in 0.05 seconds (3216.56KB/sec)

debugger invoked on a QUICKLISP-CLIENT::SYSTEM-NOT-FOUND in thread #<THREAD
                                 "initial thread" RUNNING

                                 {10029210A3}>:
  System "cxml-dom" not found

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Give up on "cxml"
  1:         Exit debugger, returning to top level.

((LABELS QUICKLISP-CLIENT::RECURSE) "cxml-dom")
0] 0  

It would be good to support local dists via file:/// URLs.

Per Ala'a Mohammad Alawi:

Hi Zach

quicklisp implementation of open-connection for LispWorks uses
open-tcp-stream. which will fail silently (returning nil) in case of
unkwon-host (a site was down). adding :errorp to the call will help
the user by show a readable error message. I've tried sbcl and ccl
where both the error was more indicative than complaining about a
stream being a 'nil' (as was the case with Lispworks)

Verify that the :errorp option works on each version of LispWorks and update the code to use it.

http://groups.google.com/group/quicklisp/browse_thread/thread/c65289a51d6a8951

I'm trying to make quicklisp work with my pre-existing install (which works for 
sbcl, ccl, etc). I get an error when trying to load the client                  
(version 2011040600).                                                           

This is a newly compiled ECL 11.1.1 (no special configure flags) on Mac OS X    
(Xcode 4).                                                                      

...                                                                             
;;; Loading "/Users/elliott/quicklisp/asdf.fas"                                 
ASDF could not load sockets because Error while trying to load definition for   
system sockets from pathname /opt/local/lib/ecl-11.1.1/sockets.asd: No          
applicable method for SOURCE-FILE-TYPE with arguments of types                  
 COMPILED-FILE                                                                  
 PREBUILT-SYSTEM.                                                               

The problem goes away if asdf-ecl.lisp is loaded at the same time Quicklisp's asdf.lisp is loaded.

(ql:quickload "cl-unification") fails on SBCL win32 because the release package includes a file named "Thumbs.db:encryptable", and the colon ':' is an illegal character in NTFS file names (it denotes an ADS).

Here is how I worked around it:

https://github.com/jawhite/quicklisp-client/tree/win32-clean-path

Tried with sbcl, ccl, allegro and clisp. All went well but clisp. Here's the error

*** - EXT:PROBE-PATHNAME: File #P"C:" does not exist
The following restarts are available:
SKIP :R1 skip (LET # #)
RETRY :R2 retry (LET # #)
STOP :R3 stop loading file C:\home\jonas\quicklisp\setup.lisp
ABORT :R4 Abort main loop

Slime with Allegro CL on Windows needs a special program to run - just pointing inferior-lisp-program to the exe file doesn't cut it. It would be nice to have a way to display configuration hints / a link to further documentation after the user installs slime-quicklisp-helper at least.

This could be useful for other software, too.

Packages often have really long directory names. For instance, on my system cl-opengl is installed at C:\Users\bvanevery\quicklisp\dists\quicklisp\software\cl-opengl-20110320-git . Quicklisp knows where these packages are and could allow users to conveniently navigate to their toplevel directories. I'd suggest that the following be accepted:

ql:cd "package-name"
ql:cd package-name

Make it easy for people to run a standard set of tasks and report their success or failure. Thanks to Ala'a Mohammad for the idea.

It seems to show backwards upgrades and removals that aren't removals. Why?

http://groups.google.com/group/quicklisp/browse_thread/thread/b8de661ccb029e37

ECL 11.1.1, Windows, MSVC compiler.
quicklisp/version.txt: 2012010700

Test case:

1. Install fresh quicklisp.
2. (ql:quickload :any-library) produces error:

In function COERCE, the value of variable is
#\H
which is not of expected type (INTEGER -128 127)
Available restarts:

1. (USE-VALUE) Supply a new value of type (INTEGER -128 127).
2. (ABORT) Give up on "babel"
3. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SI:BYTECODES. [Evaluation of: (QUICKLISP-CLIENT:QUICKLOAD :BABEL)] In:
#.

1. The library is not downloaded. The directory quicklisp\dists\quicklisp\
   contains only distinfo.txt and enabled.txt.
2. Running another lisp and performing ql:quickload for that library
   downloads and installs it.
3. Now ql:quickload in ECL for that library works. But for any other library
   it again produces the #\H error.

Recently, I tried to install utils-tk on ECL using quicklisp and that resulted in a stack overflow.

Turns out that line 9 in utils-kt.asd ( #+(or allegro lispworks cmu mcl clisp cormanlisp sbcl scl) ) excludes installation on ECL and consequently quicklisp goes into infinite recursion.

f1b0c7a introduced a bug where a downcased keyword might be returned as an initarg inappropriately.

ql:add-to-init-file fails with CLisp 2.48, built from source, on Ubuntu10.04. I call it, and the file is unchanged afterwards. I thought it was just that you weren't calling finish-output on the stream (I've had that issue with CLisp before), but I tried fixing it and couldn't get it to work.

If HTTP stalls and someone interrupts it, make it easy to retry just that HTTP operation.

This can make a huge difference as it avoids creating dists over and over again from the filesystem. iolib is more than 3x faster loading. hunchentoot too.

With the fresh quicklisp client (quicklisp:quickload :cl-base64-tests) fails, but (quicklisp:quickload :cl-base64) works.

Few days ago it worked (although with another less critical problem, which I'll report later).

The same story with :iterate - (quicklisp:quickload :iterate-tests) fails while (quicklisp:quickload :iterate) works.

What is common between these libraries is that the -tests system is defined the same .asd file as the main system
(i.g. :cl-base64-tests is defined in :cl-base64.asd).

Under both SBCL 1.0.50.46 and CCL 1.7-r14925M under Linux .

Culprit is (directory "*/.asd" #p"~/quicklisp/local-projects") in (defun local-project-system-files), which ignores any symlinked directories.

That will help in the short term until I work out all the logic of which file to update. If someone knows best, let them specify.

Currently Quicklisp comes with ASDF 2.014.6, but requires only 2.011.

This leads to a double-standard of minimum ASDF version. Probably Quicklisp should require 2.014.6, or downgrade the included ASDF to 2.011.

(Currently eg. gsll doesn't work on Quicklisp if the host system has 2.011, as it depends on :defsystem-depends-on fixes that have come in since then.)

I'm using WinXP SP2 + CCL 1.6. I don't know what version of Quicklisp I'm using.

My user profiles live under the default "C:\Documents and Settings". The CCL installation is on my E: drive. I run CCL via the command line, and the current directory at that time is within the E: drive.

I found the following file after running ql:update-all-dists, mistakenly written to the E: drive rather than the C: drive:

E:\Documents and Settings\Walter\quicklisp\tmp\distinfo-update\releases.txt

There are no other files in that directory structure.

I haven't looked at Quicklisp's code, so I don't know whether it's writing to the E: drive incorrectly because the CCL installation is there, or because the current directory at the time of running ql:u-a-d is there.

Right now it says "No update available for version". It should say something like "You are already using the latest version, version" or something clearer.

Add a function to emit a file that has a list of available system files, in preference order. This can be fed to buildapp to make it easier to use Quicklisp and Buildapp together.

I have setted "proxy-url" variable to "" (because i have no proxy at home) and sbcl started to crash with "getattrerror -2 (unkown hostname)".

Resolved with "rm ~/quicklisp/config/proxy-url.txt"

Please, make possible unsetting config variables.

Currently, quickload does an exact match for the system name. It would be nice if it did a match (possibly inexact) on both the system name as well as the tar-file name. In case of multiple choices, it could offer a choice to the user of which system he wants to load.

For example, although the 0MQ interface is named (and referred to as) "cl-zmq", the actual system name is "zeromq" and (ql:quickload "cl-zmq") fails to load anything. The tar file is named "cl-zmq-2010..." and quickload would succeed (possibly with a confirmation dialog) if it tried to match on the tar file name.

As another example, if a substring match was implemented (when an exact match fails), doing (ql:quickload "json") would offer the choice to load one of "cl-json", "cl-json.test" and "st-json".

The above should not be too difficult to implement and would provide benefit to most users especially in cases where multiple packages/libraries exist to do the same thing (XML parsers, PostgreSQL interfaces, etc.)

RFC 2616 says that servers should not sent a content-length header if there is also a content-transfer-encoding header. Quicklisp assumes that any response with a content-length header is not chunked. However, the RFC goes on to say that clients that receive both a content-transfer-encoding header and a content-length header should ignore the latter. Quicklisp fails in this regard, and it causes problems for some users.

Fix up save-response so it checks for chunkiness first.

For non-interactive use of add-to-init file, provide the ability to pass :prompt nil.

It's now in git://common-lisp.net/projects/linedit/linedit.git

ClozureCL's namestring syntax for pathnames with embedded dots includes an escape character. This will cause problems if a project is installed with ClozureCL but then later run with SBCL (I think).

Create a test case to demonstrate this, then add a new implementation utility function that uses CCL:NATIVE-TRANSLATED-NAME on CCL and SB-EXT:NATIVE-NAMESTRING underneath.

I view quicklisp as a subscription sort of thing, but will have to donate when I remember rather than just signing up and going. I am less reliable than clockwork.

MacPorts CLISP was giving me trouble, so I tried Fink CLISP instead.

Specs:

CLISP 2.43
Fink 0.29.19
Mac OS X 10.6.6
MacBook Pro 5, 1

Trace (during loading of Quicklisp):

** - Continuable Error
DEFPACKAGE QL-CLISP: There is no symbol EXT::RENAME-DIRECTORY .
If you continue (by typing 'continue'): This symbol will be created.
The following restarts are also available:
TRY-RECOMPILING :R1     Try recompiling impl
RETRY          :R2      Retry compiling component ("quicklisp" "impl").
ACCEPT         :R3      Continue, treating compiling component ("quicklisp" "impl") as having been successful.
SKIP           :R4      skip (LET # #)
STOP           :R5      stop loading file /Users/andrew/quicklisp/setup.lisp
SKIP           :R6      skip (LET # #)
STOP           :R7      stop loading file /Users/andrew/.clisprc.lisp
ABORT          :R8      ABORT
ABORT          :R9      ABORT
Break 1 QL-IMPL[3]>

Updating a dist may download and install replacement versions of existing projects. The old versions are no longer used, but they are not deleted either.

Make some process to clean up unused/ignored project directories.

; Loading "hunchentoot"
[package usocket]..
Read error between positions 195 and 295 in /Users/Mac/quicklisp/dists/quicklisp/software/usocket-0.5.4/vendor/ccl-send.lisp.

Error: Foreign function not found: X86-DARWIN64::|send|
While executing: LOAD-EXTERNAL-FUNCTION, in process Listener(6).

Quicklisp installs an asdf system definition search function that will return the pathname in which a secondary system is defined even if the name of that secondary system doesn't match the pathname, e.g. (find-asdf-system-file "foo-test") can return "/path/to/foo.asd". That causes a problem with how asdf 2.015 works.

http://groups.google.com/group/quicklisp/browse_frm/thread/add0b53e9f6d190a has Nikodemus's report and analysis.

It should work to add a new function around find-asdf-system-file that only returns the result if the system name and the pathname name match.

From Marko Kocic:

I had the following problem today. I tried to update-all-dist and
download got stuck after some packages were installed, so I
interrupted the process and restarted slime session.

After that update-all-dists said system is up to date although it
didn't finish it first time.
After that I got errors when trying to quickload package that failed
to update, and had it working by manually deleting all package files
from quickload folder and quickloading it again.

I used sbcl and ccl on windows, if that is relevant.

Would be nice to leave some traces of what upgrade operations have been performed and when, with the full output.

This would facilitate debugging some issues such as the inaccurate pre-upgrade report regarding what libraries are new/removed/etc...

I just installed quicklisp 11-15. I am using sbcl 1.0.50 on OpenBSD. I run (ql:quickload "clsql-sqlite3") which proceeds to uffi and clsql and a few other things, before:

[package ansi-loop]...............................
[package clsql-uffi]
debugger invoked on a ASDF:OPERATION-ERROR:
  Error while invoking #<COMPILE-OP (:VERBOSE NIL) {41EF80B1}> on
  #<CLSQL-UFFI-SOURCE-FILE "clsql-uffi" "uffi" "clsql_uffi">

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY ] Retry
              compiling #<CLSQL-UFFI-SOURCE-FILE "clsql-uffi" "uffi" "clsql_uffi">.
  1: [ACCEPT] Continue, treating
              compiling #<CLSQL-UFFI-SOURCE-FILE "clsql-uffi" "uffi" "clsql_uffi">
              as having been successful.
  2: [ABORT ] Give up on "clsql-sqlite3"
  3:          Exit debugger, returning to top level.

((SB-PCL::FAST-METHOD ASDF:PERFORM
  (ASDF:COMPILE-OP CLSQL-UFFI-SYSTEM::CLSQL-UFFI-SOURCE-FILE))
 #<unavailable argument>
 #<unavailable argument>
 #<ASDF:COMPILE-OP (:VERBOSE NIL) {41EF80B1}>
 #<CLSQL-UFFI-SYSTEM::CLSQL-UFFI-SOURCE-FILE "clsql-uffi" "uffi" "clsql_uffi">)
0]

This is unfortunately rather opaque to me. If the nature of the problem is in the error message, I wasn't able to pick it out.

Summary: Ideally all output could have a semicolon before. For example,

CL-USER> (ql:quickload :foo)
To load "foo":
  Load 1 ASDF system:
    foo
; Loading "foo"
[package quux].................................
[package foo]..

would be

CL-USER> (ql:quickload :foo)
; To load "foo":
;   Load 1 ASDF system:
;     foo
; Loading "foo"
; [package quux].................................
; [package foo]..

Rationale: When using Emacs and SLIME, when paired with something like the auto-complete package for Emacs, strings such as quux]................................. are registered as possible, complete-able symbols. While this is not strictly a bug in Quicklisp or such Emacs packages, it's nice to have a differentiation between output which is data/code, and output which is simply messaging the user.

Proposed Change: Have all output, including the progress dots, be prepended with at least one semicolon.

Opened an ECL bug here:

https://sourceforge.net/tracker/?func=detail&aid=3462618&group_id=30035&atid=398053

http://groups.google.com/group/quicklisp/browse_thread/thread/1d6587af398d7440

antifuchs sent me a patch for this and other issues for mlisp; I have to find it and apply it.

In theory, Quicklisp can be ported to a new implementation of CL without modifying any of the Quicklisp sources by adding the appropriate methods to a handful of generic functions. However, not all of these generic functions are named by exported symbols, and not all of them have docstrings. Make sure that all of them are exported and documented.

This loses drive letters in Windows. Use the bootstrap trick of constructing a file-less pathname instead.

https://groups.google.com/d/topic/quicklisp/xJXEHwThAs4/discussion has an example of this problem. I've seen it before, too, but haven't been able to figure out the context in which it happens.

If ~/quicklisp/asdf.fas exists and is not a CLISP fasl file, CLISP 2.49 will fail to load it, and also fail to compile a new FASL, because of a bug in CLISP that is now fixed in CLISP CVS.

http://groups.google.com/group/quicklisp/browse_thread/thread/1aa2a38bc4721d1f

Quicklisp could work around the issue by segregating its ASDF-related FASLs.