Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Phillip Lord]

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, 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 8:28:19 PM UTC-4, David Jacobs wrote:
>>
>> 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 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 
>> > (mailto:
>> da...@wit.io )> 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 
>> (partial map z)) -- in order to figure out anything about dynamic data 
>> flowing through, you have to break apart that composition or add a let 
>> binding in one of those functions before returning a value. Both of those 
>> involve a lot of friction. 
>> > >   
>> > >   
>> > > On Thursday, May 30, 2013 5:00:13 PM UTC-7, raould wrote: 
>> > > > 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 
>> > > clo...@googlegroups.com(mailto:
>> clo...@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+u...@googlegroups.com  (mailto:
>> clojure%2b...@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+u...@googlegroups.com  (mailto:
>> clojure%2b...@googlegroups.com ). 
>> > > For more options, visit https://groups.google.com/groups/opt_out. 
>> > >   
>> > >   
>> >   
>> >   
>> >   
>> >   
>> > --   
>> > “One of the main causes of the fall of the Roman Empire was that–lacking 
>> zero–they had no way to indicate successful termination of their C 
>> programs.” 
>> > (Robert Firth)   
>> >   
>> > --   
>> > --   
>> > You received this message because you are subscribed to the Google 
>> > Groups "Clojure" group. 
>> > To post to this group, send email to 
>> > clo...@googlegroups.com(mailto:
>> clo...@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+u...@googlegroups.com  (mailto:
>> clojure+u...@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+u...@googlegroups.com  (mailto:
>> clojure+u...@googlegroups.com ). 
>> > For more options, visit https://groups.google.com/groups/opt_out. 
>> >   
>> >   
>>
>>
>>
>>
>
> -- 

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
-- 
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 r

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[David Jacobs]

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://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 8:28:19 PM UTC-4, David Jacobs wrote:
> > That's true -- that's why I wrote up the Letters debugging mini-library for 
> > Ruby (lettersrb.com (http://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 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  > > (mailto:da...@wit.io)> 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 
> > > > (partial map z)) -- in order to figure out anything about dynamic data 
> > > > flowing through, you have to break apart that composition or add a let 
> > > > binding in one of those functions before returning a value. Both of 
> > > > those involve a lot of friction.  
> > > >
> > > >
> > > > On Thursday, May 30, 2013 5:00:13 PM UTC-7, raould wrote:  
> > > > > 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 clo...@googlegroups.com 
> > > > (mailto:clo...@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+u...@googlegroups.com (mailto:clojure%2b...@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+u...@googlegroups.com 
> > > > (mailto:clojure%2b...@googlegroups.com).  
> > > > For more options, visit https://groups.google.com/groups/opt_out.  
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > “One of the main causes of the fall of the Roman Empire was that–lacking 
> > > zero–they had no way to indicate successful termination of their C 
> > > programs.”  
> > > (Robert Firth)
> > >
> > > --
> > > --
> > > You received this message because you are subscribed to the Google  
> > > Groups "Clojure" group.  
> > > To post to this group, send email to clo...@googlegroups.com 
> > > (mailto:clo...@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+u...@googlegroups.com (mailto:clojure+u...@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+u...@googlegroups.com 
> > > (mailto:clojure+u...@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 unsub

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[dgrnbrg]

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 8:28:19 PM UTC-4, David Jacobs wrote:
>
> 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 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 
> > (mailto:
> da...@wit.io )> 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 
> (partial map z)) -- in order to figure out anything about dynamic data 
> flowing through, you have to break apart that composition or add a let 
> binding in one of those functions before returning a value. Both of those 
> involve a lot of friction. 
> > >   
> > >   
> > > On Thursday, May 30, 2013 5:00:13 PM UTC-7, raould wrote: 
> > > > 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 
> > > clo...@googlegroups.com(mailto:
> clo...@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+u...@googlegroups.com  (mailto:
> clojure%2b...@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+u...@googlegroups.com  (mailto:
> clojure%2b...@googlegroups.com ). 
> > > For more options, visit https://groups.google.com/groups/opt_out. 
> > >   
> > >   
> >   
> >   
> >   
> >   
> > --   
> > “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.” 
> > (Robert Firth)   
> >   
> > --   
> > --   
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to 
> > clo...@googlegroups.com(mailto:
> clo...@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+u...@googlegroups.com  (mailto:
> clojure+u...@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+u...@googlegroups.com  (mailto:
> clojure+u...@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.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[David Jacobs]

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 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  (mailto:da...@wit.io)> 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 
> > (partial map z)) -- in order to figure out anything about dynamic data 
> > flowing through, you have to break apart that composition or add a let 
> > binding in one of those functions before returning a value. Both of those 
> > involve a lot of friction.
> >  
> >  
> > On Thursday, May 30, 2013 5:00:13 PM UTC-7, raould wrote:
> > > 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 
> > (mailto: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 
> > (mailto: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 unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+unsubscr...@googlegroups.com 
> > (mailto:clojure%2bunsubscr...@googlegroups.com).
> > For more options, visit https://groups.google.com/groups/opt_out.
> >  
> >  
>  
>  
>  
>  
> --  
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C programs.”
> (Robert Firth)  
>  
> --  
> --  
> 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 
> (mailto: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 
> (mailto: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 
> (mailto: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.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Timothy Baldridge]

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
> (partial map z)) -- in order to figure out anything about dynamic data
> flowing through, you have to break apart that composition or add a let
> binding in one of those functions before returning a value. Both of those
> involve a lot of friction.
>
>
> On Thursday, May 30, 2013 5:00:13 PM UTC-7, raould wrote:
>>
>> 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 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.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[David Jacobs]

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 
(partial map z)) -- in order to figure out anything about dynamic data 
flowing through, you have to break apart that composition or add a let 
binding in one of those functions before returning a value. Both of those 
involve a lot of friction.

On Thursday, May 30, 2013 5:00:13 PM UTC-7, raould wrote:
>
> 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 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.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Raoul Duke]

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[David Jacobs]

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 
better than a print statement. (Importantly, it's more efficient to 
identify a problem spot in code if you can dynamically change what you're 
interested in as you get feedback from a REPL -- this is something print 
statements can't do. Print statements often have to be brute-force if you 
aren't exactly sure what to print.)

If we want Clojure to continue to be adopted, we need to support the habits 
of Web developers. And Web developers expect to:

1. Spot a problem spot in the code
2. Add the word "debugger/debug" at that spot (or make a breakpoint in an 
IDE)
3. Make the API call/run the spec/refresh the page/click the button
4. Immediately be in a debugger REPL where they can explore the environment

While it doesn't solve all problems, and while the more advanced we are, 
(perhaps) the sooner we can spot errors without a debugger, the fact is 
that a debugger is part of the standard workflow for many people. The 
essential thing is that a debugger quickly loads an execution context into 
your working memory. Instead of having to think about it for a while, you 
get immediate feedback about what's going wrong (nesting level is too high, 
that function doesn't return what you think it does, etc) and can jump into 
a new codebase easily.

So both for adoption and for a quick identify-debug-fix cycle (not all of 
us can afford hammock time for each and every bug that crops up in the 
code), I think it's important that we start thinking about creating and 
documenting debugging tools for the community.

Tangent: I don't see any documentation for inserting a debug REPL using 
Ritz. Anyone have any pointers? Does Ritz actually give me what I described 
earlier?

Best,
David

On Wednesday, May 29, 2013 8:56:08 AM UTC-7, Ben Mabey wrote:
>
> 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/edit/build/break to point of 
> > failure cycle. 
> > 
> > It's not the same goals and efficiency. Maybe the following will shed 
> some light. 
> > 
> > My REPL's main usage is to tinker with my code in a name space until 
> it's resilient and 
> > composable as much as possible. I rarely use the REPL to test short 
> snippets. 
> > My code is always backed by the name space I am working with. 
> > 
> > I seldom write unit tests. I make use of pre and post conditions as much 
> as possible 
> > to knock the rough edges off. 
> > 
> > I run integrated tests starting from a root name space (whichever is 
> appropriate for the 
> > scope oftest to be done) where I may have to establish some base 
> context. 
> > I exercise the code, I can trace/untrace calls, redef fns when needed 
> and so on without 
> > restarts. 
> > 
> > This insures a minimally resilient code base. 
> > 
> > When a severe error occurs, our logging facility dumps also the 
> environment 
> > with all the current bindings in scope where the exception was trapped. 
> > We can log bindings up to the top of the call stack... 
> > 
> > This is usable (as clojure maps) to reconstruct the call context and 
> rerun the 
> > culprit chunk of code to pinpoint were are the shortcomings that made it 
> fail. 
> > When running full integrated tests, we have access to this data. 
> > 
> > This is also available from production, we then obtain data to reinject 
> in dev to 
> > understand what happened with a limited wiring to establish the global 
> context. 
> > We can then reflect this our integrated tests to stress the code. 
> > 
> > This is more or less easy depending on the code that failed based on 
> > how much side effects are impacting the context. 
> > 
> > The more you use pure fns, the easier it is to rerun failures from the 
> appropriate 
> > call site and fix them. 
> > The more composable your code is, the less bugs you end up with, fns are 
> smaller, 
> > their scope is smaller, ... 
> > 
> > When I trigger a debugger it's because I hit a strange error from the 
> > Clojure compiler that I do not understand upfront or when I deal with 
> interop code 
> > and I need to look at the exception and internal states of Java objects 
> in situ. 
> > I never need to look at Clojure bindings in the debugger aside from the 
> obscure 
> > compilation errors I may hit. 
> > 
> > I became much more efficient swapping my time spent in a debugger by 
> time 
> > spent in the REPL. This is the bottom line and I am convinced from 
> comments 
> > I got from colleagues well versed in the use of debugg

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Ben Mabey]

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/edit/build/break to 
point of
failure cycle.

It's not the same goals and efficiency. Maybe the following will shed some 
light.

My REPL's main usage is to tinker with my code in a name space until it's 
resilient and
composable as much as possible. I rarely use the REPL to test short snippets.
My code is always backed by the name space I am working with.

I seldom write unit tests. I make use of pre and post conditions as much as 
possible
to knock the rough edges off.

I run integrated tests starting from a root name space (whichever is 
appropriate for the
scope oftest to be done) where I may have to establish some base context.
I exercise the code, I can trace/untrace calls, redef fns when needed and so on 
without
restarts.

This insures a minimally resilient code base.

When a severe error occurs, our logging facility dumps also the environment
with all the current bindings in scope where the exception was trapped.
We can log bindings up to the top of the call stack...

This is usable (as clojure maps) to reconstruct the call context and rerun the
culprit chunk of code to pinpoint were are the shortcomings that made it fail.
When running full integrated tests, we have access to this data.

This is also available from production, we then obtain data to reinject in dev 
to
understand what happened with a limited wiring to establish the global context.
We can then reflect this our integrated tests to stress the code.

This is more or less easy depending on the code that failed based on
how much side effects are impacting the context.

The more you use pure fns, the easier it is to rerun failures from the 
appropriate
call site and fix them.
The more composable your code is, the less bugs you end up with, fns are 
smaller,
their scope is smaller, ...

When I trigger a debugger it's because I hit a strange error from the
Clojure compiler that I do not understand upfront or when I deal with interop 
code
and I need to look at the exception and internal states of Java objects in situ.
I never need to look at Clojure bindings in the debugger aside from the obscure
compilation errors I may hit.

I became much more efficient swapping my time spent in a debugger by time
spent in the REPL. This is the bottom line and I am convinced from comments
I got from colleagues well versed in the use of debuggers that it's not a 
personal and
unique experience. Everyone of them when they saw what can be done in a REPL
were salivating to the idea of tossing debuggers aside.



Yes, but a REPL and a debugger are not mutually exclusive.  Nice 
debuggers for dynamic languages give you a REPL at breakpoints with all 
the context to evaluate expressions against.  In other words, why not 
have your cake and eat it too? :)  Clojure has this somewhat with 
nrepl-ritz evaluation commands (I imagine hooking up an actual repl 
wouldn't be too hard) and technomany's limit-break[1].


I think what this thread has shown is that a subset of the Clojure 
community would like better debugger support.  Repeated arguments on 
why they don't need debugger support isn't constructive since this is 
their personal opinion and development preference.  I think this thread 
has also shown that some people are not aware of the fantastic work 
Hugo Duncan and others have done for debuggers in Clojure.  To help 
with the awareness issue I think having a clojure-docs tutorial[2] on 
debugging would go a long ways.  As far as getting better support in 
general perhaps an ambitious member in the community could start a 
kickstarter to help improve the state of affairs.  I know my company 
would donate to a campaign to improve clojure debuggers.


-Ben

1. https://github.com/technomancy/limit-break  (I have never gotten 
limit-break to work for me though.)

2. https://github.com/clojuredocs/cds/issues/27

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Softaddicts]

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 not the same goals and efficiency. Maybe the following will shed some 
light.

My REPL's main usage is to tinker with my code in a name space until it's 
resilient and
composable as much as possible. I rarely use the REPL to test short snippets.
My code is always backed by the name space I am working with.

I seldom write unit tests. I make use of pre and post conditions as much as 
possible
to knock the rough edges off.

I run integrated tests starting from a root name space (whichever is 
appropriate for the 
scope oftest to be done) where I may have to establish some base context.
I exercise the code, I can trace/untrace calls, redef fns when needed and so on 
without 
restarts.

This insures a minimally resilient code base.

When a severe error occurs, our logging facility dumps also the environment
with all the current bindings in scope where the exception was trapped.
We can log bindings up to the top of the call stack...

This is usable (as clojure maps) to reconstruct the call context and rerun the
culprit chunk of code to pinpoint were are the shortcomings that made it fail.
When running full integrated tests, we have access to this data.

This is also available from production, we then obtain data to reinject in dev 
to
understand what happened with a limited wiring to establish the global context.
We can then reflect this our integrated tests to stress the code.

This is more or less easy depending on the code that failed based on
how much side effects are impacting the context.

The more you use pure fns, the easier it is to rerun failures from the 
appropriate
call site and fix them.
The more composable your code is, the less bugs you end up with, fns are 
smaller,
their scope is smaller, ...

When I trigger a debugger it's because I hit a strange error from the
Clojure compiler that I do not understand upfront or when I deal with interop 
code
and I need to look at the exception and internal states of Java objects in situ.
I never need to look at Clojure bindings in the debugger aside from the obscure
compilation errors I may hit.

I became much more efficient swapping my time spent in a debugger by time
spent in the REPL. This is the bottom line and I am convinced from comments
I got from colleagues well versed in the use of debuggers that it's not a 
personal and 
unique experience. Everyone of them when they saw what can be done in a REPL
were salivating to the idea of tossing debuggers aside.


Luc
> 
> 
> 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 like conceding defeat before 
> > the fight 
> > has started. 
> >
> > Trying to a avoid debug sessions as much as possible is more productive. 
> > Time spent in debug sessions is not spent on more important issues. 
> >
> > Luc P. 
> >
> >
> I found this kind of logic hard to swallow. I certainly don't look forward 
> to creating a lot of bugs so I can get the joy of using a debugger.  But 
> bugs, sometimes very tricky bugs happen, no matter how good your design is. 
> If you apply the logic that "because we can overuse/over rely on it so it 
> is better we don't have it at all" we almost don't need anything in the 
> modern life. Following your logic I would argue that if you don't have an 
> REPL, it will force you to think hard and write perfect code that does not 
> need any testing at all. It just runs, because you don't even have a second 
> chance to know what is going on inside and fix it. The quick REPL loop just 
> encourage people to write crappy code and constantly tinker with it 
> (because they know they can easily found out the cause and fix it). Does 
> that sound right to you?
> 
> We need to get our logic straight before debating this kind of issues.
> 
> -- 
> -- 
> 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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Warren Lynn]

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 like conceding defeat before 
> the fight 
> has started. 
>
> Trying to a avoid debug sessions as much as possible is more productive. 
> Time spent in debug sessions is not spent on more important issues. 
>
> Luc P. 
>
>
I found this kind of logic hard to swallow. I certainly don't look forward 
to creating a lot of bugs so I can get the joy of using a debugger.  But 
bugs, sometimes very tricky bugs happen, no matter how good your design is. 
If you apply the logic that "because we can overuse/over rely on it so it 
is better we don't have it at all" we almost don't need anything in the 
modern life. Following your logic I would argue that if you don't have an 
REPL, it will force you to think hard and write perfect code that does not 
need any testing at all. It just runs, because you don't even have a second 
chance to know what is going on inside and fix it. The quick REPL loop just 
encourage people to write crappy code and constantly tinker with it 
(because they know they can easily found out the cause and fix it). Does 
that sound right to you?

We need to get our logic straight before debating this kind of issues.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[xumingmingv]

+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 essential, of course. But nice. 
> 
> Phil 
> 
> I miss the Elisp debugger or Common Lisp debugger too. They made fixing an 
> issue so much easier. I think good REPL is a complement (and a very 
> important/good one) to it, not a replacement to it. I don't know if I gained 
> much (or any) if I got a good tool but lost another good one.
> 
> -- 
> -- 
> 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.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Phillip Lord]

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 nice. 
>>
>> Phil 
>>
>
> I miss the Elisp debugger or Common Lisp debugger too. They made fixing an 
> issue so much easier. I think good REPL is a complement (and a very 
> important/good one) to it, not a replacement to it. I don't know if I 
> gained much (or any) if I got a good tool but lost another good one.


Yeah, this is exactly what I feel. The elisp debugger is joy because
it's right there, in your editing environment and is very first class;
although if you are debugging the command loop this is a problem, but in
general it's fantastic.

I like the test environment in clojure, and although they exist in elisp
I never really use them; don't know why, just habit I guess. And yes, in
it's absence, I do lean on other tools instead. Still, it would be nice.

Phil


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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[u1204]

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 except when you want to watch what is begin
logged.

Since the values are printed they don't have to be kept.

You can even keep this live in a production environment for
dumping things like statistics. At Worldcom I used this to 
put up a "live console".

It might be possible to make a DEFTRACE macro to replace the DEFN
which prints the arguments and return values to the UDP port as in
   > enter (FOO "asdf" 3 'thing)
   < exit  (FOO 6)

When you connect to the UPD port you'll see an active trace, including
the arguments. If you set up a netcat listener on the port you can dump
the stream to a file and see the execution. If you're really slick you
can open a slime-like port to dump the trace to an emacs buffer.

Tim Daly


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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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 reasons anyway).

Sure, but in some kinds/styles of work this is more inconvenient / 
inappropriate than in others.


On May 28, 2013, at 6:08 PM, Sean Corfield wrote:
> 
> Mark's original point is well-made: the biggest "bang for our buck" is
> likely to come from exceptions being able to capture and automatically
> display all of the in-scope vars at the point of failure. Even with a 
> step debugger, you still have to reproduce the failure, often [etc]


I agree 100% with Sean and Mark that, from my perspective, the best thing to 
shoot for is some kind of display of locals at the point of an error. This was 
always crucial to me in Common Lisp (I never much used the stepper or the 
snazzy restart mechanism) and its absence in Clojure has been one of the main 
pain points of my transition to Clojure. I think this is true of my work as a 
programmer/researcher but also as a teacher; when something breaks, which is 
all the time with new programmers, you want to be able to look around and see 
what the state was that caused the error. You really want to see the values of 
locals, and in Common Lisp that was easy and obvious, while in Clojure it seems 
to be close to impossible.

It looks from Hugo's video like I can get this kind of functionality now if I 
run my code via emacs and use nrepl-ritz... although it sounds like this can 
lead to memory management problems, so that one shouldn't do it routinely (and 
plus I generally want to run my code in other ways). So, not optimal but a 
start. If there was a way to get locals to be displayed on error, without the 
restriction to emacs and without the performance issues, then I think that 
would be a big win for a lot of people.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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, the compiler makes sure that xs is available for GC as it is being 
> processed, so that the working-set size is small. If locals clearing is 
> disabled, the local reference xs is kept around in case a debugger wants to 
> look at it, and so the head of xs is being held while it is realized, meaning 
> a hundred-million-element range must be kept in memory until the function 
> call completes.
> 
> It's definitely useful to be able to disable locals-clearing temporarily 
> while debugging, but doing so in any kind of production app would be a 
> disaster.

Shouldn't it be possible, at least in principle, to retain only those things 
that could be referenced at the point of the error? In other words, if you can 
GC it under normal circumstances then go ahead and GC it. If you can't, then 
don't (of course), and when we hit an exception then we want to be able to see 
whatever is still around (or if that's hard for tails of lazy sequences or for 
any other reason, then punt on this stuff).

I obviously don't know the guts of the JVM, but I think that something like 
this is what's wanted.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Sean Corfield]

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 used a step
debugger back in the day with C and later C++ code but found myself
relying on it less and less over the years. I've used the step
debugger maybe three times with Clojure in the last three years, and
two of those occasions were more to see where the state of the art was
at, out of curiosity. I've hardly used step debuggers at all for the
last 15 years, since I moved to the JVM. Every now and then, I've
found a debugger to be very useful, but with the complexity of a lot
of software workflows these days, trying to hit the right breakpoints,
and step thru just the critical parts of the system, has become
increasingly difficult, compared to just adding tracing or logging at
various points.

Mark's original point is well-made: the biggest "bang for our buck" is
likely to come from exceptions being able to capture and automatically
display all of the in-scope vars at the point of failure. Even with a
step debugger, you still have to reproduce the failure, often
repeatedly, slowly zeroing in on the correct breakpoints in order to
analyze what caused it. The Ritz debugger, with the ability to break
on exception and display locals (if you've disabled locals clearing),
can be very helpful here but you still have to repro the failure -
which as several folks have said, is not at all easy in a complex
and/or non-deterministic system.

Worse, if the failure arises from bad data - or the failure is simply
"incorrect results" - then breaking on an exception won't help you
anyway, and you're back to painstakingly tracking thru code to find
where data went bad. Hammock time, careful human analysis, and
selective logging and tracing is more likely to yield results quicker
for less effort, in my opinion.

As is a comprehensive test suite :)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Cedric Greevey]

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. Designing
to minimize difficulty with reproducing any observed behavior seems to be
indicated (and desirable for other reasons anyway).


On Tue, May 28, 2013 at 5:10 PM, Alan Malloy  wrote:

> 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 :jvm-opts if you are using lein. This will, of 
>> course, slow down your program but when I've used it in the past it hasn't 
>> made it unusable for development.
>>
>>  Thanks for the project.clj specifics Ben.
>>
>> It still isn't clear to me if/how I could then look at the locals after 
>> hitting an unexpected exception. Perhaps Cedric's strategy described a 
>> couple of messages back (which I didn't fully understand) would work here? 
>> But from the lack of followup to this post 
>> http://comments.gmane.org/**gmane.comp.java.clojure.swank-**clojure.devel/106
>>   
>> -- I wonder if it still won't work when hitting unexpected exceptions.
>>
>>
>> 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 a nice presentation on it (
>> https://github.com/pallet/**ritz/tree/develop/nrepl#**
>> additional-resources).
>> If you aren't using emacs then I don't have any suggestions for you. :(
>>
>> Also, I guess I don't understand what locals clearing is in this context, 
>> but why would this slow things down? If it's just preventing the clearing of 
>> locals when handling an exception then I'd expect it to have no effect 
>> except during an exception... Do you mean that it'll slow down code that 
>> does a lot of "exception" handling in circumstances that aren't really 
>> exceptional? Or will this flag do something very different than what I'm 
>> thinking, like causing all locals everywhere to be retained forever? That'd 
>> cause problems worse than just slowdowns, I would think.
>>
>>  It would slow things down in that more things wouldn't be allowed to be
>> GCed as soon as they would be with locals clearing (the usual culprit being
>> lazy seqs).  Unfortunately,  I don't know enough of the details of how and
>> when locals clearing works to give you more details.  So I'd love to hear a
>> better explanation from someone who knows.
>>
>
> 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, the compiler makes sure that xs is available for GC as it
> is being processed, so that the working-set size is small. If locals
> clearing is disabled, the local reference xs is kept around in case a
> debugger wants to look at it, and so the head of xs is being held while it
> is realized, meaning a hundred-million-element range must be kept in memory
> until the function call completes.
>
> It's definitely useful to be able to disable locals-clearing temporarily
> while debugging, but doing so in any kind of production app would be a
> disaster.
>
> --
> --
> 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 bec

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Alan Malloy]

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 :jvm-opts if you are using lein. This will, of 
> course, slow down your program but when I've used it in the past it hasn't 
> made it unusable for development.
>
>  Thanks for the project.clj specifics Ben.
>
> It still isn't clear to me if/how I could then look at the locals after 
> hitting an unexpected exception. Perhaps Cedric's strategy described a couple 
> of messages back (which I didn't fully understand) would work here? But from 
> the lack of followup to this post 
> http://comments.gmane.org/gmane.comp.java.clojure.swank-clojure.devel/106 -- 
> I wonder if it still won't work when hitting unexpected exceptions.
>
>  
> 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 a nice presentation on it (
> https://github.com/pallet/ritz/tree/develop/nrepl#additional-resources).  
> If you aren't using emacs then I don't have any suggestions for you. :(
>  
> Also, I guess I don't understand what locals clearing is in this context, but 
> why would this slow things down? If it's just preventing the clearing of 
> locals when handling an exception then I'd expect it to have no effect except 
> during an exception... Do you mean that it'll slow down code that does a lot 
> of "exception" handling in circumstances that aren't really exceptional? Or 
> will this flag do something very different than what I'm thinking, like 
> causing all locals everywhere to be retained forever? That'd cause problems 
> worse than just slowdowns, I would think.
>
>  It would slow things down in that more things wouldn't be allowed to be 
> GCed as soon as they would be with locals clearing (the usual culprit being 
> lazy seqs).  Unfortunately,  I don't know enough of the details of how and 
> when locals clearing works to give you more details.  So I'd love to hear a 
> better explanation from someone who knows.
>

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, the compiler makes sure that xs is available for GC as it 
is being processed, so that the working-set size is small. If locals 
clearing is disabled, the local reference xs is kept around in case a 
debugger wants to look at it, and so the head of xs is being held while it 
is realized, meaning a hundred-million-element range must be kept in memory 
until the function call completes.

It's definitely useful to be able to disable locals-clearing temporarily 
while debugging, but doing so in any kind of production app would be a 
disaster.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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 a nice presentation on it 
> (https://github.com/pallet/ritz/tree/develop/nrepl#additional-resources).  If 
> you aren't using emacs then I don't have any suggestions for you. :(

I'm watching the video and it does look nice. Note to all of the nay-sayers: 
the crowd erupts in applause when he shows how it displays locals! (at around 
27:50... and again at 32:45 -- the crowd really likes seeing locals!)

So many reasons to switch to an emacs environment -- and so many reasons not to 
(principally, for me, the vacuum-tube-age handling of buffers/windows... 
although the complexities of installation and configuration, especially if you 
want menus etc., also keeps me from moving too far in this direction). (Yes, 
I've said this annoyingly many time before: It should be possible to combine 
the power of emacs with a modern GUI with windows that behave like any other 
windows, and OS-native keyboard/mouse/menu behavior, etc., as Macintosh Common 
Lisp did decades ago... I wish that the awesome tool developers in the Clojure 
community would see the value in doing this...)

> It would slow things down in that more things wouldn't be allowed to be GCed 
> as soon as they would be with locals clearing (the usual culprit being lazy 
> seqs).  Unfortunately,  I don't know enough of the details of how and when 
> locals clearing works to give you more details.  So I'd love to hear a better 
> explanation from someone who knows.

I would hope that things could still be GCed when you leave the scope but I 
know less than you do about how this works in Java.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Softaddicts]

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 came to the same conclusion as Stuart after 30+ years of coding in various 
languages/assemblers and architectures.

Debugger have been in use for more than 35 years and they never improved code
quality. They were used to patch specific narrow problems, not avoiding them at 
the root.

I had a colleague once that was writing code in hex directly in the debugger.
Nice and exotic but of little value considering that he had to reconstruct 
source
code afterward... and that he'd better not get his mainframe session 
disconnected
while patching his code.

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 like conceding defeat before the 
fight
has started.

Trying to a avoid debug sessions as much as possible is more productive.
Time spent in debug sessions is not spent on more important issues.

Luc P.

> 
> 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 first strategies. 
> >
> > Luc P. 
> >
> >
> >
> you to
> -- 
> -- 
> 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.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Ben Mabey]

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 program but when I've used it in the past it hasn't made it unusable for development.

Thanks for the project.clj specifics Ben.

It still isn't clear to me if/how I could then look at the locals after hitting 
an unexpected exception. Perhaps Cedric's strategy described a couple of 
messages back (which I didn't fully understand) would work here? But from the 
lack of followup to this post 
http://comments.gmane.org/gmane.comp.java.clojure.swank-clojure.devel/106 -- I 
wonder if it still won't work when hitting unexpected exceptions.


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 a nice presentation 
on it 
(https://github.com/pallet/ritz/tree/develop/nrepl#additional-resources). If 
you aren't using emacs then I don't have any suggestions for you. :(

|


Also, I guess I don't understand what locals clearing is in this context, but why would 
this slow things down? If it's just preventing the clearing of locals when handling an 
exception then I'd expect it to have no effect except during an exception... Do you mean 
that it'll slow down code that does a lot of "exception" handling in 
circumstances that aren't really exceptional? Or will this flag do something very 
different than what I'm thinking, like causing all locals everywhere to be retained 
forever? That'd cause problems worse than just slowdowns, I would think.
It would slow things down in that more things wouldn't be allowed to be 
GCed as soon as they would be with locals clearing (the usual culprit 
being lazy seqs).  Unfortunately,  I don't know enough of the details of 
how and when locals clearing works to give you more details.  So I'd 
love to hear a better explanation from someone who knows.


-Ben

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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 past it hasn't 
> made it unusable for development.

Thanks for the project.clj specifics Ben.

It still isn't clear to me if/how I could then look at the locals after hitting 
an unexpected exception. Perhaps Cedric's strategy described a couple of 
messages back (which I didn't fully understand) would work here? But from the 
lack of followup to this post 
http://comments.gmane.org/gmane.comp.java.clojure.swank-clojure.devel/106 -- I 
wonder if it still won't work when hitting unexpected exceptions.

Also, I guess I don't understand what locals clearing is in this context, but 
why would this slow things down? If it's just preventing the clearing of locals 
when handling an exception then I'd expect it to have no effect except during 
an exception... Do you mean that it'll slow down code that does a lot of 
"exception" handling in circumstances that aren't really exceptional? Or will 
this flag do something very different than what I'm thinking, like causing all 
locals everywhere to be retained forever? That'd cause problems worse than just 
slowdowns, I would think.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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 aggressively log everything but then clear it once per generation (of a 
genetic programming system).

Feasible, but a fair amount of project-specific engineering effort. Hard for me 
to say at this point if it'd be worth designing all of my systems with this in 
mind.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Ben Mabey]

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 can do so with lein's 
JVM opts.


Ooo this sounds promising... I'd love to know how to disable locals clearing 
for an entire project and then to dump all of the locals on error, if 
possible...

  -lee



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 past it 
hasn't made it unusable for development.



-Ben

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Cedric Greevey]

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 (take max-log-entries (cons msg oldlog)))]
(with-open [wr (writer-on log-file)]
  (binding [*out* wr]
(print newlog)))
newlog

...

(log "something interesting happened in foo.core/quux!")

...

BOOM!

...

; examine log-file for last 1000 messages produced before the crash

NOTE: yeah, there's a side effect in the swap! function. But it's
semantically idempotent! Whenever the swap! completes the contents of the
file equals the contents of the atom. So it just makes the atom durable. :)



On Tue, May 28, 2013 at 2:17 PM, Lee Spector  wrote:

>
> 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 site.
>
> Too bad, if that's really the final word. It's so very useful to get the
> locals at the point of (unanticipated) error, and this is information that
> is already "known" to the system... and we just want it not to throw it
> away.
>
> > The lesson for clojure developers being, strive for reproducibility! You
> should already be using lots of pure functions and few side-effecting ones,
> and your IDE should keep a REPL history that can be used to reproduce, and
> perhaps to distill down to a small failing test, any kabooms you get while
> experimenting in the REPL. And if the domain inherently is going to produce
> hard-to-reproduce circumstances, invest proactively in aggressive and
> detailed logging.
>
> My domain (mostly research in evolutionary computation) is indeed
> inherently "going to produce hard-to-reproduce circumstances." And, as it
> happens, logging that is sufficiently "aggressive and detailed logging" to
> capture the things I'll want to see after a crash would produce
> astronomically (impractically) large log files. It'd be so much nicer just
> to see the values of the locals at the time of the crash, which are already
> there in memory if we could only grab them in time.
>
>  -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.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Warren Lynn]

> 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 the Elisp debugger or Common Lisp debugger too. They made fixing an 
issue so much easier. I think good REPL is a complement (and a very 
important/good one) to it, not a replacement to it. I don't know if I 
gained much (or any) if I got a good tool but lost another good one.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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


Ooo this sounds promising... I'd love to know how to disable locals clearing 
for an entire project and then to dump all of the locals on error, if 
possible...

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Timothy Baldridge]

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 program, the harder it would be to get any sort of useful information out
of a debugger.

For instance, look at the implementation of for, map or Clojure's reducers.
I'd really hate to step through that code with a debugger.

While sometimes I feel a debugger would be nice, I think they are much more
useful in imperative languages than they are in functional languages like
Clojure.

Timothy Baldridge


On Tue, May 28, 2013 at 12:05 PM, Warren Lynn  wrote:

>
> 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 first strategies.
>>
>> Luc P.
>>
>>
>>  --
> --
> 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.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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

Too bad, if that's really the final word. It's so very useful to get the locals 
at the point of (unanticipated) error, and this is information that is already 
"known" to the system... and we just want it not to throw it away.

> The lesson for clojure developers being, strive for reproducibility! You 
> should already be using lots of pure functions and few side-effecting ones, 
> and your IDE should keep a REPL history that can be used to reproduce, and 
> perhaps to distill down to a small failing test, any kabooms you get while 
> experimenting in the REPL. And if the domain inherently is going to produce 
> hard-to-reproduce circumstances, invest proactively in aggressive and 
> detailed logging.

My domain (mostly research in evolutionary computation) is indeed inherently 
"going to produce hard-to-reproduce circumstances." And, as it happens, logging 
that is sufficiently "aggressive and detailed logging" to capture the things 
I'll want to see after a crash would produce astronomically (impractically) 
large log files. It'd be so much nicer just to see the values of the locals at 
the time of the crash, which are already there in memory if we could only grab 
them in time.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Ben Mabey]

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 throw site in 
redl.core/break's macro expansion that captures locals, or something 
similar, and replacing the offending throw with a direct punt to the 
debug REPL.

4. Load a class with that as its only method.
5. Invoke that method, with the same arguments as the ...

Ah, crap. The arguments might have been locals-cleared by then, in the 
caller, and by the time of the throw in the callee. Damn damn damn. It 
would have to recurse farther up the stack and who knows where it 
would stop? So even with pure functions this enhanced scheme still 
would only sometimes work -- and with side-effecting ones you have 
side effects happening twice.


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


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



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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Warren Lynn]

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 first strategies. 
>
> Luc P. 
>
>
>

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Cedric Greevey]

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 that captures locals, or something
similar, and replacing the offending throw with a direct punt to the debug
REPL.
4. Load a class with that as its only method.
5. Invoke that method, with the same arguments as the ...

Ah, crap. The arguments might have been locals-cleared by then, in the
caller, and by the time of the throw in the callee. Damn damn damn. It
would have to recurse farther up the stack and who knows where it would
stop? So even with pure functions this enhanced scheme still would only
sometimes work -- and with side-effecting ones you have side effects
happening twice.

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

The lesson for clojure developers being, strive for reproducibility! You
should already be using lots of pure functions and few side-effecting ones,
and your IDE should keep a REPL history that can be used to reproduce, and
perhaps to distill down to a small failing test, any kabooms you get while
experimenting in the REPL. And if the domain inherently is going to produce
hard-to-reproduce circumstances, invest proactively in aggressive and
detailed logging.



On Tue, May 28, 2013 at 12:24 PM, Cedric Greevey  wrote:

> 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 an ability of macros.
>>
>> In Common Lisp exceptions are handled in the contexts in which they
>> occur, so if you handle the exception by stopping execution and presenting
>> a REPL (which is the default) then the locals don't have to be "retrieved"
>> -- they're just still where they were, and where the REPL is too. And there
>> are functions that let you look at locals throughout the stack (graphically
>> browsable in IDEs, but REPL-accessible in any event).
>>
>> I gather that one can't handle exceptions "in context" like this in
>> Java... but I'm approaching this from the Lisp side and don't really
>> know... I see some related discussions (e.g. in
>> https://news.ycombinator.com/item?id=438125) but it's not clear to me
>> what the bottom line is.
>>
>> If it *is* possible to get this kind of behavior in Clojure than that
>> would be a beautiful thing.
>>
>
> Eclipse allows setting a breakpoint that triggers on an exception throw,
> rather than a particular line of code. This implies that the JVM has a
> debugging hook that allows effectively wrapping every throw with a phantom
> try...catch to trap that exception and handle it a certain way. So it
> *should* be possible (with the IDE and debugged code running in separate
> JVMs) to make a Clojure IDE that can pop you into a REPL at the point of an
> exception throw (and even to set it to do this only on specific classes of
> exception). I doubt you could just patch-and-continue like in Common Lisp,
> though, and it would need further work to be able to examine local
> variables (and unwind the stack a notch at a time and repeat). I have a
> general notion of how you might fake some of Common Lisp's functionality:
> the exception handler creates or recreates a "debug" namespace, uses more
> of the JVM's debugging capabilities (which, again, Eclipse can use to let
> you examine locals when a breakpoint trips) to copy locals into vars of the
> same names, and binds some var to a function that will set a
> debug-REPL-triggering breakpoint in the caller one line after the callee
> returns and then resume, dropping you immediately into the debug REPL again
> but now in the callee. So you'd end up with something like
>
> #
> in foo.core$bar.invoke (core.clj:962)
> in foo.core$quux.invoke (core.clj:1701)
> ...
> In foo.core$bar.invoke (core.clj:962)
> debug=> a
> 3
> debug=> b
> nil
> ; Aha! Someone called bar with nil. In fact, quux called bar with nil.
> debug=> (unwind)
> In foo.core$quux.invoke (core.clj:1701)
> debug=> x
> 0
> ; Aha! Should be at least 1.
>
> Of course, locals clearing would sometimes mean that information you
> needed would have been nulled out already. If x had no further use in quux
> after being passed to bar, for example, it would probably be nil instead of
> 0, and you'd be limited in what conclusions you could draw from a nil
> value, unless the local was used farther on. I doubt that's surmountable
> without reproducing the bug first and then adding a dummy use of the local
> later than the p

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Cedric Greevey]

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 an ability of macros.
>
> In Common Lisp exceptions are handled in the contexts in which they occur,
> so if you handle the exception by stopping execution and presenting a REPL
> (which is the default) then the locals don't have to be "retrieved" --
> they're just still where they were, and where the REPL is too. And there
> are functions that let you look at locals throughout the stack (graphically
> browsable in IDEs, but REPL-accessible in any event).
>
> I gather that one can't handle exceptions "in context" like this in
> Java... but I'm approaching this from the Lisp side and don't really
> know... I see some related discussions (e.g. in
> https://news.ycombinator.com/item?id=438125) but it's not clear to me
> what the bottom line is.
>
> If it *is* possible to get this kind of behavior in Clojure than that
> would be a beautiful thing.
>

Eclipse allows setting a breakpoint that triggers on an exception throw,
rather than a particular line of code. This implies that the JVM has a
debugging hook that allows effectively wrapping every throw with a phantom
try...catch to trap that exception and handle it a certain way. So it
*should* be possible (with the IDE and debugged code running in separate
JVMs) to make a Clojure IDE that can pop you into a REPL at the point of an
exception throw (and even to set it to do this only on specific classes of
exception). I doubt you could just patch-and-continue like in Common Lisp,
though, and it would need further work to be able to examine local
variables (and unwind the stack a notch at a time and repeat). I have a
general notion of how you might fake some of Common Lisp's functionality:
the exception handler creates or recreates a "debug" namespace, uses more
of the JVM's debugging capabilities (which, again, Eclipse can use to let
you examine locals when a breakpoint trips) to copy locals into vars of the
same names, and binds some var to a function that will set a
debug-REPL-triggering breakpoint in the caller one line after the callee
returns and then resume, dropping you immediately into the debug REPL again
but now in the callee. So you'd end up with something like

#
in foo.core$bar.invoke (core.clj:962)
in foo.core$quux.invoke (core.clj:1701)
...
In foo.core$bar.invoke (core.clj:962)
debug=> a
3
debug=> b
nil
; Aha! Someone called bar with nil. In fact, quux called bar with nil.
debug=> (unwind)
In foo.core$quux.invoke (core.clj:1701)
debug=> x
0
; Aha! Should be at least 1.

Of course, locals clearing would sometimes mean that information you needed
would have been nulled out already. If x had no further use in quux after
being passed to bar, for example, it would probably be nil instead of 0,
and you'd be limited in what conclusions you could draw from a nil value,
unless the local was used farther on. I doubt that's surmountable without
reproducing the bug first and then adding a dummy use of the local later
than the point of the error so as to keep it from being locals-cleared, but
then you might as well just put a println instead of a dummy use there and
call it a night.

TL;DR: if anything seriously impedes development of a locals-examining
debugger capability in a Clojure IDE, it will be locals clearing rather
than a lack of capabilities for JVM instrumentation.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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 
know what value was passed in as n that led to the error. And in more 
complicated situations it might help to know what args the caller received as 
well. And what the values of all of the locals were all the way down the stack. 

What I was describing was just a test to see if LightTable shows the values 
that args/locals have when an error occurs, and it looks like it doesn't (at 
least not right out of the box).

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Rostislav Svoboda]

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 nice feature.
>>
>
> I love the ideas behind LightTable and I check it out from time to time.
>
> Checking it out now, though, regarding this issue, I don't see access to 
> locals at the time of an exception. For example:
>
> (defn bad [n] (/ 2 n))
>
> (defn bad-caller [x] (bad (- x 3)))
>
> (bad-caller 3)
>
> I get an exception:
>
> java.lang.ArithmeticException: Divide by zero
>   Numbers.java:156 clojure.lang.Numbers.divide
>  Numbers.java:3667 clojure.lang.Numbers.divide
>   NO_SOURCE_FILE:8 ltfoo.core/bad
>  NO_SOURCE_FILE:12 ltfoo.core/bad-caller
>  NO_SOURCE_FILE:16 ltfoo.core/eval4706
>
> but I don't see anywhere the value of n in bad at the time of the exception.
>
>  -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.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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 issue, I don't see access to locals 
at the time of an exception. For example:

(defn bad [n] (/ 2 n))

(defn bad-caller [x] (bad (- x 3)))

(bad-caller 3)

I get an exception:

java.lang.ArithmeticException: Divide by zero
  Numbers.java:156 clojure.lang.Numbers.divide
 Numbers.java:3667 clojure.lang.Numbers.divide
  NO_SOURCE_FILE:8 ltfoo.core/bad
 NO_SOURCE_FILE:12 ltfoo.core/bad-caller
 NO_SOURCE_FILE:16 ltfoo.core/eval4706

but I don't see anywhere the value of n in bad at the time of the exception.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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 handled in the contexts in which they occur, so 
if you handle the exception by stopping execution and presenting a REPL (which 
is the default) then the locals don't have to be "retrieved" -- they're just 
still where they were, and where the REPL is too. And there are functions that 
let you look at locals throughout the stack (graphically browsable in IDEs, but 
REPL-accessible in any event).

I gather that one can't handle exceptions "in context" like this in Java... but 
I'm approaching this from the Lisp side and don't really know... I see some 
related discussions (e.g. in https://news.ycombinator.com/item?id=438125) but 
it's not clear to me what the bottom line is.

If it *is* possible to get this kind of behavior in Clojure than that would be 
a beautiful thing.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[dgrnbrg]

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 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 using 
> the 
> > debugger to fix a specific problem. 
>
> Okay, sometimes debuggers don't help... but sometimes they do! And often 
> it's necessary to step back and think... but sometimes having some key 
> information (like the value of the arguments to my function, or of some 
> other locals, that led to the error) makes the thinking a lot more 
> productive. 
>
> Elsewhere on this thread: 
>
> On May 27, 2013, at 9:36 PM, dgrnbrg wrote: 
> > For Vim users, I ported the debug repl. This is a tool that allows you 
> to create a REPL in the middle of the call stack, which allows you to 
> suspend the evaluation of functions, lazy seqs, etc, and then inspect the 
> locals and globals at that location. If you've already installed Fireplace, 
> then you just need add the vim plugin and include redl in your project.clj, 
> and use :Repl or :ReplHere to create a repl, and then use redl.core/break 
> and redl.core/continue to use the debugger. You can find the vim component 
> here: https://github.com/dgrnbrg/vim-redl and the Clojure component here: 
> https://github.com/dgrnbrg/redl 
>
> This sounds pretty neat... but I also don't use Vim. (It's also not 
> completely clear to me from this description if you can get the locals from 
> the context of an error, rather than from a manual suspension.) 
>
> Is there anything that will provide the values of locals at an error 
> (whether interactively or in a big dump) regardless of the IDE or launch 
> method that one uses? 
>
> Or if there's nothing that's so general then is there anything that would 
> work from a call to "lein run" or from Clooj or from Eclipse/CCW? 
>
> Thanks, 
>
>  -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.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Phillip Lord]

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 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't know how to do well currently in Clojure 
> (I use Vim, and have not programmed in Clojure for a while), so I am really 
> interested in what he meant.

I'm an emacs head, and that was my originally my first and only
experience of lisp. I've really enjoyed learning clojure, and have found
it both very useful and very nice. The REPL is great, I eval stuff and
play with things. I use test.

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

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Mark Engelberg]

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 of actions brought about the
unique state that caused the problem.

Even if it is clear how to recreate the problem, it can be tedious to
annotate the code with extra logging info to print out all the local
variables, and the mere act of doing so might make the problem go away.

There are all sorts of reasons why you'd want to do a fuller investigation
of a crash when it happens, using information that was generated directly
by the crash, without having to add new code and reconstruct the events
leading to the crash.

On Mon, May 27, 2013 at 10:53 PM, Cedric Greevey  wrote:

> You have production code going *boom* that doesn't have any failing tests?
> Or you have nondeterministic tests? :)
>
>

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Cedric Greevey]

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-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 entry anytime it gets set to a value outside its
>> expected range, including printing a stack trace that should include the
>> spot in the code where this happened.
>>
>> In the case of immutable data or mutable Java objects getting scrozzled,
>> there's always the option of modifying the possible sites of the trouble to
>> log buggy behavior. For instance, if a LinkedBlockingQueue is getting
>> polluted with nils that are making the consumer blow up, adding before
>> (.offer lbq x) something like (if (nil? x) (throw (NullPointerException.)))
>> will move the blowup closer to the actual site of the error and give you an
>> informative stack trace. You might even leave that one in in production, if
>> the thing should (or *will*) die anyway if a nil gets in there, so your
>> user base's bug reports will already have a useful stack trace instead of a
>> useless one.
>>
>> Bad function arguments? Add a :pre clause to blow up immediately with a
>> useful stack trace, if one otherwise doesn't show up or shows up far from
>> the error. Bad values getting into immutable data? Add a (print ...)
>> wherever it's built up using assoc or conj or what-have-you.
>>
>>
>>
>
> You've just listed three things that I can *add* to my code to track down
> errors: watches, logging, pre clauses (and let's not forget the old standby
> printf).  But that all misses the point.  When my code goes *boom* and I
> get an error and a stacktrace, I want to know specifically what the context
> was at the time of *that particular crash*.  If I have to alter my code and
> rerun, it may be hard to recreate the conditions that caused the error.  If
> the stacktrace simply revealed richer information, such as what the inputs
> were to the various functions in the stacktrace, and I could explore the
> local variables, that would save tons of time spent trying to annotate the
> function to print or log the variables and then trying to get the bug to
> happen again.
>
> --
> --
> 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.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Mark Engelberg]

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 entry anytime it gets set to a value outside its
> expected range, including printing a stack trace that should include the
> spot in the code where this happened.
>
> In the case of immutable data or mutable Java objects getting scrozzled,
> there's always the option of modifying the possible sites of the trouble to
> log buggy behavior. For instance, if a LinkedBlockingQueue is getting
> polluted with nils that are making the consumer blow up, adding before
> (.offer lbq x) something like (if (nil? x) (throw (NullPointerException.)))
> will move the blowup closer to the actual site of the error and give you an
> informative stack trace. You might even leave that one in in production, if
> the thing should (or *will*) die anyway if a nil gets in there, so your
> user base's bug reports will already have a useful stack trace instead of a
> useless one.
>
> Bad function arguments? Add a :pre clause to blow up immediately with a
> useful stack trace, if one otherwise doesn't show up or shows up far from
> the error. Bad values getting into immutable data? Add a (print ...)
> wherever it's built up using assoc or conj or what-have-you.
>
>
>

