I believe the locals are actually *not* available because they are proactively cleared to help GC.
Setting the *compiler-options* var with :disable-locals-clearing can turn that off. Which is probably what you often want in dev, but is not the default. You can also set this via command line with -Dclojure.compile.disable-locals-clearing=true On Thursday, November 7, 2013 11:32:29 AM UTC-6, Lee wrote: > > > I'd like to chime in here from a background that involved a lot of Common > Lisping back in the day. > > I have been continually dismayed, as I've moved further from Common Lisp, > that debugging facilities that are so basic and ubiquitous and helpful in > that world are considered exotic or specialized or necessarily tied to > particular IDEs or tool chains in other language ecosystems. > > Even more basic (and useful, in my experience) than things like steppers > or the ability to set break points is the ability just to see the values of > locals when an error occurs. This is so obviously useful, and so obviously > doable (for decades), that I'm really quite stunned that it's so > complicated to do in Clojure and tied to a particular toolset if you can do > it at all. > > In Common Lisp when you hit an error you're thrown into a break loop REPL > in which you can view locals, move up and down the stack, and do lots of > other fancier things (re-binding things, restarting...) that are probably > useful in some situations, but just being able to see the locals is, in my > experience, the really huge win. It doesn't matter what IDE you're using or > if you're running it from a command line or whatever -- it's part of the > language and easy to access no matter how you write and run your code. And > my guess is that every Common Lisper takes advantage of this frequently. > Different implementations/environments provide different modes of access to > this information (e.g. some are GUI-based, and in emacs you can have > interactive access to it using interaction conventions that seemed like a > good idea in the 1970s :-), but there's always some way to get the > information. > > By contrast in Clojure this information seems really hard to come by. I > saw and was excited by a Ritz video -- and I note the enthusiastic applause > from the crowd when it was shown that you could see locals (gasp!) -- but > my understanding is that this functionality requires commitment to an > Emacs-based tool set with all that that implies (which is a lot, IMHO). > > When I hit an error running my code from "lein run" or from Clooj or from > Eclipse/CCW (or I think from any other way that I might run it) I get (or > can easily get) a backtrace that shows the function call stack at the time > of the error... which is good, but surely (?) the locals are also available > when the backtrace is produced and I really also want to see those. The > ability to browse and navigate this information dynamically, as in a Common > Lisp break loop, is cool but I can understand that something about the > Clojure/JVM execution architecture might make that difficult -- maybe that > really would have to be tied to a particular IDE? However, if it would just > dump all of the values of the locals to standard output, just like it does > already with the trace, then I'd be plenty happy since I could dig through > that output to find what I need but can't currently get. (Yes, dumping the > values of all of the locals might produce a lot of output and yes, one > might want to make this an option that could be turned off or on, maybe > including options re: limits on how much of sequences to print, etc.) > > I guess the bottom line of this long message (sorry) is that I hope that > some of the great tool developers in this community will continue to > consider providing things like debugging tools that are as untethered as > possible from particular IDEs. My impression is that nrepl (and maybe other > projects) are intended to help "untether" things in this way, but it still > seems like a lot of people assume that something like access to locals > should naturally be tied to a specific IDE. From my perspective that seems > like a really unfortunate assumption. I realize that debugging tools are > unlikely to become "part of the language" in Clojure as they are in Common > Lisp, but I think there's an important middle ground between that and being > available only within some specific IDE. > > Thanks, > > -Lee > > > > philli...@newcastle.ac.uk <javascript:> (Phillip Lord) writes: > > > >> Ritz does some things, but it doesn't do step through like edebug. > >> > >> I've never found anything as nice as edebug in any language; I guess, > >> it's the big advantage of running your editor and whatever you are > >> debugging in the environment. > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
