[slime-devel] [BUG] a repeatable way to crash a utf-8 slime session
While figuring out how to deal with unicode i stumbled upon across something which appeared to be killing slime session/sbcl with an ensuing emacs message telling something about process filters. Urfin from #lisp helped me to narrow this down to evaluation of (format t "~c" #\UD0BB), or otherwise getting #\UD0BB shown on the screen, like having it displayed as the result of evaluation. It seems to have a 100% repeatability. I have yesterday's slime and sbcl 1.0/x86/Linux. regards, Samium Gromoff
At Sat, 27 Jan 2007 04:03:32 +0300, Samium Gromoff wrote:
While figuring out how to deal with unicode i stumbled upon across something which appeared to be killing slime session/sbcl with an ensuing emacs message telling something about process filters.
I have just discovered that the SBCL processes are not killed, but are merely excommunicated.
Urfin from #lisp helped me to narrow this down to evaluation of (format t "~c" #\UD0BB), or otherwise getting #\UD0BB shown on the screen, like having it displayed as the result of evaluation.
It seems to have a 100% repeatability.
I have yesterday's slime and sbcl 1.0/x86/Linux.
Urfin has also discovered that the same happens on allegro/win32. Also, i have slime-net-coding-system set to 'utf-8-unix in my .emacs
regards, Samium Gromoff
Samium Gromoff <_deepfire@feelingofgreen.ru> writes:
While figuring out how to deal with unicode i stumbled upon across something which appeared to be killing slime session/sbcl with an ensuing emacs message telling something about process filters.
I have just discovered that the SBCL processes are not killed, but are merely excommunicated.
I've had a similar problem with LispWorks: http://common-lisp.net/pipermail/slime-devel/2006-October/005290.html The solution works for me, but does require me to maintain a seperate patch to local to my machine. Cheers, Chris Dean
On Sat, 27 Jan 2007, Samium Gromoff wrote:
At Sat, 27 Jan 2007 04:03:32 +0300, Samium Gromoff wrote:
While figuring out how to deal with unicode i stumbled upon across something which appeared to be killing slime session/sbcl with an ensuing emacs message telling something about process filters.
I have just discovered that the SBCL processes are not killed, but are merely excommunicated.
FWIW, I solved my unicode problems related to unreconcilable differences between emacs and slime by upgrading emacs to version 23 (cvs branch emacs-unicode-2 or somesuch). It seems to work, as opposed to versions 21 and 22 which both broke to pieces when encountering perfectly acceptable characters from regular utf-8 files. Then again, I'm using emacs -nw so your mileage may vary. Taneli
+ T Taneli Vahakangas <vahakang@cs.helsinki.fi>: | FWIW, I solved my unicode problems related to unreconcilable | differences between emacs and slime by upgrading emacs to version 23 | (cvs branch emacs-unicode-2 or somesuch). An excellent choice. The scary disclaimer on the splash screen notwithstanding, I honestly believe this is the most stable emacs I ever did run. Not that I managed to crash earlier emacsen very often, but this one just seems rock solid. Though I am sure you can have bad things happening if you run cvs update at an unopportune moment. Better have a good backup policy. But I write this not to sing the praise of the emacs-unicode-2 branch, but to point out that I neglected to mention my emacs version in a previous post where I said I could not reproduce the problem. This is vital information. Sorry about leaving it out. - Harald
+ Samium Gromoff <_deepfire@feelingofgreen.ru>: | While figuring out how to deal with unicode i stumbled upon across | something which appeared to be killing slime session/sbcl with an ensuing | emacs message telling something about process filters. | | Urfin from #lisp helped me to narrow this down to evaluation of | (format t "~c" #\UD0BB), or otherwise getting #\UD0BB shown on the screen, | like having it displayed as the result of evaluation. | | It seems to have a 100% repeatability. Does it apply only to this magical value (which would be strange indeed), or to any other character for which emacs cannot find a glyph? | I have yesterday's slime and sbcl 1.0/x86/Linux. FWIW, I can't reproduce this with today's slime and sbcl 1.0.1.33/ppc/MacOS X. I don't use slime-net-coding-system, but instead have (setf slime-lisp-implementations '((sbcl ("sbcl") :coding-system utf-8-unix) (cmucl ("cmucl") :coding-system iso-latin-1-unix))) However I believe the effect should be the same, so this comment is probably irrelevant. - Harald
participants (4)
-
Chris Dean -
Harald Hanche-Olsen -
Samium Gromoff -
T Taneli Vahakangas