You've just listed three things that I can *add* to my code to track down
errors: watches, logging, pre clauses (and let's not forget the old standby
printf).  But that all misses the point.  When my code goes *boom* and I
get an error and a stacktrace, I want to know specifically what the context
was at the time of *that particular crash*.  If I have to alter my code and
rerun, it may be hard to recreate the conditions that caused the error.  If
the stacktrace simply revealed richer information, such as what the inputs
were to the various functions in the stacktrace, and I could explore the
local variables, that would save tons of time spent trying to annotate the
function to print or log the variables and then trying to get the bug to
happen again.

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Cedric Greevey]

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 that in Clojure yet.
>

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 entry anytime it gets set to a value outside its
expected range, including printing a stack trace that should include the
spot in the code where this happened.

In the case of immutable data or mutable Java objects getting scrozzled,
there's always the option of modifying the possible sites of the trouble to
log buggy behavior. For instance, if a LinkedBlockingQueue is getting
polluted with nils that are making the consumer blow up, adding before
(.offer lbq x) something like (if (nil? x) (throw (NullPointerException.)))
will move the blowup closer to the actual site of the error and give you an
informative stack trace. You might even leave that one in in production, if
the thing should (or *will*) die anyway if a nil gets in there, so your
user base's bug reports will already have a useful stack trace instead of a
useless one.

