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<lprefonta...@softaddicts.ca> 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.


Reply via email to