[slime-devel] Weird interaction between CMU, SLIME, floating-point-modes, possibly kernel/chipset?
Sorry for the length of this post, but I'm encountering a very odd problem. This problem involves different behavior on two different x86 machines, one of which is a Dell Xeon desktop machine running Fedora Core with a 2.4.22 kernel, the other an IBM T42 laptop running Debian Testing with a 2.6.3 kernel. (The laptop has a Pentium M chip --- I do not know if this can be causing the differences, I guess the kernel difference seems more likely.)
On both machines, I am using SLIME from CVS downloaded on 06 August 2004, and I'm using the CMUCL 19A binary release downloaded on 05 August 2004. Before each run of SLIME, I remove all the .x86f files from the slime directory, as well the entire ~/.slime directory, which seems to be caching these (this is probably overkill, but I don't have a good feel for what's being cached when I change things, and I'm trying to isolate the problem).
In all cases, we consider a .emacs file consisting (only) of the following lines: (add-to-list 'load-path "/home/rif/Software/slime") (require 'slime) (setq swank:*communication-style* :sigio) (setq inferior-lisp-program "/home/rif/Software/CMU19A/bin/lisp")
The .cmucl-init file is either blank, or consists of the single line: (set-floating-point-modes :traps nil)
If the .cmucl-init file is not blank (contains the above line), at the CL-USER> prompt, I type: (get-floating-point-modes)
If the .cmucl-init file IS blank, then I type at the prompt: (set-floating-point-modes :traps nil) (get-floating-point-modes)
We consider a "correct" result to be (:TRAPS NIL :ROUNDING-MODE :NEAREST :CURRENT-EXCEPTIONS (:INEXACT) :ACCRUED-EXCEPTIONS (:INEXACT) :FAST-MODE NIL :PRECISION-CONTROL :64-BIT)
We consider (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO) :ROUNDING-MODE :NEAREST :CURRENT-EXCEPTIONS (:INEXACT) :ACCRUED-EXCEPTIONS (:INEXACT) :FAST-MODE NIL :PRECISION-CONTROL :64-BIT)
to be an "incorrect result".
On each of the two machines, I tested the empty and single-line .cmucl-init files inside and outside SLIME (outside SLIME means starting CMUCL in a terminal). On the desktop, everything gave the correct result. On the laptop, everything gave the correct result EXCEPT the combination of the blank initialization file and SLIME, which gave the incorrect result. For this combination, I also tried changing :sigio in the .emacs to :fd-handler, based on some earlier discussions on this list; this did not seem to make any difference.
Summary: On my Dell machine, all methods give the correct result. On my IBM laptop, I do not have any way to set CMUCL floating-point modes on an already running SLIME, although I can do it either in a terminal or at SLIME start-up time.
Any help or suggestions are appreciated.
Sincerely,
rif
rif rif@MIT.EDU writes:
For this combination, I also tried changing :sigio in the .emacs to :fd-handler, based on some earlier discussions on this list; this did not seem to make any difference.
In ~/.swank.lisp you mean?
I get the incorrect result on my laptop running Linux 2.6.0. If I add this line to my ~/.swank.lisp:
(setq swank:*communication-style* :fd-handler)
Then I get the correct result.
Could you please double-check?
(This is based on the previous idea that Linux is saving/restoring floating point modes when calling the SIGIO handler.)
-Luke
In ~/.swank.lisp you mean?
I get the incorrect result on my laptop running Linux 2.6.0. If I add this line to my ~/.swank.lisp:
(setq swank:*communication-style* :fd-handler)
Sorry, I was putting it in .emacs. If I create a .swank.lisp and put this in, then I again get the "correct" result.
Changing the topic, if I use :fd-handler, do I have any way to interrupt running Lisp code?
rif
rif rif@MIT.EDU writes:
Sorry, I was putting it in .emacs. If I create a .swank.lisp and put this in, then I again get the "correct" result.
Changing the topic, if I use :fd-handler, do I have any way to interrupt running Lisp code?
Yes, C-c C-c in the REPL or C-c C-b in a lisp-mode buffer will send a SIGINT and put it into the debugger.
:SIGIO means that RPCs from Emacs are executed by a signal handler so that they implicitly interrupt Lisp to make it act on them. So e.g. you can use the REPL while compiling a file.
-Luke
-
Luke Gorrie -
rif