Bad function arguments? Add a :pre clause to blow up immediately with a
useful stack trace, if one otherwise doesn't show up or shows up far from
the error. Bad values getting into immutable data? Add a (print ...)
wherever it's built up using assoc or conj or what-have-you.

The only times I've resorted to a debugger myself have been with buggy C
code that trashed the stack or heap or jumped off into the middle of
nowhere and the resulting stack trace, if existent, didn't point to the
true location of the error, or give any useful hints as to where that was,
and when diagnosing and fixing deadlocks in Java code. Java dispensed with
C's ability to trash the system badly enough to not have a meaningful stack
trace (even if it's far from the real error, a Java stack trace is pointing
to something *relevant*, like a null where one shouldn't be that you can
find all the mutators of; with C in real mode it was frighteningly easy to
get no stack trace at all, just a hang, kernel panic, or BSOD, and even in
protected mode your bug could systematically destroy all of the data you
could use to diagnose it and *then* crash the process) and Clojure has more
or less ended the deadlock menace (where being able to see which threads
hold what monitors and are waiting for what other monitors was the key
debugger killer-feature that stack traces and logging weren't so helpful
with) and anything that simply hangs inside the JVM can be re-tried in the
context of (def x (Thread. #(hanging-fn args))), (.start x), wait for it to
have stopped working, (.getStackTrace x), and check out the stack trace you
get to see where hanging-fn and its callees went off the fairway and into
the trees (maybe lower x's priority before (.start x) if it wedges a core
and that would otherwise make the REPL unresponsive).

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Charles Harvey III]

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

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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 using the
> debugger to fix a specific problem.

Okay, sometimes debuggers don't help... but sometimes they do! And often it's 
necessary to step back and think... but sometimes having some key information 
(like the value of the arguments to my function, or of some other locals, that 
led to the error) makes the thinking a lot more productive.

Elsewhere on this thread:

On May 27, 2013, at 9:36 PM, dgrnbrg wrote:
> For Vim users, I ported the debug repl. This is a tool that allows you to 
> create a REPL in the middle of the call stack, which allows you to suspend 
> the evaluation of functions, lazy seqs, etc, and then inspect the locals and 
> globals at that location. If you've already installed Fireplace, then you 
> just need add the vim plugin and include redl in your project.clj, and use 
> :Repl or :ReplHere to create a repl, and then use redl.core/break and 
> redl.core/continue to use the debugger. You can find the vim component here: 
> https://github.com/dgrnbrg/vim-redl and the Clojure component here: 
> https://github.com/dgrnbrg/redl

This sounds pretty neat... but I also don't use Vim. (It's also not completely 
clear to me from this description if you can get the locals from the context of 
an error, rather than from a manual suspension.) 

