Sorry to keep replying to my own posts with corrections: Rereading previous posts, I think I understand now that Colin's comments about retaining locals were intended to be relevant only to possible future facilities (which would go beyond my current knowledge). But I'm still curious about where the -Dblahblah goes, etc. Thanks.
On Tuesday, November 12, 2013 11:15:11 PM UTC-6, Mars0i wrote: > > Colin (or anyone), for a Clojure newbie, could you spell out what you're > saying about *compiler-options* and -Dblahblah a little bit further? I > think you're saying that if *compiler-options* is set to > :disable-locals-clearing , then values of local variables are available, > somehow. Can I see them from the lein REPL, somehow? If not, what do I > get from :disable-locals-clearing ? > > It also sounds as if the only way to set *compiler-options* to > :disable-locals-clearing is to use > -Dclojure.compile.disable-locals-clearing=true . Where would I put that in > a Leiningen project file? After :jvm-opts or :javac-options? Somewhere > else? (I experimented with both, and with trying to set *command-options* > in various ways, but I'm not what effect I should see.) > > Thanks- > Marshall > > (Also, another big +1 for Lee's original comments, and thanks for all of > the debugger suggestions from others. Locals are especially important when > there's no state. I just recently started rewriting a Common Lisp > application. The code had gotten too convoluted; parts of it are very old, > with many layers of accretions. I've been doing the rewrite in Clojure as > my first Clojure project. I'm seriously wondering at this moment, though, > whether I should stop and do the rewrite in CL instead, despite several > advantages of Clojure for me. Being able to easily look at any data > structure at any time in the CL version of this application has been > absolutely crucial in the past.) > > On Friday, November 8, 2013 11:13:01 PM UTC-6, Colin Fleming wrote: >> >> 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 <al...@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 clo...@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+u...@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+u...@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.
