One quick clarification about -Dclojure.compile.disable-locals-clearing=true which bit me - this is actually read in clojure.main, which uses it to initialise the *compiler-options* var. This means that if you start your app in any other way (I'm not sure if lein duplicates the clojure.main functionality) setting this system property doesn't do anything.
On 8 November 2013 10:22, Alex Miller <a...@puredanger.com> wrote: > 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 (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. > -- -- 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.