Is there anything that will provide the values of locals at an error (whether 
interactively or in a big dump) regardless of the IDE or launch method that one 
uses? 

Or if there's nothing that's so general then is there anything that would work 
from a call to "lein run" or from Clooj or from Eclipse/CCW?

Thanks,

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Softaddicts]

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 feeds 
within the same time slot.  I had to sort out messages while listening to the 
master
feed to replicate the same orderly message stream as the master while avoiding
sending duplicates.

This was highly non deterministic, I ended up with more than two dozen threads
with circular buffers, etc... with obviously mutation everywhere, mutexes, 
condition variables, ... to try to stay in sync with the master feed.

Tests had to be done with real data which of course changed every time I had
to test.

Add to this an unstable Solaris kernel thread subsystem. Took three weeks to
find the proper patch mix to attain the nirvana of stability.

Debugging was not a viable option.

The only options were code review/hammock time and sufficient logging.
This was written in C, no REPL, the old fail/fix/compile/link/run cycle.

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 using the
debugger to fix a specific problem.

Luc P.


> 
> 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, but the capability seems to have been lost in the 
> > transition to nrepl.
> 
> This is also the main debugging feature I want and don't have in any of the 
> ways that I currently work with Clojure. I've seen montion of libraries that 
> one can include that will give one this kind of functionality, but I've never 
> gotten anything to work. Does anyone know a simple way to do this that 
> doesn't involve an Emacs-based tool set?
> 
> In my former life in Common Lisp I think that every environment -- from 
> command-line-based implementations to full-featured IDEs -- would put you in 
> a REPL at the point of an error, from which you could examine locals all the 
> way up the stack, evaluate expressions, and even redefine things and 
> continue. I don't usually need all of this, but it seems cruel for the system 
> to be throwing away all of that stack info (local variables) that I often 
> know contains the information I need to track down and fix a bug.
> 
> Later in the thread:
> 
> On May 27, 2013, at 8:17 PM, Brandon Bloom wrote:
> > 
> > Most of the time, stepping through code is just much slower than thinking, 
> > inserting a precise print statement, and then re-executing the broken code.
> > 
> > However, this means that you need to design your code for determinism, 
> > repeatability, and visibility. So not having a debugger means also has 
> > pleasant affects on your design!
> 
> Most of my code is intentionally and intrinsically non-deterministic, and 
> "re-executing" can take days. So it sure would be nice to be able to see the 
> locals that were in play when the error was triggered!
> 
>  -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.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[dgrnbrg]

