I am trying to use Clojure with emacs and cider for a project of mine, and often exceptions occur while executing my code. When an exception occurs, cider provides me a stack trace, but often that is not sufficient to quickly identify what went wrong. I am looking for some way to make CIDER initialize a REPL when the exception occurs, that will allow me to examine the values of locals at the point of occurring of exception and perhaps even change some of the values and continue execution from that point. Is it possible with Clojure, Emacs and Cider?
AFAIK, such feature is not available neither in CIDER nor in other IDEs (Cursive, LightTable).
The most you can do is to insert a breakpoint before erroneous form and, when debugger has popped up, inspect locals there.
Related
I am developing project in clojure using emacs cider under windows. And sometimes I have a problem that after accidently forgotten println function or on printing contents of big file Emacs stops responding (cursor and all key combinations doesn't work) and retire into oneself for processing that information to show it in repl. The only way to continue I know is to close program and open project files from scratch. And it is so simple to get in this trap.
Are there any other better solutions or configuration restrictions?
Though this suggestion will not solve your problem completely, it can help you a little.
First, set *print-length* to some value to limit the number of items of each collection to be printed.
(set! *print-length* 10)
And use cider-connect instead of cider-jack-in. You should run lein repl in a separate console window, then run cider-connect to connect to the repl. Then you can evaluate some expressions in the console window.
It would be good if there's an option to limit the contents to be printed by number of characters, however, I couldn't find it.
When I use the slime-repl, I get this message in my minibuffer and emacs hangs for a second:
error in process filter: Wrong type argument: sequencep, :not-available
It stops happening when I turn off slime-autodoc-mode
Has anyone seen that before?
From this error report
joddie commented:
I experienced the same problem. After a cursory
investigation, it seems to be related to enabling the slime-fancy
module in slime/contrib. slime-fancy is a shortcut for enabling a
number of different slime modules, and I'm not sure which one is the
actual source of the problem, but disabling it seems to fix the
problem here at least.
(This is using the latest Git/CVS versions of slime and slime-js,
although I also tried rolling back to the 2010-02-12 version of slime
just in case; it made no difference).
ghost commented: #joddie : I just try it and remove slime-fancy, it
does work. Now I put
(slime-setup '(slime-js slime-repl))
in my .emacs. Before that I can not use auto complete in node even my
tab already bound to slime-indent-and-complete-symbol. Thanks. :)
For those of you using quicklisp and slime-helper to manage their slime setup open quicklisp/slime-helper.el to find the place where (slime-setup) is used.
I have a small GTK python application that imports a package (Twisted) that may not be loaded twice.
If I run my application in emacs with python-mode.el and press C-c C-c, the application gets executed in a python shell window.
If I now close the application, the python shell stays up and running. If I now press C-c C-c again, emacs "reuses" the old python process and thus I run into problems because I'm installing a Twisted reactor twice.
Is it possible to have python-mode.el open a new shell window each time I execute a buffer?
python-mode.el comes with a command py-execute-buffer-dedicated,
opening a new and reserved process for it
In python.el, a new inferior process is launched in a new buffer if the python-buffer variable is set to nil. Therefore, it's possible to advise the python-send-buffer function to reset that variable to nil after every invocation, thereby forcing a new Python process to be executed for every subsequent python-send-buffer command. Something like the following should work:
(defadvice
python-send-buffer
(after python-send-buffer-new-proc activate)
(setq python-buffer nil))
(ad-activate python-send-buffer)
I know that your post was asking for help with python-mode.el, but I thought it might be helpful to mention this anyway, as I'd surprised if python-mode.el doesn't use a similar mechanism. If I have time, I'll try to look into it.
Edit: the python-mode.el package uses the command py-shell to initiate a new inferior Python process. I found a mailing list posting in which a user provides an ad hoc function that appears to do what you need.
By the way, it might be worth considering that trying to alter the default behavior of python-mode isn't the best approach to this problem. I don't know what your code does, and I'm not particularly familiar with Twisted, but it seems to me that experiencing major errors when evaluating your code a second time within the same session could be a sign of a more fundamental design problem. I fail to see how it could be a matter of multiple imports of the same module being the issue, as Python modules are only loaded once, with successive import statements having no effect (for that, an explicit reload or execfile() is required). If I'm completely off-base here, I apologize, but I felt this possibility might merit mention.
In certain kinds of code it's relatively easy to cause an infinite loop without blowing the stack. When testing code of this nature using clojure-test, is there a way to abort the current running tests without restarting the swank server?
Currently my workflow has involved
$ lein swank
Connect to swank with emacs using slime-connect, and switch to the the tests, execute with C-c C-,, tests run until infinite loop, then just return but one cpu is still churning away on the test. The only way to stop this I have found is to restart lein swank, but it seems like this would be a relatively common problem? Anyone have a better solution?
Yes, it is a common problem for programmers to write infinite loops in development :). And the answer is very simple. It's called "Interrupt Command" and it is C-c C-b
Leiningen has nothing to do with this. This is SLIME/Swank/Clojure. When you evaluate code in Emacs you are spawning a new thread within Clojure. SLIME keeps reference to those threads and shows you how many are running in the Emacs modeline. If you're in a graphical environment you can click the modeline where it indicates your namespace and see lots of options. One option is "Interrupt Command"
Eval (while true) and C-c C-b to get a dialog showing a java.lang.ThreadDeath error with probably just one option. You can type 0 or q to quit that thread, kill that error message buffer and return focus to your previous buffer.
As per this old discussion, adding (use 'clojure.contrib.repl-utils)) and (add-break-thread!) to user.clj should enable you to press C-c C-c for passing SIGINT to the long running evaluation/processe.
if all else fails.. alt-x slime-quit-lisp and restart the REPL. try Psyllo's answer first of course.
I'm having a problem with an Emacs lisp package that I pulled down from the ubuntu distribution. The package is JDEE, and it complains of Args out of range: "63", 0, 4 in the mini buffer and the *Messages* buffer whenever I open a file. This bug appears to have been reported last September but no action has been taken. I'm not an emacs newbie, having written some Elisp code myself, but I've never attempted to debug anything like this. I would like to stop the file load in a debugger when this error happens to at least get an idea of where the problem is coming from. I've read section 18.1.1 of the Elisp manual on "Entering the debugger on error" but trying to load the file after playing with various combinations of values for debug-on-error, debug-ignored-errors, and debug-on-signal appears to have no effect. Has anybody got any suggestions for my next step?
If debug-on-error isn't working, I'd start with the source itself. Find the keybinding/event that is causing the problem, and locate the function.
C-h k <keystrokes>
M-x find-function <function-name-from-above>
Now, once you are at the source
M-x edebug-defun
And the next time you hit the key, you should be able to step through the program. At that point, you can see which portion causes an error - and drill down that way.
You can also try setting the variable 'stack-trace-on-error to see if you can find the culprit (though 'debug-on-error usually works for me, not sure why it doesn't for you).
As a last resort (if edebug-defun doesn't work), you can redefine the routine with a call to (debug) in it, sort of does the same.
I suppose JDEE is somehow inhibiting debug-on-error. Perhaps grep through its files for the error message "Args out of range". While debugging, make sure to load the uncompiled .el files, not the byte-compiled .elc files (you will notice it in the debugger if you are running byte-compiled code) by entering commands like (load "foo.el") instead of (load "foo").
I got the same error when using find-grep after accidentally redefining (current-time-string) in one of my own scripts.
Using the M-x edebug-defun tip posted above I managed to find the issue when I stepped through the code giving the error seeing the call to (current-time-string).
Not sure how helpful this is in your case.