[slime-devel] slime-pprint-eval-region
I had a desire for a slime-pprint-eval-region and cobbled together the following patch. It's bound to C-c C-f and allows one to highlight a region and then evaluate it. This is helpful in particular when dealing with forms with reader macros in them that aren't properly read by emacs' backward-sexp function. Any interest in seeing something like this in the canonical slime.el? thanks, Cryus diff --git a/slime.el b/slime.el index 3ef2b41..bfb4242 100644 --- a/slime.el +++ b/slime.el @@ -531,6 +531,7 @@ information." (defvar slime-prefix-bindings '(("\C-r" slime-eval-region) + ("\C-f" slime-pprint-eval-region) (":" slime-interactive-eval) ("\C-e" slime-interactive-eval) ("E" slime-edit-value) @@ -4297,6 +4298,13 @@ Use `slime-re-evaluate-defvar' if the from starts with '(defvar'" `(swank:interactive-eval-region ,(buffer-substring-no-properties start end)))) +(defun slime-pprint-eval-region (start end) + "Evaluate region; pprint the value in a buffer." + (interactive "r") + (slime-eval-describe + `(swank:pprint-eval + ,(buffer-substring-no-properties start end)))) + (defun slime-eval-buffer () "Evaluate the current buffer. The value is printed in the echo area." @@ -7149,6 +7157,7 @@ is setup, unless the user already set one explicitly." [ "Eval Last Expression" slime-eval-last-expression ,C ] [ "Eval And Pretty-Print" slime-pprint-eval-last-expression ,C ] [ "Eval Region" slime-eval-region ,C ] + [ "Eval Region And Pretty-Print" slime-pprint-eval-region ,C ] [ "Interactive Eval..." slime-interactive-eval ,C ] [ "Edit Lisp Value..." slime-edit-value ,C ] [ "Call Defun" slime-call-defun ,C ])
* Cyrus Harmon [2012-05-05 23:36] writes:
I had a desire for a slime-pprint-eval-region and cobbled together the following patch. It's bound to C-c C-f and allows one to highlight a region and then evaluate it. This is helpful in particular when dealing with forms with reader macros in them that aren't properly read by emacs' backward-sexp function.
Any interest in seeing something like this in the canonical slime.el?
I the command, but not the keybinding. Helmut
[possible dup alert -- common-lisp.net's spam filter didn't like my first attempt at this] Thanks Helmut! Since I haven't done this before, and I'd like that keybinding locally, is this the proper way to do that in one's .emacs: (add-hook 'slime-mode-hook (lambda () (pushnew (list "\C-c\C-f" 'slime-pprint-eval-region) slime-editing-keys :test 'equalp) (slime-init-keymaps))) thanks again, Cyrus On May 6, 2012, at 1:42 AM, Helmut Eller wrote:
I the command, but not the keybinding.
Helmut
* Cyrus Harmon [2012-05-06 16:24] writes:
Since I haven't done this before, and I'd like that keybinding locally, is this the proper way to do that in one's .emacs:
(add-hook 'slime-mode-hook (lambda () (pushnew (list "\C-c\C-f" 'slime-pprint-eval-region) slime-editing-keys :test 'equalp) (slime-init-keymaps)))
thanks again,
Yes, that should work. So should this: (add-hook 'slime-load-hook 'my-slime-load-hook) (defun my-slime-load-hook () (define-key slime-mode-map (kbd "C-c C-f") 'slime-pprint-eval-region)) slime-load-hook is run at the end of slime.el, i.e. only once not for every time when slime-mode is turned on. Helmut
Hello Helmut I've gotten into the habit of running "./test.sh -S emacs sbcl" in the slime directory after downloading the daily slime updates just to see if it catches something. Normally, after running the test script I get three errors I've come to expect as normal and I continue to use the slime update. This morning's update causes an error that I haven't gotten before. After listing the three errors I've come to expect as normal, there is brief period of waiting and then I get a message "Lisp connection closed unexpectedly: connection broken by remote peer" indicating the connection was closed and the test session remains active. I don't know how to close it other than closing the terminal window it was running in. The last few lines showing in the "Tests" window of the "slime : emacs" session running in the terminal window were: ** input: (1 0)... ** input: (2 1)... ** input: (4 2)... * flow-control ** input: (400 0.03 3) OK: No debugger ERROR: (error "Timeout waiting for condition: \"In debugger\"") I'm using SBCL 1.0.55 running on a copy of 32-bit PCLinuxOS. I've been using the CVS command: "cvs -d :pserver:anonymous:anonymous@common-lisp.net:/project/slime/cvsroot co slime" as recommended on the slime website to download slime. starting with a fresh install for each update (which only takes a few seconds). If I download the fairly stable release using the CVS incantations found in the slime documentation, the test succeeds with only the usual three failures I've come to expect as normal, but the release date on the slime I get that way is about a year old. Is the "test.sh" script I find in the slime directory a useful tool to use on new slime upgrades or am I expecting too much from it? Thanks, Paul Bowyer
* Paul Bowyer [2012-05-06 17:40] writes:
Is the "test.sh" script I find in the slime directory a useful tool to use on new slime upgrades or am I expecting too much from it?
Thanks for running the tests! The 3 new failures are indeed a regression: I tried to use the :timeout argument of sb-thread:condition-wait that was added in version 1.0.54 or so. Obviously it doesn't work as I had expected; I'll restore the previous version. And yes, the purpose of the script is to catch such things. The 3 remaining failures are a known problem but nothing serious. Those only fail in SBCL due to some quirks of its pretty printer. Helmut
On 7 May 2012 00:22, Helmut Eller <heller@common-lisp.net> wrote:
regression: I tried to use the :timeout argument of sb-thread:condition-wait that was added in version 1.0.54 or so. Obviously it doesn't work as I had expected; I'll restore the previous
Without digging deeper, it seems to me that there is an outer deadline from another WITH-DEADLINE. In the old version you're using :OVERRIDE, which means that even if you specify a longer wait, you get what you ask for. In the new version the outer WITH-DEADLINE specifies a shorter wait than the :TIMEOUT you request, and that happens -- and a deadline-timeout is signalled, etc. Using bleeding edge SBCL and '(sb-sys:with-deadline (:seconds nil :override t) (sb-thread:condition-wait waitqueue mutex :timeout timeout))) in the first leg, the tests pass after removing nil ; FIXME: :timeout doesn't work. Why? ...but since ability to specify :SECONDS NIL is very new, it's probably best not to depend on that just now. Finding the outer source of deadline is probably a better bet. Cheers, -- Nikodemus
* Nikodemus Siivola [2012-05-07 05:24] writes:
On 7 May 2012 00:22, Helmut Eller <heller@common-lisp.net> wrote:
regression: I tried to use the :timeout argument of sb-thread:condition-wait that was added in version 1.0.54 or so. Obviously it doesn't work as I had expected; I'll restore the previous
Without digging deeper, it seems to me that there is an outer deadline from another WITH-DEADLINE. In the old version you're using :OVERRIDE, which means that even if you specify a longer wait, you get what you ask for.
In the new version the outer WITH-DEADLINE specifies a shorter wait than the :TIMEOUT you request, and that happens -- and a deadline-timeout is signalled, etc.
Is WITH-DEADLINE part of the official API? Seriously? Helmut
On 7 May 2012 08:45, Helmut Eller <heller@common-lisp.net> wrote:
Without digging deeper, it seems to me that there is an outer deadline from another WITH-DEADLINE. In the old version you're using :OVERRIDE, which means that even if you specify a longer wait, you get what you ask for.
In the new version the outer WITH-DEADLINE specifies a shorter wait than the :TIMEOUT you request, and that happens -- and a deadline-timeout is signalled, etc.
Is WITH-DEADLINE part of the official API? Seriously?
If you mean "am I really supposed to wrap WITH-DEADLINE around CONDITION-WAIT calls", not generally. In this case however, something else, probably the :AROUND method on STREAM-FORCE-OUTPUT, has provided a tighter deadline. In such case the system obeys the global deadline. Sticking a longer deadline into S-F-E :AROUND would achieve the same result from practical POV. Cheers, -- Nikodemus
* Nikodemus Siivola [2012-05-10 06:14] writes:
On 7 May 2012 08:45, Helmut Eller <heller@common-lisp.net> wrote:
Without digging deeper, it seems to me that there is an outer deadline from another WITH-DEADLINE. In the old version you're using :OVERRIDE, which means that even if you specify a longer wait, you get what you ask for.
In the new version the outer WITH-DEADLINE specifies a shorter wait than the :TIMEOUT you request, and that happens -- and a deadline-timeout is signalled, etc.
Is WITH-DEADLINE part of the official API? Seriously?
If you mean "am I really supposed to wrap WITH-DEADLINE around CONDITION-WAIT calls", not generally.
I meant more "is it possible to write reliable programs with such an API".
In this case however, something else, probably the :AROUND method on STREAM-FORCE-OUTPUT, has provided a tighter deadline. In such case the system obeys the global deadline. Sticking a longer deadline into S-F-E :AROUND would achieve the same result from practical POV.
Apparently not. Helmut
Helmut Eller <heller@common-lisp.net> writes:
* Nikodemus Siivola [2012-05-10 06:14] writes:
On 7 May 2012 08:45, Helmut Eller <heller@common-lisp.net> wrote:
Without digging deeper, it seems to me that there is an outer deadline from another WITH-DEADLINE. In the old version you're using :OVERRIDE, which means that even if you specify a longer wait, you get what you ask for.
In the new version the outer WITH-DEADLINE specifies a shorter wait than the :TIMEOUT you request, and that happens -- and a deadline-timeout is signalled, etc.
Is WITH-DEADLINE part of the official API? Seriously?
If you mean "am I really supposed to wrap WITH-DEADLINE around CONDITION-WAIT calls", not generally.
I meant more "is it possible to write reliable programs with such an API".
In this case however, something else, probably the :AROUND method on STREAM-FORCE-OUTPUT, has provided a tighter deadline. In such case the system obeys the global deadline. Sticking a longer deadline into S-F-E :AROUND would achieve the same result from practical POV.
Apparently not.
IMHO, the composition semantics of WITH-DEADLINE are an improvement over WITH-TIMEOUT. It's certainly debatable whether the hack in STREAM-FORCE-OUTPUT is in good style, but it's there for a reason. It's hardly the fault of the API.
* Gábor Melis [2012-05-10 07:21] writes:
Helmut Eller <heller@common-lisp.net> writes:
* Nikodemus Siivola [2012-05-10 06:14] writes:
On 7 May 2012 08:45, Helmut Eller <heller@common-lisp.net> wrote:
Without digging deeper, it seems to me that there is an outer deadline from another WITH-DEADLINE. In the old version you're using :OVERRIDE, which means that even if you specify a longer wait, you get what you ask for.
In the new version the outer WITH-DEADLINE specifies a shorter wait than the :TIMEOUT you request, and that happens -- and a deadline-timeout is signalled, etc.
Is WITH-DEADLINE part of the official API? Seriously?
If you mean "am I really supposed to wrap WITH-DEADLINE around CONDITION-WAIT calls", not generally.
I meant more "is it possible to write reliable programs with such an API".
In this case however, something else, probably the :AROUND method on STREAM-FORCE-OUTPUT, has provided a tighter deadline. In such case the system obeys the global deadline. Sticking a longer deadline into S-F-E :AROUND would achieve the same result from practical POV.
Apparently not.
IMHO, the composition semantics of WITH-DEADLINE are an improvement over WITH-TIMEOUT. It's certainly debatable whether the hack in STREAM-FORCE-OUTPUT is in good style, but it's there for a reason. It's hardly the fault of the API.
It seems to me that WITH-DEADLINE must be used whenever we wait for something and don't know for certain that we aren't inside another WITH-DEADLINE. I.e. "in general" WITH-DEADLINE must be used and only in the special case when we know that no caller used WITH-DEADLINE can it be omitted. I think both WITH-DEADLINE and WITH-TIMEOUT are bad ideas. Helmut
On 10 May 2012 10:45, Helmut Eller <heller@common-lisp.net> wrote:
It seems to me that WITH-DEADLINE must be used whenever we wait for something and don't know for certain that we aren't inside another WITH-DEADLINE. I.e. "in general" WITH-DEADLINE must be used and only in the special case when we know that no caller used WITH-DEADLINE can it
I don't see how this follows. Local :TIMEOUT and a global deadline are two different things. I consider cases where :OVERRIDE is used to be red flags that something is wrong. Either there's a deadline that is unrealistic, or you're blocking way too long. The only places I've used :OVERRIDE so far myself for real is in SB-EXT:EXIT, for which a DEADLINE-TIMEOUT would be quite inappropriate, IMO. In case of Slime, the deadline of 0.1 seconds installed by the :AROUND method is probably unrealistic considering what it is for, and the occasional sluggishness of the system and the purpose of the deadline. 1 second would do just as well. I /don't/ dispute the hacky nature of WITH-DEADLINE for a second, though. It's whole purpose is intercession into parts of a program not written with timeouts in mind -- third party libraries, etc. Cheers, -- Nikodemus
On 05/06/2012 02:22 PM, Helmut Eller wrote:
* Paul Bowyer [2012-05-06 17:40] writes:
Is the "test.sh" script I find in the slime directory a useful tool to use on new slime upgrades or am I expecting too much from it? Thanks for running the tests! The 3 new failures are indeed a regression: I tried to use the :timeout argument of sb-thread:condition-wait that was added in version 1.0.54 or so. Obviously it doesn't work as I had expected; I'll restore the previous version. And yes, the purpose of the script is to catch such things.
The 3 remaining failures are a known problem but nothing serious. Those only fail in SBCL due to some quirks of its pretty printer.
Helmut
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Hello Helmut: Thanks for the reply. I see that the fixes you made correct all of the errors I was experiencing when running the test script. For some reason I don't understand, however, I had to download a new copy of slime twice before the test would pass. I failed to note the errors on my first attempt, but just deleted the entire slime directory and downloaded it again. The second download evidently succeeded because the tests ran without problems. Is there a CVS command or a checksum arrangement that will verify that the current download has been done correctly? Sorry for my ignorance... Thanks, Paul Bowyer
* Paul Bowyer [2012-05-07 15:25] writes:
Hello Helmut:
Thanks for the reply. I see that the fixes you made correct all of the errors I was experiencing when running the test script.
For some reason I don't understand, however, I had to download a new copy of slime twice before the test would pass. I failed to note the errors on my first attempt, but just deleted the entire slime directory and downloaded it again. The second download evidently succeeded because the tests ran without problems. Is there a CVS command or a checksum arrangement that will verify that the current download has been done correctly? Sorry for my ignorance...
A normal "cvs up" should download the newest version of all files. Some of the tests are not 100% repeatable; in particular if test.sh is started without the -S option the tests are executed in random order and that may cause some unfortunate interferences. With -S the results are more predictable. Helmut
Cyrus Harmon <ch-slime@bobobeach.com> writes:
[possible dup alert -- common-lisp.net's spam filter didn't like my first attempt at this]
Thanks Helmut!
Since I haven't done this before, and I'd like that keybinding locally, is this the proper way to do that in one's .emacs: (define-key slime-editing-map "\C-c\C-f" 'slime-pprint-eval-region)
-- With best regards, Stas.
participants (6)
-
Cyrus Harmon -
Helmut Eller -
mega＠retes.hu -
Nikodemus Siivola -
Paul Bowyer -
Stas Boukarev