For Vim users, I ported the debug repl. This is a tool that allows you to 
create a REPL in the middle of the call stack, which allows you to suspend 
the evaluation of functions, lazy seqs, etc, and then inspect the locals 
and globals at that location. If you've already installed Fireplace, then 
you just need add the vim plugin and include redl in your project.clj, and 
use :Repl or :ReplHere to create a repl, and then use redl.core/break and 
redl.core/continue to use the debugger. You can find the vim component 
here: https://github.com/dgrnbrg/vim-redl and the Clojure component 
here: https://github.com/dgrnbrg/redl

Let me know if you need help setting it up!

On 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 
> 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't know how to do well currently in Clojure 
> (I use Vim, and have not programmed in Clojure for a while), so I am really 
> interested in what he meant.
>
> And by the way: As I said, I have not been using Clojure for a few months, 
> but: What's the state of the art of debugging for Vim users? I've been 
> meaning to try out vim-fireplace and ritz and see if they work together 
> well, but have not gotten around to it yet. I would very much appreciate a 
> nudge in the right direction.
>

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Lee Spector]

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, but the capability seems to have been lost in the transition to 
> nrepl.

This is also the main debugging feature I want and don't have in any of the 
ways that I currently work with Clojure. I've seen montion of libraries that 
one can include that will give one this kind of functionality, but I've never 
gotten anything to work. Does anyone know a simple way to do this that doesn't 
involve an Emacs-based tool set?

