[slime-devel] Unicode character misbehavior?
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:
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.
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. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
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 Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06
* 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 -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap
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
-- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott
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. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
* 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:
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?
What version of Emacs are you using? -- With best regards, Stas.
participants (9)
-
Alex Ott -
Anton Kovalenko -
Attila Lendvai -
Bernard Hurley -
Helmut Eller -
Jeffrey Cunningham -
Pixel // pinterface -
Sebastian Tennant -
Stas Boukarev