On Mar 17, 2010, at 8:14 AM, Lee Spector wrote:
The root problem is that I think I have an infinite loop somewhere
in my code and I'm having a hard time tracking it down. [...] In
Common Lisp I would wait until I think I'm in trouble, break
execution with a keyboard interrupt, look at the function call
stack (and local vars, if I'm in a nice CL environment), and
probably figure it out pretty quickly.[...] Is there is a way to
break and look around under slime? [...]
I've also been doing some runs under MCLIDE, with help from Terje
Norderhaug, and there I can indeed issue a break from a menu and
get a backtrace of sorts... but so far I have not been able to get
a backtrace that shows me what I need -- that is, I don't see any
of my own functions, presumably because the break changed the
context... I'm not sure what's going on there.
MCLIDE gets the same backtrace items from swank-clojure as does emacs
SLIME. I believe the issue is that the JVM only provides limited
stacktrace information (at least compared to what Common Lisp
developers are used to).
A good backtrace is essential for efficient debugging. Are there any
ways to improve the backtrace provided by swank-clojure?
An alternative: Is there a way to watch my running Clojure program
without breaking it, that is to observe the recent call history (of
my own definitions, either all of them or specifically marked ones)
from outside the process?
You could use a profiler to see which of your Clojure functions
monopolize the execution.
I can think of some clumsy ways to roll my own version of this,
e.g. using trace and sending the trace output to a file, but I
don't think this will be practical because I generally only get
these errors after long stretches of intensive computation that
will involve many many calls to the potentially problematic
functions. So I think there'll be too much trace output to save on
disk, and the slowdown from tracing all of the calls may prevent me
from ever reaching a problematic state (although I haven't tried
this to be sure of the timing).
Consider waiting until you are in the situation then use trace on
candidate culprits.
And in spite of the problems listed above I'm having a great time
in the Clojureverse!
-- Terje Norderhaug
te...@in-progress.com
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