In my former life in Common Lisp I think that every environment -- from 
command-line-based implementations to full-featured IDEs -- would put you in a 
REPL at the point of an error, from which you could examine locals all the way 
up the stack, evaluate expressions, and even redefine things and continue. I 
don't usually need all of this, but it seems cruel for the system to be 
throwing away all of that stack info (local variables) that I often know 
contains the information I need to track down and fix a bug.

Later in the thread:

On May 27, 2013, at 8:17 PM, Brandon Bloom wrote:
> 
> Most of the time, stepping through code is just much slower than thinking, 
> inserting a precise print statement, and then re-executing the broken code.
> 
> However, this means that you need to design your code for determinism, 
> repeatability, and visibility. So not having a debugger means also has 
> pleasant affects on your design!

Most of my code is intentionally and intrinsically non-deterministic, and 
"re-executing" can take days. So it sure would be nice to be able to see the 
locals that were in play when the error was triggered!

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Brandon Bloom]

Coming from Visual Studio all those years ago, I deeply missed my debugger.

These days, I miss my debugger extremely rarely. And when I do use a 
debugger, I much prefer a non-visual one: Either something like dgb, or 
something like a hypothetical open-repl-here function, where I can ask 
specific questions and get specific answers... logged to my terminal! I 
find that trace points (aka print statements) are more useful than break 
points because I can look at cross sections of execution (read: logs) 
rather than specific instruction pointer locations. And when you get a log 
in your terminal, you spend less time re-asking and re-evaluating by 
hovering your mouse around, which is quick to confuse you. Logs are 
particularly useful with pretty printed Clojure data, since you know the 
values have remained immutable since you have printed them!

