And, of course, Engelberg's objection then applies again: you have to have the bug, disable locals clearing, and then try to reproduce the bug again in order to have the otherwise-cleared locals available in the debug session.
Clojure just doesn't make what he asked for easy, by its nature. Designing to minimize difficulty with reproducing any observed behavior seems to be indicated (and desirable for other reasons anyway). On Tue, May 28, 2013 at 5:10 PM, Alan Malloy <a...@malloys.org> wrote: > On Tuesday, May 28, 2013 1:01:46 PM UTC-7, Ben Mabey wrote: > >> On 5/28/13 1:05 PM, Lee Spector wrote: >> >> On May 28, 2013, at 2:40 PM, Ben Mabey wrote: >> >> The flag is a system property: >> "-Dclojure.compiler.disable-**locals-clearing=true". So you can add that >> string to your project.clj's :jvm-opts if you are using lein. This will, of >> course, slow down your program but when I've used it in the past it hasn't >> made it unusable for development. >> >> Thanks for the project.clj specifics Ben. >> >> It still isn't clear to me if/how I could then look at the locals after >> hitting an unexpected exception. Perhaps Cedric's strategy described a >> couple of messages back (which I didn't fully understand) would work here? >> But from the lack of followup to this post >> http://comments.gmane.org/**gmane.comp.java.clojure.swank-**clojure.devel/106 >> <http://comments.gmane.org/gmane.comp.java.clojure.swank-clojure.devel/106> >> -- I wonder if it still won't work when hitting unexpected exceptions. >> >> >> To do this I have been using nrepl-ritz's 'M-x >> nrepl-ritz-break-on-exception'**. If you are using emacs and haven't >> looked into ritz I would highly encourage taking the time to do so. It is >> painless to install these days and you can watch a nice presentation on it ( >> https://github.com/pallet/**ritz/tree/develop/nrepl#** >> additional-resources<https://github.com/pallet/ritz/tree/develop/nrepl#additional-resources>). >> If you aren't using emacs then I don't have any suggestions for you. :( >> >> Also, I guess I don't understand what locals clearing is in this context, >> but why would this slow things down? If it's just preventing the clearing of >> locals when handling an exception then I'd expect it to have no effect >> except during an exception... Do you mean that it'll slow down code that >> does a lot of "exception" handling in circumstances that aren't really >> exceptional? Or will this flag do something very different than what I'm >> thinking, like causing all locals everywhere to be retained forever? That'd >> cause problems worse than just slowdowns, I would think. >> >> It would slow things down in that more things wouldn't be allowed to be >> GCed as soon as they would be with locals clearing (the usual culprit being >> lazy seqs). Unfortunately, I don't know enough of the details of how and >> when locals clearing works to give you more details. So I'd love to hear a >> better explanation from someone who knows. >> > > The principal problem of disabling locals-clearing is not "slowing things > down", but rather causing perfectly reasonable code to consume unbounded > memory. For example, consider: ((fn [xs] (nth xs 1e8)) (range)). With > locals clearing, the compiler makes sure that xs is available for GC as it > is being processed, so that the working-set size is small. If locals > clearing is disabled, the local reference xs is kept around in case a > debugger wants to look at it, and so the head of xs is being held while it > is realized, meaning a hundred-million-element range must be kept in memory > until the function call completes. > > It's definitely useful to be able to disable locals-clearing temporarily > while debugging, but doing so in any kind of production app would be a > disaster. > > -- > -- > 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.
