Take the 2-minute tour ×

I'm trying to load hunchentoot via quicklisp in slime, and getting the following error:

READ error during COMPILE-FILE:

  :ASCII stream decoding error on
    for "file [redacted]/dists/quicklisp/software/rfc2388-20120107-http/rfc2388.asd"

    the octet sequence #(196) cannot be decoded.

  (in form starting at line: 29, column: 29,
  file-position: 1615)

I get this when trying to run either:

(ql:quickload "hunchentoot")

Or simply:

(ql:quickload "rfc2388")

It seems that others are getting this too. I found one hint at a possible answer, saying:

The system file is encoded as UTF-8. 
I'm not sure how to configure things so that SBCL on Windows starts with 
UTF-8 as its default encoding for loading sources, but that's what you 
need to do. 

From there, I've tried (based on e.g. [this] adding the following to my emacs config:

(set-language-environment "UTF-8")
(setq slime-lisp-implementations
      '((sbcl ("/opt/local/bin/sbcl") :coding-system utf-8-unix)))

But... I still get the same error, even after completely re-starting emacs, to make sure I had a fresh Slime that was reading the above config.

So, what am I missing, and/or otherwise how can I get this to load?

Thanks in advance! (More thanks to come for a successful answer. ;)

share|improve this question
try this: (setq slime-net-coding-system 'utf-8-unix) –  Vsevolod Dyomkin Jun 4 '12 at 5:30
@VsevolodDyomkin: You'll note that I've tried that (see last line of the last block of text) already... Is there something I need to do to make sbcl itself see this? That variable seems (if I'm reading the documentation correctly) to control network connections (I presume with swank?), but what controls what SBCL is launched with? –  lindes Jun 5 '12 at 14:51
add comment

4 Answers

up vote 1 down vote accepted

Have you checked your locale settings? Emacs configuration only tells it what coding systems to set for communication between SLIME and SWANK.

You can check for locale settings with /usr/bin/locale, for example:

navi ~ » locale
navi ~ »

Mine is setup for UTF-8 everywhere, as you can see, except for displaying 'C' messages.

share|improve this answer
Adding (setenv "LANG" "en_US.UTF-8") to my emacs init file (and re-starting, as a lazy way of re-starting slime/sbcl) did indeed solve the problem. Thanks! (This answer didn't exactly give that, but it pointed me in the direction I needed, and that's appreciated.) –  lindes Jun 5 '12 at 15:08
add comment

Try this:

change into the .../quicklisp/dists/quicklisp/software/rfc2388* directory and load rfc2388.asd into a text editor. Move down to the :author parameter of the defsystem form. Replace the author's name by the name given at the top of the file. Store file using ASCII encoding.

Of course, when a new version of the library is published, the workaround gets lost. Or else store the modified project in local-projects.

share|improve this answer
I'm much happier finding a solution that doesn't require me to change the representation of someone's name, nor manage patches to things. I'm sure this would have worked, but setting LANG strikes me as a (mostly, at least) happier solution. I think my days of just assuming LANG=C are probably nearing an end. :) –  lindes Jun 8 '12 at 22:26
add comment

With the original UTF-8 encoding still in effect, the DEBUGGER should present an INPUT-REPLACEMENT option to replace offending input characters by a replacement string. Choose that option, type "?" or "x" or any string you like at the prompt and then ENTER. The load then completes. Of course, that is not something you would like to do every time.

So the best idea is probably to send an email to the author and ask to provide an ascii version for quicklisp.

share|improve this answer
Hmm, I don't recall having seen that option in the debugger... The restarts that were available to me were: 0: [ABORT] Abort loading file "[...]/rfc2388.asd". 1: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system rfc2388 after reinitializing the source-registry. 2: [ABORT] Give up on "rfc2388" 3: [RETRY] Retry SLIME REPL evaluation request. 4: [*ABORT] Return to SLIME's top level. 5: [ABORT] Abort thread (#<THREAD "repl-thread" RUNNING {10049C8083}>) -- what were you expecting to see there? –  lindes Jun 8 '12 at 22:29
add comment

There should be a .cache directory in your HOME that contains all the fasl files. Sometimes removing those old fasl files seems to work for me when something goes wrong with compilation.

share|improve this answer
I renamed them away, and it doesn't appear to have made a difference. I'm pretty sure there's some sort of setting to get the encoding system right that's required, and this would only be a cache of something compiled -- I can't compile the file, though. I could imagine that something previously compiled might interfere, but... it doesn't seem to change anything. –  lindes Jun 5 '12 at 14:46
add comment

Your Answer