Most of the time, stepping through code is just much slower than thinking, 
inserting a precise print statement, and then re-executing the broken code.

However, this means that you need to design your code for determinism, 
repeatability, and visibility. So not having a debugger means also 
has pleasant affects on your design!

On 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 
> 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't know how to do well currently in Clojure 
> (I use Vim, and have not programmed in Clojure for a while), so I am really 
> interested in what he meant.
>
> And by the way: As I said, I have not been using Clojure for a few months, 
> but: What's the state of the art of debugging for Vim users? I've been 
> meaning to try out vim-fireplace and ritz and see if they work together 
> well, but have not gotten around to it yet. I would very much appreciate a 
> nudge in the right direction.
>

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Softaddicts]

I use Eclipse and rarely use the debugger. 

When I use the debugger it's mainly in some interop situations where I need
to look at both sides of the fence, Java and Clojure at the same time. Most of 
the
time it's a misuse of the API that triggers exceptions.

These first four strategies are both covering 98% of the needs and reflect sane
priorities.

Reading the code offline and hammock time is of the utmost importance.
If you get stuck in a dead end with some obscure bug, it's a sign that you need 
this
time to reassess your understanding and design of your code.

Think about others trying to understand your code if you cannot keep your own 
code
under control...

It may well be a sign that it needs some improvements to make it more resilient 
and 
cleaner.

