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
-
Chris Dean -
Harald Hanche-Olsen -
Samium Gromoff -
T Taneli Vahakangas