That looks really very nice. The reader macros are particularly nice
because it saves messing around with the structure of your code.
Phil
dgrnbrg writes:
> I'd like to point out a similar library I wrote for Clojure called
> spyscope: https://github.com/dgrnbrg/spyscope
>
> With spyscope, yo
Very cool, will have to try it out!
That said, I think we should start talking about how to make the traditional
debugging cycle accessible in Clojure.
On Friday, May 31, 2013 at 8:27 AM, dgrnbrg wrote:
> I'd like to point out a similar library I wrote for Clojure called spyscope:
> https:/
I'd like to point out a similar library I wrote for Clojure called
spyscope: https://github.com/dgrnbrg/spyscope
With spyscope, you can write a handful of characters and get the stack
frame, form, and its value pretty-printed and logged to a queue for future
querying.
On Thursday, May 30, 2013
That's true -- that's why I wrote up the Letters debugging mini-library for
Ruby (lettersrb.com). However, there's friction there, too, and a surprising
number of people don't think to do this.
On Thursday, May 30, 2013 at 5:25 PM, Timothy Baldridge wrote:
> Not really true, most of my progr
Not really true, most of my programs contain this function:
(defn debug [x]
(pprint x)
x)
Now I can do this:
(comp foo debug bar)
Also, with some reader literal magic, I could write something to let me do
this:
(myfunc foo #dbg bar)
On Thu, May 30, 2013 at 6:12 PM, David Jacobs wrote:
Two more things:
1) printing is often not a viable option for lazily eval-ed sequences or
async processes -- the output gets jumbled! And believe me, when a new
Clojure dev sees that for the first time, he/she wants to quit.
2) printing is terrible for elegant clojure code -- thing (comp f g h
for a long time haskell did not have a debugger. that sucked, imho.
--
--
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 wi
I'm just catching up on this discussion. I think that, regardless of
whether any one coder uses them, debuggers are useful to a large subset of
people. Even though Clojure likes us to be immutable, there are often times
where we would like to debug the mutable parts of our code with something
b
On Wed May 29 09:18:10 2013, Softaddicts wrote:
The REPL is a better alternative than a debugger. No REPL available = increase
need for
a debugger.
If you write creepy code in the REPL, you would do the same in a text editor
and then
end up debugging it in the debugger... with the old fail/edi
The REPL is a better alternative than a debugger. No REPL available = increase
need for
a debugger.
If you write creepy code in the REPL, you would do the same in a text editor
and then
end up debugging it in the debugger... with the old fail/edit/build/break to
point of
failure cycle.
It's
I did not say that a debugger was not useful at all, I said that the
> importance of having a
> debugger is *overestimated* especially in an immutable world.
>
> Relying on a debugger as an important tool to support coding is like
> admitting
> the failure of your code before it runs. It's l
+1
On 2013-5-29, at 上午2:23, Warren Lynn wrote:
>
> Still miss the Elisp debugger, which is great. It's right there, in your
> editing environment. It's good for debugging my own code. It's really
> good for working out someone elses code. I wish I debug clojure in the
> same way. It's not ess
Warren Lynn writes:
>> Still miss the Elisp debugger, which is great. It's right there, in your
>> editing environment. It's good for debugging my own code. It's really
>> good for working out someone elses code. I wish I debug clojure in the
>> same way. It's not essential, of course. But nic
One technique I've used in the past for debugging is to open a UDP
port as a log stream and print messages to that stream. These messages
can be read at any time by a telnet connection to that port.
Since UDP packets that are not read just get dropped this is equivalent
to writing to /dev/null exc
A couple more replies to comments on this thread:
On May 28, 2013, at 5:50 PM, Cedric Greevey wrote:
>
> 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 r
On May 28, 2013, at 5:10 PM, Alan Malloy wrote:
>
> 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, th
On Tue, May 28, 2013 at 1:35 PM, Softaddicts
wrote:
> I came to the same conclusion as Stuart after 30+ years of coding in various
> languages/assemblers and architectures.
Interesting thread and I find myself in agreement with Luc here. I've
been programming commercially for about 30 years and I
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. Design
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 :
On May 28, 2013, at 4:01 PM, Ben Mabey wrote:
>
> 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
I maintain the strategies summarized by Stuart are a better alternative
than repetitive debugging sessions because they change the core of how you are
thinking about design and coding, forcing you to have a broader view
about how you are doing things and preventing problems before
they appear.
I
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 progra
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
On May 28, 2013, at 2:38 PM, Cedric Greevey wrote:
> What about logging aggressively but also aggressively dumping older log
> entries? Keep only, say, the last 100 or 1000 entries. Something like: [etc.]
Thanks Cedric. That does indeed seem feasible. In my applications, for example,
I might a
On 5/28/13 12:19 PM, Lee Spector wrote:
On May 28, 2013, at 2:16 PM, Ben Mabey wrote:
You can disable locals clearing with a compiler flag. nrepl-ritz even has
helper function that will compile the given form using that flag. If you want
to disable locals clearing on a project wide basis you
What about logging aggressively but also aggressively dumping older log
entries? Keep only, say, the last 100 or 1000 entries. Something like:
(def logger (atom nil))
(def max-log-entries 1000)
(def log-file whatever)
(defn log [msg]
(swap! logger
(fn [oldlog]
(let [newlog (doall (t
> Still miss the Elisp debugger, which is great. It's right there, in your
> editing environment. It's good for debugging my own code. It's really
> good for working out someone elses code. I wish I debug clojure in the
> same way. It's not essential, of course. But nice.
>
> Phil
>
I miss
On May 28, 2013, at 2:16 PM, Ben Mabey wrote:
>
> You can disable locals clearing with a compiler flag. nrepl-ritz even has
> helper function that will compile the given form using that flag. If you
> want to disable locals clearing on a project wide basis you can do so with
> lein's JVM opt
I did a fair amount of programming in C# before switching to Clojure. I
noticed an interesting fact: the more lazy (as in using lazy-seqs) and
functional my code became, the more erratic the was the flow of execution.
It's my personal opinion, that as these features are used more and more in
a prog
On May 28, 2013, at 12:37 PM, Cedric Greevey wrote:
>
> I think locals clearing is simply incompatible with ever having full debug
> info at an error site without anticipation of an error at that site, and with
> anticipation you can put debug prints, logging, watchers, and suchlike at the
> s
On 5/28/13 10:37 AM, Cedric Greevey wrote:
Huh. I just solved it. The debug exception handler has to do something
a bit fancier, that's all:
1. Dig up the bytecode of the method executing the throw and copy it
somewhere.
2. Unwind by one call.
3. Take the bytecode in 1, alter it to wrap the t
May I suggest that as useful as your strategies are, they cannot replace a
debugger? Let's be clear about our logic before claiming "it is not much
needed". Maybe YOU really don't need it, but that is different from
claiming it is not needed.
A debugger as good as it is cannot replace the 4 fi
Huh. I just solved it. The debug exception handler has to do something a
bit fancier, that's all:
1. Dig up the bytecode of the method executing the throw and copy it
somewhere.
2. Unwind by one call.
3. Take the bytecode in 1, alter it to wrap the throw site in
redl.core/break's macro expansion t
On Tue, May 28, 2013 at 9:36 AM, Lee Spector wrote:
>
> On May 28, 2013, at 8:43 AM, dgrnbrg wrote:
> > There's not much you can do to retrieve the locals around an exception
> with adding a Java Agent. REDL is able to get the locals around uses of
> redl.core/break, since it's a macro and that's
On May 28, 2013, at 10:32 AM, Rostislav Svoboda wrote:
> This might not be the proper example: If (/ 2 n) throws "Divide by
> zero" then "n == zero"
Well yes of course it's obvious what the problem is in this case!
The point is that if the "bad" function was more complicated then might help to
This might not be the proper example: If (/ 2 n) throws "Divide by
zero" then "n == zero"
On 28 May 2013 15:40, Lee Spector wrote:
>
> On May 27, 2013, at 8:31 PM, Charles Harvey III wrote:
>> If you haven't tried out Light Table, it shows you the values of local
>> variables. It is a pretty nic
On May 27, 2013, at 8:31 PM, Charles Harvey III wrote:
> If you haven't tried out Light Table, it shows you the values of local
> variables. It is a pretty nice feature.
>
I love the ideas behind LightTable and I check it out from time to time.
Checking it out now, though, regarding this issu
On May 28, 2013, at 8:43 AM, dgrnbrg wrote:
> There's not much you can do to retrieve the locals around an exception with
> adding a Java Agent. REDL is able to get the locals around uses of
> redl.core/break, since it's a macro and that's an ability of macros.
In Common Lisp exceptions are han
There's not much you can do to retrieve the locals around an exception with
adding a Java Agent. REDL is able to get the locals around uses of
redl.core/break, since it's a macro and that's an ability of macros.
On Monday, May 27, 2013 10:10:39 PM UTC-4, Lee wrote:
>
>
> On May 27, 2013, at 9:54
Oskar Kvist writes:
> Stuart Halloway said in his video Clojure in the Field (
> http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I
> think): "I don't feel the absence of a debugger because I've learnt enough
> that I don't ever need a debugg
I'm not sure what your point is.
I rely quite a bit on randomly generated tests, and of course, any
multithreaded app has nondeterministic elements that can be hard to
replicate.
For that matter, if you are simply experimenting with new code at the REPL,
it might not always be clear what sequence
You have production code going *boom* that doesn't have any failing tests?
Or you have nondeterministic tests? :)
On Tue, May 28, 2013 at 1:49 AM, Mark Engelberg wrote:
> On Mon, May 27, 2013 at 10:25 PM, Cedric Greevey wrote:
>
>> What about add-watch? Can be used with any of Clojure's mutable-
On Mon, May 27, 2013 at 10:25 PM, Cedric Greevey wrote:
> What about add-watch? Can be used with any of Clojure's mutable-value
> containers -- atoms, refs, agents, vars. If one is getting set to an
> inappropriate value, or you suspect it is, you can attach a watcher to it
> that will emit a log
On Mon, May 27, 2013 at 5:39 PM, u1204 wrote:
> The REPL is your best friend. You can "hand execute" small pieces of
> code to test your assumptions.
>
> Common Lisp systems have wonderfully powerful trace functions allowing
> arbitrary conditions and actions.
>
> I haven't seen anything like tha
If you haven't tried out Light Table, it shows you the values of local
variables. It is a pretty nice feature.
On Monday, May 27, 2013 5:53:16 PM UTC-4, puzzler wrote:
>
> I would be a lot happier with the state of Clojure debugging if, in
> addition to a stacktrace, I could easily explore the
On May 27, 2013, at 9:54 PM, Softaddicts wrote:
> Lets take a real life example, [etc.]
>
> Debugging was not a viable option. [etc.]
>
> This project was extreme in this regard but it prove to me that reviewing
> code offline
> and thinking about how to improve it gives much more payback than
Lets take a real life example, I had to design a backup system to take
over when a master quote feed made of several individual feeds failed.
My backup system had access to same raw feeds as the master system using
serial lines but there were no guarantee that both systems would receive the
raw f
k): "I don't feel the absence of a debugger because I've learnt enough
> that I don't ever need a debugger." I am very intrigued by that statement.
> What does he (or you, if you are reading, Stuart) mean? For me, debugging
> is the biggest thing that I don'
On May 27, 2013, at 5:53 PM, Mark Engelberg wrote:
> I would be a lot happier with the state of Clojure debugging if, in addition
> to a stacktrace, I could easily explore the local variables in play when an
> error was triggered. It was possible to do this in earlier Clojure
> environments,
Monday, May 27, 2013 2:34:23 PM UTC-4, Oskar Kvist wrote:
>
> Stuart Halloway said in his video Clojure in the Field (
> http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I
> think): "I don't feel the absence of a debugger because I've learnt enough
e clojure, a live repl can fill the role (and
> then some) of a debugger.
>
> I personally can't speak to vim integration, don't use it with clojure.
>
>
>
>
>
>
>
>
>
>
> On Mon, May 27, 2013 at 2:34 PM, Oskar Kvist wrote:
>
> > Stuart Hall
Yes and no. nrepl ritz lags behind slime, especially in areas such as
breakpoints and inspection.
On Mon, May 27, 2013 at 3:22 PM, David Nolen wrote:
> Doesn't ritz support nrepl? http://github.com/pallet/ritz
>
>
> On Mon, May 27, 2013 at 5:53 PM, Mark Engelberg
> wrote:
>
>> I would be a lot
Doesn't ritz support nrepl? http://github.com/pallet/ritz
On Mon, May 27, 2013 at 5:53 PM, Mark Engelberg wrote:
> I would be a lot happier with the state of Clojure debugging if, in
> addition to a stacktrace, I could easily explore the local variables in
> play when an error was triggered. It
I would be a lot happier with the state of Clojure debugging if, in
addition to a stacktrace, I could easily explore the local variables in
play when an error was triggered. It was possible to do this in earlier
Clojure environments, but the capability seems to have been lost in the
transition to
>Stuart Halloway said in his video Clojure in the Field (
>http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I
>think): "I don't feel the absence of a debugger because I've learnt enough
>that I don't ever need a debugger." I am very intrig
n the Field (
> http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I
> think): "I don't feel the absence of a debugger because I've learnt enough
> that I don't ever need a debugger." I am very intrigued by that statement.
> What does he (or yo
Stuart Halloway said in his video Clojure in the Field (
http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I
think): "I don't feel the absence of a debugger because I've learnt enough
that I don't ever need a debugger." I am very intrigued by that sta
57 matches
Mail list logo