I frequently used a debugger in the past when integrating component written in 
different
languages because most of the time it's the only easy way to bridge the gap 
between 
them  (different call conventions, runtimes, call side effects, ...).

There are lot less side effects in Clojure, it makes the added value of a 
debugger
limited in a Clojure centric app. 

The importance of having a debugger is highly exaggerated in this context.

A debugger as good as it is cannot replace the 4 first strategies.

Luc P.

> I just watched that video and interpreted it to mean that of the many
> strategies available to understand problematic behavior in a live app:
> 
> * reading the code offline + sufficient hammock time
> * reproducing the problem offline using test cases in an appropriate
> simulation environment
> * appropriate logging and tracing at runtime
> * repl into the live app
> * tool-assisted stepwise execution and runtime examination (debugging)
> 
> He's able to be sufficiently productive using the first 4 strategies and
> doesn't miss the 5th.
> 
> In that video he also clarified that his recent experience in the field
> with clojure has been with datomic, of which he and Rich are probably the
> principal authors, so it's familiar code, with test cases and  the logging
> and tracing he wants. He usually responds very quickly to bug reports on
> the datomic list, often within hours, so in that case it's fair to say that
> he's not being hampered by the absence of a debugger.
> 
> I've found debuggers are most useful in cases where:
> 
> * the code is unfamiliar/source is unavailable
> * there isn't an appropriate staging environment or test harness
> * there aren't good logs
> * there's no repl
> 
> However, in a language like 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 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 statement.
> > What does he (or you, if you are reading, Stuart) mean? For me, debugging
> > is the biggest thing that I don't know how to do well currently in Clojure
> > (I use Vim, and have not programmed in Clojure for a while), so I am really
> > interested in what he meant.
> >
> > And by the way: As I said, I have not been using Clojure for a few months,
> > but: What's the state of the art of debugging for Vim users? I've been
> > meaning to try out vim-fireplace and ritz and see if they work together
> > well, but have not gotten around to it yet. I would very much appreciate a
> > nudge in the right direction.
> >
> > --
> > --
> > 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 mes

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Mark Engelberg]

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[David Nolen]

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 was possible to do this in earlier
> Clojure environments, but the capability seems to have been lost in the
> transition to nrepl.
>
>  --
> --
> 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.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Mark Engelberg]

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

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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[u1204]

>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 statement. 
>What does he (or you, if you are reading, Stuart) mean? For me, debugging 
>is the biggest thing that I don't know how to do well currently in Clojure 
>(I use Vim, and have not programmed in Clojure for a while), so I am really 
>interested in what he meant.

Like Stuart, I haven't used a debugger in years.  I find that debuggers
give me something to do with my hands while thinking about the
failure. They used to be very useful on slow machines but these
billion-instructions-per-second toys we have now just tend to overwhelm
with data.

Try "navel debugging". Write a few lines of code, rebuild the system,
test that it works the way you expect. If it fails the failure is almost
certainly in the changes you just made. Sit back, contemplate your
navel, stare at the code, and the nature of the bug will likely reveal
itself. Most likely the bug is in the piece of code you don't understand.

Of course, this won't work well when working with other people's code.
Finding those bugs usually requires human to human communication. 

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 that in Clojure yet. Is it possible to
dynamically swap a Clojure function definition with a trace function?
You would have to interpret the tracer's code fragments in the lexical
environment of the call.  Are environments first class objects in
Clojure? How would that work in an STM code block? How do you "stack
smash" an immutable data structure and continue execution from the
breakpoint? How would you mutate a value in the caller's environment?

Tim


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

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Jonah Benton]

I just watched that video and interpreted it to mean that of the many
strategies available to understand problematic behavior in a live app:

* reading the code offline + sufficient hammock time
* reproducing the problem offline using test cases in an appropriate
simulation environment
* appropriate logging and tracing at runtime
* repl into the live app
* tool-assisted stepwise execution and runtime examination (debugging)

He's able to be sufficiently productive using the first 4 strategies and
doesn't miss the 5th.

In that video he also clarified that his recent experience in the field
with clojure has been with datomic, of which he and Rich are probably the
principal authors, so it's familiar code, with test cases and  the logging
and tracing he wants. He usually responds very quickly to bug reports on
the datomic list, often within hours, so in that case it's fair to say that
he's not being hampered by the absence of a debugger.

I've found debuggers are most useful in cases where:

* the code is unfamiliar/source is unavailable
* there isn't an appropriate staging environment or test harness
* there aren't good logs
* there's no repl

However, in a language like 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 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 statement.
> What does he (or you, if you are reading, Stuart) mean? For me, debugging
> is the biggest thing that I don't know how to do well currently in Clojure
> (I use Vim, and have not programmed in Clojure for a while), so I am really
> interested in what he meant.
>
> And by the way: As I said, I have not been using Clojure for a few months,
> but: What's the state of the art of debugging for Vim users? I've been
> meaning to try out vim-fireplace and ritz and see if they work together
> well, but have not gotten around to it yet. I would very much appreciate a
> nudge in the right direction.
>
> --
> --
> 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.

"I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Oskar Kvist]

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 statement. 
What does he (or you, if you are reading, Stuart) mean? For me, debugging 
is the biggest thing that I don't know how to do well currently in Clojure 
(I use Vim, and have not programmed in Clojure for a while), so I am really 
interested in what he meant.

And by the way: As I said, I have not been using Clojure for a few months, 
but: What's the state of the art of debugging for Vim users? I've been 
meaning to try out vim-fireplace and ritz and see if they work together 
well, but have not gotten around to it yet. I would very much appreciate a 
nudge in the right direction.

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