Re: [slime-devel] Emacs command for loading Slime and application
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
1. If Slime is not already running, the load command is not executed.
2. If Slime is already running, Femlisp is loaded, but the package is not set.
Can someone tell me how I can achieve my goal?
Yes, this is bit more difficult because most of the commands work asynchronously. I changed slime-start-and-load a bit so that it should be usable for your needs. In general If you need commands of this sort, it's usually the easiest to write a small CL function for the job, so that Emacs can make a single RPC and doesn't need so much synchronization.
PS: Another problem is that executing (slime) apparently sets back some variables, e.g. *READ-DEFAULT-FLOAT-FORMAT* which I have set to DOUBLE-FLOAT when loading Femlisp. Why is that?
Can't help you here without more details. Which Lisp are you using? Which communication style? Are threads involved? We don't set *READ-DEFAULT-FLOAT-FORMAT* explicit, but there's always the possibility for bug and that we used WITH-STANDARD-IO-SYNTAX in a wrong place. Helmut.
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
1. If Slime is not already running, the load command is not executed.
2. If Slime is already running, Femlisp is loaded, but the package is not set.
Can someone tell me how I can achieve my goal?
Yes, this is bit more difficult because most of the commands work asynchronously. I changed slime-start-and-load a bit so that it should be usable for your needs.
Thank you, Helmut. This works fine. Femlisp loads, and I am left with an "APPLICATION>" prompt.
In general If you need commands of this sort, it's usually the easiest to write a small CL function for the job, so that Emacs can make a single RPC and doesn't need so much synchronization.
I tried to set the package in the file being loaded, but it did not work because *PACKAGE* is specially bound during LOAD.
PS: Another problem is that executing (slime) apparently sets back some variables, e.g. *READ-DEFAULT-FLOAT-FORMAT* which I have set to DOUBLE-FLOAT when loading Femlisp. Why is that?
Can't help you here without more details. Which Lisp are you using? Which communication style? Are threads involved? We don't set *READ-DEFAULT-FLOAT-FORMAT* explicit, but there's always the possibility for bug and that we used WITH-STANDARD-IO-SYNTAX in a wrong place.
I have tried it now again with CMUCL and I could not reproduce this error, i.e. when I do `M-x slime', *READ-DEFAULT-FLOAT-FORMAT* remains at 'DOUBLE-FLOAT. Fine. However, I see that the package of the REPL is reset to CL-USER. For me, it would be better if it remained FL.APPLICATION. Or should I use a different function for bringing up the SLIME-REPL buffer? Thank you very much, Niko.
Hello, I have just checked with SBCL, and here is where the error with *READ-DEFAULT-FLOAT-FORMAT* occurs, probably because of threads. Also, your modifications of slime-start-and-load do not work with SBCL. I.e. after doing (slime-start-and-load (concat *femlisp-root* "start.lisp") "FL.APPLICATION") I get ... CL-USER> CL-USER> *READ-DEFAULT-FLOAT-FORMAT* SINGLE-FLOAT When I then set the default format manually in the REPL, it is reset by `M-x slime'. CL-USER> (setq *READ-DEFAULT-FLOAT-FORMAT* 'DOUBLE-FLOAT) DOUBLE-FLOAT CL-USER> *READ-DEFAULT-FLOAT-FORMAT* DOUBLE-FLOAT CL-USER> [ I have executed `M-x slime' here] CL-USER> *READ-DEFAULT-FLOAT-FORMAT* SINGLE-FLOAT CL-USER> Yours, Nicolas. Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
1. If Slime is not already running, the load command is not executed.
2. If Slime is already running, Femlisp is loaded, but the package is not set.
Can someone tell me how I can achieve my goal?
Yes, this is bit more difficult because most of the commands work asynchronously. I changed slime-start-and-load a bit so that it should be usable for your needs.
In general If you need commands of this sort, it's usually the easiest to write a small CL function for the job, so that Emacs can make a single RPC and doesn't need so much synchronization.
PS: Another problem is that executing (slime) apparently sets back some variables, e.g. *READ-DEFAULT-FLOAT-FORMAT* which I have set to DOUBLE-FLOAT when loading Femlisp. Why is that?
Can't help you here without more details. Which Lisp are you using? Which communication style? Are threads involved? We don't set *READ-DEFAULT-FLOAT-FORMAT* explicit, but there's always the possibility for bug and that we used WITH-STANDARD-IO-SYNTAX in a wrong place.
Helmut.
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
CL-USER> *READ-DEFAULT-FLOAT-FORMAT* SINGLE-FLOAT
When I then set the default format manually in the REPL, it is reset by `M-x slime'.
That could be a bug or a feature depending on your expectations. Changing *READ-DEFAULT-FLOAT-FORMAT* globally is rather hard in SBCL. SBCL's native top level loop is executed within with-rebound-io-syntax, i.e. most reader variables have a non-toplevel binding in the initial thread and all our threads are spawned from that thread. In SBCL, a new threads inherits (all?) the dynamic bindings of the parent thread and so, if you change *READ-DEFAULT-FLOAT-FORMAT* in one thread, the change it will not be visible in other threads. M-x slime also creates a new threads and the bindings are those from the initial thread. I've heard that SBCL's inheriting semantics for dynamic variables are an ongoing debate, maybe they change it. Helmut.
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
CL-USER> *READ-DEFAULT-FLOAT-FORMAT* SINGLE-FLOAT
When I then set the default format manually in the REPL, it is reset by `M-x slime'.
That could be a bug or a feature depending on your expectations.
Changing *READ-DEFAULT-FLOAT-FORMAT* globally is rather hard in SBCL. SBCL's native top level loop is executed within with-rebound-io-syntax, i.e. most reader variables have a non-toplevel binding in the initial thread and all our threads are spawned from that thread. In SBCL, a new threads inherits (all?) the dynamic bindings of the parent thread and so, if you change *READ-DEFAULT-FLOAT-FORMAT* in one thread, the change it will not be visible in other threads. M-x slime also creates a new threads and the bindings are those from the initial thread.
I've heard that SBCL's inheriting semantics for dynamic variables are an ongoing debate, maybe they change it.
Helmut.
Thank you for the explanation. Hmm, maybe I should allow my application to operate also with SINGLE-FLOAT. I fear, however, that the accuracy will usually not be sufficient such that this would put a burden on the user to set *READ-DEFAULT-FLOAT-FORMAT* to DOUBLE-FLOAT when starting up his/her Lisp. (This should be sufficient, I hope.) At the moment, I simply do not use 'M-x slime' for bringing up the REPL, but this function: (defun show-repl-maybe-start-slime () (interactive) (if (slime-connected-p) (slime-display-output-buffer) (slime))) (global-set-key [f9] 'show-repl-maybe-start-slime) This works for CMUCL (no threads). For SBCL, I guess that I will set *READ-DEFAULT-FLOAT-FORMAT* also in my .sbclrc file. Thanks again, Nicolas.
participants (2)
-
Helmut Eller -
Nicolas Neuss