Lee, I am curious whether you would consider it "too tied to a particular dev environment" if the kind of minimal debugging features you wish for worked from Leiningen's REPL? i.e. 'lein repl'
I do not know if Ritz can work in such an environment or not, but I am guessing it might be easier to get a subset of it working there than from a REPL started via 'java -cp clojure.jar clojure.main' Andy On Thu, Nov 7, 2013 at 9:32 AM, Lee Spector <lspec...@hampshire.edu> 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 > > > > phillip.l...@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.
