Ideally, in a Lisp I'd think the unit of breakpoints would not be a line but instead an s-expression, tripping before evaluating the body of the expression.
On Fri, Nov 8, 2013 at 12:24 AM, Colin Fleming <colin.mailingl...@gmail.com>wrote: > I'm slightly late to the discussion, sorry - currently moving cities. > Cursive does indeed have a stepping debugger which works well with Clojure, > although it's quite slow (I haven't been able to figure out why, yet - I > suspect Clojure adds a lot of line information to the bytecode). There have > also been some fairly annoying bugs with it which will be fixed in the next > drop. Here's more or less what it can do: > > 1. Standard stepping - step into, step over. Step out is flaky for > non-Java languages for some reason, I believe this is fixed in the new > version of IntelliJ (13, currently in beta, due to be released soon). > 2. Place breakpoints on any line. This generally works well but is > occasionally frustrating with Clojure since you can pack a lot on a line. > I've found chained sequence operations to be particularly difficult to > debug. This is really a JVM limitation since JVMTI is line-oriented. > 3. Breakpoints can be configured in various ways. Instead of stopping > you can configure them to print the value of an expression, or to stop only > the current thread, or to stop all threads. > 4. Drop frame to go back in time, as long as you're not mutating any > global state. You're not, right? > 5. Look at locals up and down the stack, as long as you have locals > clearing disabled. > 6. For the next drop I'm going to add the ability to toggle locals > clearing in debug REPLs with a button in the REPL tool window. > 7. You can evaluate arbitrary Clojure expressions at any point in the > call stack. > 8. You can set a breakpoint on an arbitrary exception, and it will > pause *at the time the exception is thrown* and you can inspect locals etc. > > I'm pretty sure all of this works, and I use most of it regularly. > Expression evaluation has been broken until the current dev build so I need > to test that things that depend on it work before promising them, but I'm > pretty sure they will. They include: > > 1. Watches. > 2. Being able to configure breakpoints to only stop when a particular > expression is true. > > For the next drop I'm planning to work a lot on the debugger and document > it all properly including some pretty animations, so I'll post to the list > when that is done. > > > On 8 November 2013 13:14, intronic <m...@pheasant.co.nz> wrote: > >> Why would a break function in clojure the language not be considered, >> a-la common-lisp? >> >> >> >> On Friday, 8 November 2013 09:31:55 UTC+10, Lee wrote: >>> >>> >>> On Nov 7, 2013, at 5:48 PM, Alex Miller wrote: >>> >>> > When you say "hit an error", I'm assuming you mean "clojure throws an >>> exception" and not "hit a breakpoint in a debugger" or something else. >>> >>> Yes -- I mean "clojure throws an exception." >>> >>> > >>> > I don't think there is one place where we could generically attach >>> locals info to a thrown exception. The JVM debugging interface (JVMTI - >>> http://docs.oracle.com/javase/7/docs/technotes/guides/jvmti/index.html) >>> can do an awful lot of things (including arbitrary class bytecode >>> transformation) so I would guess it's possible to build a java agent that >>> could do this (or to modify the Compiler to inject the right code at >>> compile time). Sounds like a fun project, but probably non-trivial. >>> >>> Too bad... unless someone wants to have that fun and then share it with >>> the rest of us :-). It still strikes me as really odd that such basic and >>> clearly desirable functionality, available forever in other environments, >>> should be so hard to come by. >>> >>> -Lee >> >> -- >> -- >> 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. > -- -- 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.
