-
Notifications
You must be signed in to change notification settings - Fork 331
/
PROBLEMS
94 lines (63 loc) · 3.29 KB
/
PROBLEMS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
Known problems with SLIME -*- outline -*-
* Common to all backends
** Caution: network security
The `M-x slime' command has Lisp listen on a TCP socket and wait for
Emacs to connect, which typically takes on the order of one second. If
someone else were to connect to this socket then they could use the
SLIME protocol to control the Lisp process.
The listen socket is bound on the loopback interface in all Lisps that
support this. This way remote hosts are unable to connect.
** READ-CHAR-NO-HANG is broken
READ-CHAR-NO-HANG doesn't work properly for slime-input-streams. Due
to the way we request input from Emacs it's not possible to repeatedly
poll for input. To get any input you have to call READ-CHAR (or a
function which calls READ-CHAR).
* Backend-specific problems
** CMUCL
The default communication style :SIGIO is reportedly unreliable with
certain libraries (like libSDL) and certain platforms (like Solaris on
Sparc). It generally works very well on x86 so it remains the default.
** SBCL
The latest released version of SBCL at the time of packaging should
work. Older or newer SBCLs may or may not work. Do not use
multithreading with unpatched 2.4 Linux kernels. There are also
problems with kernel versions 2.6.5 - 2.6.10.
The (v)iew-source command in the debugger can only locate exact source
forms for code compiled at (debug 2) or higher. The default level is
lower and SBCL itself is compiled at a lower setting. Thus only
defun-granularity is available with default policies.
** LispWorks
On Windows, SLIME hangs when calling foreign functions or certain
other functions. The reason for this problem is unknown.
We only support latin1 encoding. (Unicode wouldn't be hard to add.)
** Allegro CL
Interrupting Allegro with C-c C-b can be slow. This is caused by the
a relatively large process-quantum: 2 seconds by default. Allegro
responds much faster if mp:*default-process-quantum* is set to 0.1.
** CLISP
We require version 2.49 or higher. We also require socket support, so
you may have to start CLISP with "clisp -K full".
Under Windows, interrupting (with C-c C-b) doesn't work. Emacs sends
a SIGINT signal, but the signal is either ignored or CLISP exits
immediately.
On Windows, CLISP may refuse to parse filenames like
"C:\\DOCUME~1\\johndoe\\LOCALS~1\\Temp\\slime.1424" when we actually
mean C:\Documents and Settings\johndoe\Local Settings\slime.1424. As
a workaround, you could set slime-to-lisp-filename-function to some
function that returns a string that is accepted by CLISP.
Function arguments and local variables aren't displayed properly in
the backtrace. Changes to CLISP's C code are needed to fix this
problem. Interpreted code is usually easer to debug.
M-. (find-definition) only works if the fasl file is in the same
directory as the source file.
The arglist doesn't include the proper names only "fake symbols" like
`arg1'.
** Armed Bear Common Lisp
The ABCL support is still new and experimental.
** Corman Common Lisp
We require version 2.51 or higher, with several patches (available at
http://www.grumblesmurf.org/lisp/corman-patches).
The only communication style currently supported is NIL.
Interrupting (with C-c C-b) doesn't work.
The tracing, stepping and XREF commands are not implemented along with
some debugger functionality.