Re: Step by step debugging

I would imagine that cinc could side-step any jvm-imposed limitations on developing a reference debugger for clojure. -- -- 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 fr

Re: Step by step debugging

Colin, Got it--this setting is relevant to use of a debugger. I was trying to see something from vanilla and Leiningen repls. Thank you for taking so much time to explain. (My current debugger is (print (format ...)). Have to upgrade.) -Marshall On Wednesday, November 13, 2013 5:16:27 PM

Re: Step by step debugging

Hi Marshall, You'll only see a difference due to locals clearing if you're stepping with a debugger and looking at locals in your local stack frame or in the frames above it. In your example, the ability to pause when an exception is thrown is a capability your debugger provides. Cursive does prov

Re: Step by step debugging

Thanks Colin! Wow--that's extremely helpful. The concepts are very clear now, and I now understand that it's a map *compiler-options* is supposed to be set to. What I was trying before wasn't right. No matter what I do, I am not seeing an effect on the value of *compiler-options* from the co

Re: Step by step debugging

Hi Marshall, Sure. Clojure implements locals clearing, which means that the compiler will set local variables to null when it knows that the value of those variables won't be used any more. This allows the garbage collector to reclaim any values that those variables were pointing to, which is part

Re: Step by step debugging

Hi Ryan, Ryan Spangler writes: > I'll have an official announcement once it is ready to be released, > but until then I welcome any feedback. I don't have time to test experimental stuff right now but I'm very much looking forward to reading your announcement! Thanks to tacking this. Best, -

Re: Step by step debugging

Lee, Thank you for pointing that out! The README has been updated with more explicit instructions. For those who don't know, to open a dt_socket from your project.clj simply add this line: :jvm-opts ["-agentlib:jdwp=transport=dt_socket,server=y,suspend=n"] Schmetterling is still very ne

Re: Step by step debugging

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 whe

Re: Step by step debugging

On Tuesday, November 12, 2013 11:15:11 PM UTC-6, Mars0i wrote: > > ... 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

Re: Step by step debugging

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

Re: Step by step debugging

Very excited by this. Thanks also to Justin for the pointer. >From my perspective a particularly nice additional would be to provide minimal >instructions on how to get this running for people who don't know (or >necessarily want to have to know) what a dt_socket is. On Nov 12, 2013, at 7:11

Re: Step by step debugging

>> 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 :-) I have started a project that does this: a browser based debugger that breaks on exceptions (it attaches to a dt_socket port): https://github.c

Re: Step by step debugging

Cedric, you're right in both your assessment of the potential solution (this could definitely be done) and also the problems. You'd need an additional line number mapping of original source line to expanded-lines source line to be able to make any sense of stack traces, thread dumps etc, and of cou

Re: Step by step debugging

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 functio

Re: Step by step debugging

As far as I can see, though ritz is not Emacs specific per se. It's a set of middleware for nrepl. So you should be able to build clients against it for different environments, including a textual one. There's no reason that a debugger shouldn't be part of lein. I think making it work with java -j

Re: Step by step debugging

On Thursday, November 7, 2013 6:32:29 PM UTC+1, Lee wrote: > > > 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 > us

Re: Step by step debugging

This JVMTI doesn't know Clojure source code from parsnip soup, I expect, so can't it be fooled into "thinking" that the bytecode it's interpreting came from a source with many more, shorter lines? So (defn x [y z] (a (b (c)) ((d) e (f g could be passed off to it as if it were (defn x

Re: Step by step debugging

Right, sadly I believe this is impossible using JVMTI, although I'm far from an expert. On 8 November 2013 18:51, Cedric Greevey wrote: > 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 > expressi

Re: Step by step debugging

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 wrote: > I'm slightly late to the discussion, sorry - currently moving cities. > Cursive doe

Re: Step by step debugging

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

Re: Step by step debugging

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

Re: Step by step debugging

+1 well said, 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 whate

Re: Step by step debugging

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 gen

Re: Step by step debugging

I don't know yet, since what I have in mind at the moment is based on vague pattern matching of words rather than on knowledge of how Ritz works. :-) My basic idea was simply that the Ritz nrepl stuff only works in Emacs now, but it does work across an nREPL connection between a client and the JVM

Re: Step by step debugging

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. 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.or

Re: Step by step debugging

+1 Rudi Engelbrecht Mobile: +61 (0) 455 500 369 Voice: +61 (0) 2 8091 5554 Voice: +27 (0) 11 083 7774 Email: r...@engelbrecht.me > On 8 Nov 2013, at 8:29, Lee Spector wrote: > > > Andy, > > I do think that if a debugging feature has to be limited to a particular > environment then Leiningen

Re: Step by step debugging

What would I need to do to get it to not only retain locals but also show them to me when I hit an error? -Lee On Nov 7, 2013, at 4:22 PM, Alex Miller wrote: > I believe the locals are actually *not* available because they are > proactively cleared to help GC. > > Setting the *compiler-op

Re: Step by step debugging

Andy, I do think that if a debugging feature has to be limited to a particular environment then Leiningen would be preferable to any other, since it's so simple to install and use (and maybe most people have it anyway?) that people who use other environments could, without too much trouble, do

Re: Step by step debugging

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

Re: Step by step debugging

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 ge

Re: Step by step debugging

Hi Lee, you made me cry (almost). I've been working in the eighties on Lisp Machine (both Symbolics and Texas Instruments) and I still have to see a programming environment comparable to the one I was using 30 years ago. At the moment we're still far way from those happy days. Well written!

Re: Step by step debugging

There is redl which does some of this too, that's more for the vim workflow though On Thursday, November 7, 2013, Phillip Lord wrote: > > > 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 a

Re: Step by step debugging

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

Re: Step by step debugging

There is redl which does some of this too, that's more for the vim workflow though On Thursday, November 7, 2013, Phillip Lord wrote: > > > 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 a

Re: Step by step debugging

Not to my knowledge. (if anyone wants to make one, that would be useful hint hint) I would try asking on the CCW list at https://groups.google.com/forum/#!msg/clojuredev-users/ for help on the CCW/Eclipse debugger. For Cursive, there is some info at http://cursiveclojure.com/userguide/repl.html o

Re: Step by step debugging

Hi Alex, Alex Miller writes: > If you're willing to look outside of Emacs *shock* *horror*, both > Eclipse CCW and IntelliJ Cursive have debuggers that work to some > degree with Clojure. I love testing new tools, I did not sign a life-time contract with any software ;) Is there a video somew

Re: Step by step debugging

If you're willing to look outside of Emacs *shock* *horror*, both Eclipse CCW and IntelliJ Cursive have debuggers that work to some degree with Clojure. On Thursday, November 7, 2013 3:16:17 AM UTC-6, Bastien Guerry wrote: > > I'm a big fan of edebug, the Emacs debugger, which allows step throu

Re: Step by step debugging

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. W

Re: Step by step debugging

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. Phil Bastien writes: > I'm a big fan of edebug, the Emacs d

Re: Step by step debugging

Hi Juan, "juan.facorro" writes: > I think Ritz [1] might be what you are looking for. Although I > haven't tried it myself yet, I recently saw the presentation "Ritz, > The Missing Clojure Tooling" and really liked what I saw. This seems great indeed, I'll watch the presentation carefully. Tha

Re: Step by step debugging

Hi Bastien, I think Ritz [1] might be what you are looking for. Although I haven't tried it myself yet, I recently saw the presentation "Ritz, The Missing Clojure Tooling" and really liked what I saw. HTH, J [1]: https://github.com/pallet/ritz [2]: http://w