Hi Helmut,
Thanks very much for the detailed and helpful reply.
May I post this as an answer to the SO question? If you don't want to post it yourself, that is.
On Thu, 30 Aug 2012, Helmut Eller wrote:
On Thu, Aug 30 2012, Faheem Mitha wrote:
Hi,
I recently posted a question at
http://stackoverflow.com/questions/12156902/unxpected-behavior-with-eval-whe...
Brief summary:
The following code should (I think) set *read-default-float-format* to double float. Well, it does compile with C-c C-k, but running
*read-default-float-format*
in the REPL afterwards gives SINGLE-FLOAT.
So the value of *read-default-float-format* in the REPL has not changed from the default value of SINGLE-FLOAT.
Note, however, that the
(print *read-default-float-format*)
in the code does return DOUBLE-FLOAT.
Rainer Joswig, in his answer to this question, says that this is because the compilation and the REPL are on different threads (if I understand him correctly), but I'd like some evidence of this.
SLIME creates a new thread for C-c C-k. As compiling could potentially take a long time, using a new thread seems like a reasonable thing to do. Therefore the code that compiles and loads your code is a different thread than the REPL thread.
For evidence, evaluate (princ ccl:*current-process*) in the REPL and inside the eval-when form.
Ah. I tried the function "all-processes". *current-process* is better.
Also, this code works fine with SBCL.
In addition to wanting to understand why this is happening, I'd like to know whether it is possible to work around this, and set *read-default-float-format* in a file, rather than having to set it on the command line.
I'm not sure whether this issue has something to do with SLIME, so I'm posting here first.
Platform and versions. I'm using Debian squeeze x86. The version of SLIME is from Debian unstable, 1:20120525-2. CCL is the 1.8 release. I tried it both with the upstream binaries from http://svn.clozure.com/publicsvn/openmcl/release/1.8/linuxx86/ccl, and a binary package created by me - see Package ccl at mentors.debian.net. The result was the same in each case.
Thanks in advance. Please CC me on any reply.
When CCL creates a new thread it binds some special variables in the new thread. *READ-DEFAULT-FLOAT-FORMAT* is one of them. You can see the full list of those variables with (ccl::standard-initial-bindings). Also look at the documentation of MAKE-PROCESS[1]. I think CCL:DEF-STANDARD-INITIAL-BINDING can be used to change those variables for future thread, but I know no easy way to change them in all existing threads.
When it says MAKE-PROCESS here, it actually means thread, right? This terminology is a little confusing.
The documentation says "See DEF-STANDARD-INITIAL-BINDING" but there is no further information about DEF-STANDARD-INITIAL-BINDING that I could find. It seems this is a function. I found one example of usage which looks like
(ccl::def-standard-initial-binding *read-default-float-format* 'double-float)
Is this correct usage? So, this changes the default value of *read-default-float-format* for all future threads? Should this be called in CCL's init file or somewhere else?
One last question, which is tangentially related. Is there some easy way to find out what CCL (or, more generally, any CL implementation) function is called by C-c C-k?
Regards, Faheem
Helmut
[1] http://ccl.clozure.com/ccl-documentation.html#f_make-process
On Thu, Aug 30 2012, Faheem Mitha wrote:
Hi Helmut,
Thanks very much for the detailed and helpful reply.
May I post this as an answer to the SO question?
Sure.
When CCL creates a new thread it binds some special variables in the new thread. *READ-DEFAULT-FLOAT-FORMAT* is one of them. You can see the full list of those variables with (ccl::standard-initial-bindings). Also look at the documentation of MAKE-PROCESS[1]. I think CCL:DEF-STANDARD-INITIAL-BINDING can be used to change those variables for future thread, but I know no easy way to change them in all existing threads.
When it says MAKE-PROCESS here, it actually means thread, right? This terminology is a little confusing.
Yes, the process terminology stems from the Lisp machine era.
The documentation says "See DEF-STANDARD-INITIAL-BINDING" but there is no further information about DEF-STANDARD-INITIAL-BINDING that I could find.
Well, CCL comes with source code. Which in this case is not that hard to read. If you want to have some official documentation, it's probably the best to create a ticket in the CCL bug tracker.
It seems this is a function. I found one example of usage which looks like
(ccl::def-standard-initial-binding *read-default-float-format* 'double-float)
Is this correct usage? > So, this changes the default value of *read-default-float-format* for all future threads?
Yes, I think so.
Should this be called in CCL's init file or somewhere else?
Yes, that should work or the ~/.swank.lisp file.
One last question, which is tangentially related. Is there some easy way to find out what CCL (or, more generally, any CL implementation) function is called by C-c C-k?
It's a somewhat long sequence but not that hard to discover:
1. C-c C-k invokes the command slime-compile-and-load-file. You can find that out with C-h k C-c C-k.
2. Looking at the source of slime-compile-and-load-file we see that it calls slime-compile-file, which it turn uses (slime-eval-async `(swank:compile-file-for-emacs ...) ...)
3. swank:compile-file-for-emacs is a CL function in swank.lisp. SLIME's M-. should take you right to the source. Reading a bit further reveals that this calls swank-backend:swank-compile-file which is defined in swank-backend.lisp but it's actually implemented in swank-ccl.lisp.
In the *slime-events* buffer you can see the actual messages that are exchanged between Emacs and Lisp. E.g. C-c C-k will send something like
(:emacs-rex (swank:compile-file-for-emacs "/tmp/x.lisp" t) nil t 14)
Helmut