It has confused me since the day I tried to mess around with clojure that this topic isn't brought up more (not that I follow clj regularly) ... so I'm happy to learn that someone added trace capabilities.
That said (and I'm not trying to make this a "charged" statement ... just a way to learn more) I had always thought that one of the key things that made lisp so complete was that programs don't just crash ... that debugging is fully-baked into the *core* of everything. Now, I don't remember much about the debugging capabilities of, say, CL, but my understanding is that *after* a crash, you can interrogate the state of objects. . . .rather than having to preemptively guess at what you may want to know in the future. Trace is better than logging. Logging just seems like a flawed approach (as others have pointed out). I mean, Log4j (or related) is desired in Java so that someone can get more information without a recompile. But in a dynamically run language or in an environment where you aren't just the user of some closed-off code, you may as well just put print statements where you need them. The latter is what I was advised to do in Clojure, and it was a real turn-off for me. Maybe the lack of appeal comes from having to squeeze in that extra "do" nesting -- or maybe because you then have to go through and remove all that stuff later. Or in the case of logging? you always leave it there, FOREVER. Even if you never end up caring about some state in a production environment!!! So, anyway, it seems to me that folks have been successfully chipping away, borrowing, and improving the cool things about CL for years, but, amazingly, a newb to Lisp like me can still find something unique about CL. Or, at least it seems unique to me .... this concept of leaving the user suspended in the middle of the execution exactly where it crashes without having to know before-hand that they should have somehow debugged. It's the only language I know of that comes that close to giving you the true state of a program "when it crashed". I mean, any time you have to rerun a program, you have to say, "I hope I can repeat (or remember) the conditions". But maybe there are things I'm not considering. It seems like an FP-lang ought to be able to handle something like that environment easily. On the other hand, a parallel world could have real troubles bothering to trying to figure out what any of that would mean. I wonder how CL users feel about this issue. Is it a feature they really love or something they wouldn't miss because they never really took advantage of it? On Sun, Jan 24, 2010 at 8:22 AM, Gabi <bugspy...@gmail.com> wrote: > Be careful of deftrace. It has a bug that crashes when the defn'ed > funcs have string comment on the top of the func > > On Jan 23, 7:02 am, ataggart <alex.tagg...@gmail.com> wrote: > > On Jan 22, 6:27 pm, Mike Meyer <mwm-keyword-googlegroups. > > > > > > > > 620...@mired.org> wrote: > > > On Fri, 22 Jan 2010 17:25:39 -0800 > > > > > ajay gopalakrishnan <ajgop...@gmail.com> wrote: > > > > I dont mind using println. The problem is that needs to be inside a > do or > > > > when ... and that is not really part of my code. When the time comes > to > > > > remove the prints, i need to remove all these do blocks too. I can > leave > > > > them as it is I guess, but then it is not neat and non-idiomatic. > From all > > > > the replies, it seems that Debugging is going to be a pain in the > Lisp style > > > > languages. How do people in Lisp/Scheme debug it? > > > > > In the REPL. That's a pretty complete debugger, all by itself. In > > > something like SLIME, you get the ability to examine the call stack, > > > etc. while things are running. > > > > > The trace package just dumps arguments/results of functions while they > > > run. It's a primitive tool, but better than println's in many cases: > > > > > user it, then use dotrace: > > > > > user> (use 'clojure.contrib.trace) > > > nil > > > user> (defn foo [coll] (reduce + coll)) > > > #'user/foo > > > user> (defn bar [coll] (map inc coll)) > > > #'user/bar > > > user> (dotrace [foo bar] (foo (bar [1 1 1]))) > > > TRACE t7043: (bar [1 1 1]) > > > TRACE t7043: => (2 2 2) > > > TRACE t7044: (foo (2 2 2)) > > > TRACE t7044: => 6 > > > 6 > > > user> (dotrace [foo +] (foo (bar [1 1 1]))) > > > TRACE t7071: (foo (2 2 2)) > > > TRACE t7072: | (+ 2 2) > > > TRACE t7072: | => 4 > > > TRACE t7073: | (+ 4 2) > > > TRACE t7073: | => 6 > > > TRACE t7071: => 6 > > > 6 > > > > > and so on. > > > > > <mike > > > -- > > > Mike Meyer <m...@mired.org> > http://www.mired.org/consulting.html > > > Independent Network/Unix/Perforce consultant, email for more > information. > > > > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org > > > > See, I *knew* there had to be a way to do it! Clearly I wasn't > > grokking the docs for dotrace. If the authors of of c.c.trace are > > amenable, I'm inclined to add this functionality to a variant of the > > c.c.logging/spy macro, something like: > > > > (spy [foo bar] (foo (bar [1 1 1]))) > > -- > 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<clojure%2bunsubscr...@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 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
