hexstream/clhs

This installation helper makes it even easier to install a copy of the CLHS locally. (ql:quickload "clhs").

I am a top Common Lisp Open Source contributor. See my extensive contributions at HexstreamSoft.

clhs's Issues

on loading clhs-use-local.el, debugger entered due to inability to make symlinks

Installation does not work when using with quicklisp on windows 10

Break 4 [6]> (clhs:print-emacs-setup-form)


[ Quicklisp directory: "C:\home\quicklisp\" (exists)
  If the above location is not correct, do:
  (setf clhs:*quicklisp-directory* "\\\\path\\\\to\\\\quicklisp\\\\") ]

(clhs-use-local.el was found in your quicklisp directory.
Moreover, its version matches the one bundled with this CLHS ASDF wrapper.
You may proceed with step 2 of 2 below.)
Make Emacs evaluate this form to browse the CLHS locally:
(load "C:\\\\home\\\\quicklisp\\\\clhs-use-local.el" t)

Debugger entered--Lisp error: (file-error "Making symbolic link" "Operation not permitted" "dists/quicklisp/software/clhs-0.6.3/HyperSpec-7-0/HyperSpec/" "c:/home/quicklisp/HyperSpec")
  make-symbolic-link("dists/quicklisp/software/clhs-0.6.3/HyperSpec-7-0/HyperSpec/" "c:/home/quicklisp/HyperSpec" t)
  (let ((absolute (quicklisp-clhs-hyperspec-location))) (make-symbolic-link (if relativep (file-relative-name absolute quicklisp-clhs-base) absolute) (quicklisp-clhs-symlink-location) t))
  quicklisp-clhs-setup-symlink(t)
  (if (quicklisp-clhs-inhibit-symlink-p) nil (quicklisp-clhs-setup-symlink (if (quicklisp-clhs-inhibit-symlink-relative-p) nil t)))
  (quicklisp-clhs-setup-hyperspec-root (if (quicklisp-clhs-inhibit-symlink-p) nil (quicklisp-clhs-setup-symlink (if (quicklisp-clhs-inhibit-symlink-relative-p) nil t))))
  eval-buffer(#<buffer  *load*> nil "c:/home/quicklisp/clhs-use-local.el" nil t)  ; Reading at buffer position 2599
  load-with-code-conversion("c:/home/quicklisp/clhs-use-local.el" "c:/home/quicklisp/clhs-use-local.el" t nil)
  load("C:\\home\\quicklisp\\clhs-use-local.el" t)
  eval((load "C:\\home\\quicklisp\\clhs-use-local.el" t) nil)
  eval-expression((load "C:\\home\\quicklisp\\clhs-use-local.el" t) nil)
  funcall-interactively(eval-expression (load "C:\\home\\quicklisp\\clhs-use-local.el" t) nil)
  call-interactively(eval-expression record nil)
  command-execute(eval-expression record)
  execute-extended-command(nil "eval-expression" "eval-expression")
  funcall-interactively(execute-extended-command nil "eval-expression" "eval-expression")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

[I edited your comment to use triple-backtick code block quoting instead of single-backtick quoting. Much better...]

clhs-use-local.el strongly assumes that a quicklisp version of the CLHS wrapper is currently installed

@saraf Thank you very much for your detailed report via email! I am flabbergasted!

(Note, it is generally far preferable to discuss issues in public rather than via email, for a great variety of great reasons, but right now I don't really feel like spending the time and energy to expound on that at length, although it's certainly an important topic.)

Somewhat tragically, I already knew what the problem was after reading the first 2 lines of your email:

I followed the following steps:
(ql:uninstall clhs) to remove the existing 0.6.3

[Impressive detailed report]

Uh, oops! I did not expect you to do that, although it was a completely logical thing to do. I did not even know that quicklisp supported such an easy uninstall functionality, I seem to remember that in the past it did not. Now obviously, it does.

So, the problem is that, per the topic, clhs-use-local.el strongly assumes that a quicklisp version of the CLHS wrapper is currently installed. To summarize, clhs-use-local.el uses some quicklisp-provided information as part of its computations to locate where the clhs wrapper is installed within the quicklisp directory (completely ignoring local-projects). That information is used to compute where the HyperSpec symlink should point. But due to very poor error handling, if no quicklisp-provided clhs wrapper version is currently installed, then that part of the symlink will be "left blank" instead of signaling an error, leaving the symlink essentially pointing to nowhere. That's what you were seeing.

---

Most people will only ever use quicklisp-provided clhs wrapper instances, so they never would come across this problem, I believe. For this reason, I'm classifying this as a low priority bug. I don't have a timeline for when I might fix this, if ever, it depends on a variety of factors such as how often it trips people up and how busy I am and how I feel, etc.

(I will still leave this issue open as a continuous acknowledgement and reminder of the issue, until it is finally fixed. It can also help prevent other people from falling into the same trap.)

---

In your situation, the easy workaround, for now, is to just reinstall the quicklisp-provided clhs wrapper (0.6.3) and then proceed to also install the 0.6.4-rc1 version. When all is said and done, you'll have installed the new clhs-use-local.el (version 0.7), and after running it your HyperSpec symlink will happily point to the HyperSpec in your old (0.6.3) clhs wrapper and everything should work perfectly. :)

Right now, the easiest way to force quicklisp to download and install the clhs wrapper,
despite another version of the wrapper already being installed in a location asdf can find such as within the quicklisp/local-projects directory, is to run the following in the Slime REPL:

(progn
  (ql:use-only-quicklisp-systems)
  (ql:quickload "clhs"))

Now that the quicklisp-provided clhs wrapper is (re)installed, restart your Common Lisp implementation by invoking ,restart-inferior-lisp in the Slime REPL. (Unfortunately, there is currently no other easy way to undo the effects of (ql:use-only-quicklisp-systems), nor of temporarily enacting its effects with a macro possibly called with-quicklisp-systems-only.)

After that, invoke (ql:quickload "clhs") or (asdf:load-system "clhs") to load the 0.6.4-rc1 release candidate and proceed with installation. Let me know how that goes!

Make local CLHS URLs shorter

The current setup produces URLs such as this one, which I find pretty ugly and objectionable:

file:///home/hexstream/quicklisp/dists/quicklisp/software/clhs-20120208-http/HyperSpec-7-0/HyperSpec/Body/t_symbol.htm

I'd like something like this much better:

file:///home/hexstream/quicklisp/clhs/HyperSpec-7-0/HyperSpec/Body/t_symbol.htm

(Cutting out redundant "HyperSpec" bits would be nice, but I at least can't do that without some legal disclaimers of some kind, as the redundant HyperSpec-7-0 directory exists for legal reasons in the first place...)

The obvious solution would be to use a symlink, but this is not necessarily portable and potentially fraught with peril (I think?)...

I'm not sure how best to go about this exactly, but something should be done.

Copy/paste mistake in clhs-use-local.el (quicklisp-slime-helper-file-contents)

quicklisp-slime-helper-file-contents should have been quicklisp-clhs-file-contents (which is defined in the file).

I didn't detect this problem despite testing because I always loaded quicklisp-slime-helper, predictably. There is no actual dependency to quicklisp-slime-helper. I'll make a 0.4 release very soon to fix this.

I'll need to implement the clhs-use-local.el version detection, so I'll conveniently fix the magic as discussed in:
#3

Make CLHS relocatable

I'll need to give some thought to this. Meanwhile, creating an Issue is not a bad start. :)

(06:47:03 PM) Xach: Hexstream: i tried out clhs this weekend when traveling with spotty internet access
(06:47:29 PM) Hexstream: Xach: Did you have a pleasing experience?
(06:47:55 PM) Xach: Mostly. The direct reference to the software location troubled me a bit. It might be better to indirect through the installed/projects/clhs.txt file.
(06:48:02 PM) Xach: A la quicklisp-slime-helper.
(06:48:14 PM) Xach: There was a code suggestion I had but it has temporarily slipped my mind.
[...](06:54:54 PM) Xach: Hexstream: if you update clhs, the path changes from .../software/clhs-201202xx-git/ to .../clhs-201203xx-git/ and your emacs setup breaks
(06:55:33 PM) Xach: Hexstream: but ~/quicklisp/dist/quicklisp/installed/releases/clhs.txt will always point to the latest installed version
(06:55:35 PM) Hexstream: Xach: Oh. That's an issue.
(06:56:39 PM) Xach: Hexstream: quicklisp-slime-helper puts a file in ~/quicklisp/slime-helper.el that peeks slime's file
(06:59:01 PM) Hexstream: Xach: Alright, uh, I can't seem to think straight. I'll need some time to digest this.
(07:00:22 PM) Hexstream: My first intuition is that Quicklisp could somehow help with this class of problems with a simple API, but I have no idea what it should be right now.
(07:07:31 PM) Xach: Hexstream: could be

Persist user-configured *quicklisp-directory* location

Right now the CL part of the CLHS wrapper will always fall back to the default quicklisp directory location when loaded for the first time in a CL image, so those with a "non-standard" location will need to (setf clhs:*quicklisp-directory* "/path/to/quicklisp") each time they use that part (which is presumably not often, only for installation/reinstallation/upgrade).

Maybe I should provide a way to persist this user preference...

Install use-local

It would be nice if clhs:print-emacs-setup-form and the README mentioned clhs:install-clhs-use-local.

common-lisp-hyperspec-root

i am trying to use hyperspec locally (with emacs 24.4.1 eww), remote browsing works fine but locally i get file/80 service not known. with my eww setup.

workaround:
initially common-lisp-hyperspec-root starts with file:/path rather than file:///path and i am guessing eww only accepts the latter, when i use the latter it works fine.

thanks.

Invalid byte code in Emacs 24.1.50

The full error is:

hyperspec-lookup: Invalid byte code in /usr/share/emacs/24.1.50/lisp/emacs-lisp/cl-extra.elc

I installed from quicklisp on Ubuntu 11.10 using a recently compiled SBCL 1.0.56 and am obviously running Emacs 24.1.50

I've also moved the ~/quicklisp path to ~/Libraries/quicklisp if that helps any.

User-configurable quicklisp directory location

Right now the clhs wrapper completely assumes that the quicklisp directory is in the user's home directory.

This should be user-configurable.