I discovered a way to crash Slime by compiling a simple sexp containing a string. Here are the conditions:
1. Connect to a running SBCL via swank (M-x slime-connect). 2. Cut and paste the sexp below containing the smiley-face into a lisp file. 3. Compile the fragment.
That's it. When I do this the inferior Lisp process is terminated "by remote peer".
(let ((dangerous-string "This is a smiley-face: ☺")) (print "Important safety tip: don't do this."))
I normally only work with UTF-8 characters, and my ignorance of handling other character sets is probably the culprit here.
What should I do if I want to enable slime to work with strings like this?
Regards, Jeff Cunningham
On Fri, Oct 28, 2011 at 03:15:17PM -0700, Jeffrey Cunningham wrote:
I discovered a way to crash Slime by compiling a simple sexp containing a string. Here are the conditions:
- Connect to a running SBCL via swank (M-x slime-connect).
- Cut and paste the sexp below containing the smiley-face into a lisp
file. 3. Compile the fragment.
That's it. When I do this the inferior Lisp process is terminated "by remote peer".
(let ((dangerous-string "This is a smiley-face: ☺")) (print "Important safety tip: don't do this."))
I normally only work with UTF-8 characters, and my ignorance of handling other character sets is probably the culprit here.
Hmm... I know this isn't very helpful, but it works OK for me using SBCL 1.0.51. And the latest version of slime. What versions using? I didn't do anything specific to make this work. I just compiled SBCL as per instructions and installed slime using quicklisp.
I'm also not sure what you mean by saying ☺ isn't a utf-8 character.
Regards
Bernard
"Jeffrey Cunningham" jeffrey@jkcunningham.com writes:
That's it. When I do this the inferior Lisp process is terminated "by remote peer".
(let ((dangerous-string "This is a smiley-face: ☺")) (print "Important safety tip: don't do this."))
You need M-x customize-variable <RET> slime-net-coding-system <RET>: set slime-net-coding-system to something like utf-8-unix.
P.S.
What's described here is not a rare problem, and it would be great to do something about it within SLIME. Negotiating the best coding system with SWANK shouldn't be hard to implement: it's possible to change coding system of a process in emacs after it's started.
On Sat, Oct 29, 2011 at 03:48:22AM +0400, Anton Kovalenko wrote:
You need M-x customize-variable <RET> slime-net-coding-system <RET>: set slime-net-coding-system to something like utf-8-unix.
Jeffrey had said he had been using utf8 coded character sets so I kind of assumed he knew this and the problem was somewhere else. Mabe I shouldn't jump too quickly to conclusions!
Bernard.
On Fri, 28 Oct 2011 17:14:16 -0700, Bernard Hurley bernard@marcade.biz wrote:
On Sat, Oct 29, 2011 at 03:48:22AM +0400, Anton Kovalenko wrote:
You need M-x customize-variable <RET> slime-net-coding-system <RET>: set slime-net-coding-system to something like utf-8-unix.
Jeffrey had said he had been using utf8 coded character sets so I kind of assumed he knew this and the problem was somewhere else. Mabe I shouldn't jump too quickly to conclusions!
Bernard.
I know I'm running UTF-8 - My .emacs sets it that way on startup:
(setq slime-net-coding-system 'utf-8-unix)
Perhaps I worded the situation incorrectly. What I'm trying to say is that I can repeatedly crash Slime when I start it this way:
M-x slime-connect <RET> Host: 127.0.0.1 <RET> Port: 4005 <RET>
where it is connecting to a running Hunchentoot webserver complied with swank listening on that port. If I then cut the following from this email:
(print (char-code "☺"))
, paste it into the REPL:
CL-USER> (print (char-code "☺")) <RET>
it kills Slime instantly. But not the webserver. I can reconnect by repeating the slime-connect sequence.
Jeff
Try this, Bernard:
Start SBCL in a terminal - not through Slime.
(require 'swank) (swank:create-server :port 4007 :style :spawn :dont-close t)
Now start emacs, and connect to the running Lisp through swank on 4005:
M-x slime-connect 127.0.0.1 4007
Cut the following from this email and paste it into Slime's REPL and evaluate it:
(elt "☺" 0)
When I do that Slime dies and the Lisp says:
;; swank:close-connection: end of file on #<SB-IMPL::STRING-INPUT-STREAM {1002FD93B1}>
Actually, it frequently dies before I can even evaluate it. Just having that character in the buffer kills the connection.
Jeff
Jeffrey Cunningham wrote:
Try this, Bernard:
Start SBCL in a terminal - not through Slime.
(require 'swank) (swank:create-server :port 4007 :style :spawn :dont-close t)
Now start emacs, and connect to the running Lisp through swank on 4005:
M-x slime-connect 127.0.0.1 4007
Cut the following from this email and paste it into Slime's REPL and evaluate it:
(elt "?" 0)
When I do that Slime dies and the Lisp says:
;; swank:close-connection: end of file on #<SB-IMPL::STRING-INPUT-STREAM {1002FD93B1}>
Actually, it frequently dies before I can even evaluate it. Just having that character in the buffer kills the connection.
An appropriate :coding-system when starting the server would probably help. E.g.: (swank:create-server :port 4007 :style :spawn :dont-close t :coding-system "utf-8-unix")
On Fri, 28 Oct 2011 23:09:43 -0700, Pixel // pinterface pix@kepibu.org wrote:
Actually, it frequently dies before I can even evaluate it. Just having that character in the buffer kills the connection.
An appropriate :coding-system when starting the server would probably help. E.g.: (swank:create-server :port 4007 :style :spawn :dont-close t :coding-system "utf-8-unix")
That does it. Thank you!
Jeff
An appropriate :coding-system when starting the server would probably help. E.g.: (swank:create-server :port 4007 :style :spawn :dont-close t :coding-system "utf-8-unix")
using utf-8 as default in 2011 would have spared numerous people a whole lot of time.
instead we keep on repeating such threads to... why exactly?
my take on this is sitting in our branch for ages:
http://dwim.hu/gitweb/gitweb.cgi?p=slime;a=commit;h=851c7f1778e2927e4c4a8b7a...
or if meanwhile the link gets broken by rebasing, then look up this patch:
More sensible defaults:
- slime-setup loads slime-fancy if called without arguments - use utf-8 encoding by default
* Attila Lendvai [2011-10-30 17:31] writes:
An appropriate :coding-system when starting the server would probably help. E.g.: (swank:create-server :port 4007 :style :spawn :dont-close t :coding-system "utf-8-unix")
using utf-8 as default in 2011 would have spared numerous people a whole lot of time.
Care to prove your claim? I mean with numbers and measurements from repeatable experiments.
Helmut
On Sun, 30 Oct 2011 11:56:20 -0700, Helmut Eller heller@common-lisp.net wrote:
- Attila Lendvai [2011-10-30 17:31] writes:
An appropriate :coding-system when starting the server would probably help. E.g.: (swank:create-server :port 4007 :style :spawn :dont-close t :coding-system "utf-8-unix")
using utf-8 as default in 2011 would have spared numerous people a whole lot of time.
Care to prove your claim? I mean with numbers and measurements from repeatable experiments.
I can't speak for anyone else, but it gets my vote.
Is there a downside?
Quoth "Jeffrey Cunningham" jeffrey@jkcunningham.com:
I can't speak for anyone else, but it gets my vote.
+1
Sebastian
as person, who uses Russian & German (& of course English), I vote for this - for many people (at least from Russian-speaking community) who're starting to use SLIME, this is almost standard problem, that you need to explicitly setup encoding...
Maybe one of solutions could be take encoding from LANG/LC_ environment variables? I did this for swank-clojure...
On Sun, Oct 30, 2011 at 9:58 PM, Sebastian Tennant sebyte@smolny.plus.com wrote:
Quoth "Jeffrey Cunningham" jeffrey@jkcunningham.com:
I can't speak for anyone else, but it gets my vote.
+1
Alex Ott alexott@gmail.com writes:
as person, who uses Russian & German (& of course English), I vote for this - for many people (at least from Russian-speaking community) who're starting to use SLIME, this is almost standard problem, that you need to explicitly setup encoding...
Maybe one of solutions could be take encoding from LANG/LC_ environment variables? I did this for swank-clojure...
UTF-8 default is probably good nowadays, because it takes time and concentration to dig out a non-unicode CL, and any person doing it is probably aware of possible troubles with external formats and encodings. Digging out a non-unicode emacs and running SLIME on it requires even more time and concentration, hopefully.
Adding LANG and LC_* variables to the picture here is an extremely bad idea, not only because they can't be interpreted correctly without assistance of foreign libraries (nl_langinfo should be used instead when it's available). Locale encoding should be used by almost all CL _implementations_ (I make an obvious exception for ABCL here) to set up their default external form. For SLIME, we just want a widest common encoding supported by emacs _and_ CL, and it doesn't matter if the rest of the system uses another one.
More robust solution would be an auto-negotiation thing I mentioned here earlier. We can simplify it by expecting utf8-aware emacs _unconditionally_, so SWANK server would _always_ use utf-8 when the implementation supports it. Emacs can set process-coding-system directly when the process is already running, and it can be done upon request from SWANK. It could be useful if there are indeed non-unicode, _latin1-only_ Lisps out there.
Making swank resynchronize instead of disconnecting in such cases could be beneficial as well, though it's not that easy. Some of unicode-aware lisps, for example, might hate code points outside of basic multilingual plane.
* Anton Kovalenko [2011-10-30 22:09] writes:
Alex Ott alexott@gmail.com writes:
as person, who uses Russian & German (& of course English), I vote for this - for many people (at least from Russian-speaking community) who're starting to use SLIME, this is almost standard problem, that you need to explicitly setup encoding...
Maybe one of solutions could be take encoding from LANG/LC_ environment variables? I did this for swank-clojure...
UTF-8 default is probably good nowadays, because it takes time and concentration to dig out a non-unicode CL, and any person doing it is probably aware of possible troubles with external formats and encodings. Digging out a non-unicode emacs and running SLIME on it requires even more time and concentration, hopefully.
Adding LANG and LC_* variables to the picture here is an extremely bad idea, not only because they can't be interpreted correctly without assistance of foreign libraries (nl_langinfo should be used instead when it's available). Locale encoding should be used by almost all CL _implementations_ (I make an obvious exception for ABCL here) to set up their default external form. For SLIME, we just want a widest common encoding supported by emacs _and_ CL, and it doesn't matter if the rest of the system uses another one.
More robust solution would be an auto-negotiation thing I mentioned here earlier. We can simplify it by expecting utf8-aware emacs _unconditionally_, so SWANK server would _always_ use utf-8 when the implementation supports it.
Well, you also need to enforce that enable-multibyte-characters is true on the Emacs side otherwise SLIME tries to insert multibyte strings into unibyte buffers. Anyway, enable-multibyte-characters is nil my configuration.
Helmut
On Oct 29, 2011 2:44 AM, "Jeffrey Cunningham" jeffrey@jkcunningham.com wrote:
I discovered a way to crash Slime by compiling a simple sexp containing a
string. Here are the conditions:
- Connect to a running SBCL via swank (M-x slime-connect).
- Cut and paste the sexp below containing the smiley-face into a lisp
file.
- Compile the fragment.
That's it. When I do this the inferior Lisp process is terminated "by
remote peer".
(let ((dangerous-string "This is a smiley-face: ☺")) (print "Important safety tip: don't do this."))
I normally only work with UTF-8 characters, and my ignorance of handling
other character sets is probably the culprit here.
What should I do if I want to enable slime to work with strings like this?
What version of Emacs are you using?
-- With best regards, Stas.
-
Alex Ott -
Anton Kovalenko -
Attila Lendvai -
Bernard Hurley -
Helmut Eller -
Jeffrey Cunningham -
Pixel // pinterface -
Sebastian Tennant -
Stas Boukarev