Hi Ryan,
Ryan Spangler ryan.spang...@gmail.com 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
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
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
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
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
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
, November 7, 2013 1:16:17 AM UTC-8, Bastien Guerry wrote:
I'm a big fan of edebug, the Emacs debugger, which allows step through
debugging (and breakpoints, and some more fun.)
Is there anything similar for Clojure?
For example, from an Emacs (cider) REPL, I'd evaluate some Clojure
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
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
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
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
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 new
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
useful
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
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
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
I'm a big fan of edebug, the Emacs debugger, which allows step through
debugging (and breakpoints, and some more fun.)
Is there anything similar for Clojure?
For example, from an Emacs (cider) REPL, I'd evaluate some Clojure
expression, then a window would let me go through a buffer containing
://www.infoq.com/presentations/ritz-clojure
On Thursday, November 7, 2013 5:16:17 PM UTC+8, Bastien Guerry wrote:
I'm a big fan of edebug, the Emacs debugger, which allows step through
debugging (and breakpoints, and some more fun.)
Is there anything similar for Clojure?
For example, from
Hi Juan,
juan.facorro juan.faco...@gmail.com 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
of edebug, the Emacs debugger, which allows step through
debugging (and breakpoints, and some more fun.)
Is there anything similar for Clojure?
For example, from an Emacs (cider) REPL, I'd evaluate some Clojure
expression, then a window would let me go through a buffer containing
a copy
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.
Well,
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
Hi Alex,
Alex Miller a...@puredanger.com 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
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
advantage of running your editor and whatever you are
debugging in the environment.
Phil
Bastien bastiengue...@gmail.com javascript:; writes:
I'm a big fan of edebug, the Emacs debugger, which allows step through
debugging (and breakpoints, and some more fun.)
Is there anything similar
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
advantage of running your editor and whatever you are
debugging in the environment.
Phil
Bastien bastiengue...@gmail.com javascript:; writes:
I'm a big fan of edebug, the Emacs debugger, which allows step through
debugging (and breakpoints, and some more fun.)
Is there anything similar
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!
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 get
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
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,
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
+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 lspec...@hampshire.edu wrote:
Andy,
I do think that if a debugging feature has to be limited to a particular
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 -
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
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
+1
well said, Lee.
philli...@newcastle.ac.uk javascript: (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
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
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
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.comwrote:
I'm slightly late to the discussion, sorry - currently
Right, sadly I believe this is impossible using JVMTI, although I'm far
from an expert.
On 8 November 2013 18:51, Cedric Greevey cgree...@gmail.com 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
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
42 matches
Mail list logo
