Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Trace function

From: joel:neely:fedex at: 21-Jun-2001 2:39

[Sanghabum--aol--com] wrote:
> I suspect the lack of response to my request indicates just > how few of us ever go near Trace after the first encounter. >
I suspect you're right.
> I'm sure we've all got our > little toolkit of debugging toys. The simplest one I have is > in my USER.R.... > > debugprint: :print > > I can search code later for all Print statements that > exist only for debugging. >
Not only that, but you can later re-define debugprint: func [dummy [any-type!]] [] to disable debugging! You've got a good idea there.
> I think it is a shame that Rebol does not have a better set > of debugging tools. > > Perhaps we could open this thread out....Anyone else got > little scripts or tricks they use for debugging that they'd > like to share? >
1) (re)factoring, 2) objects, 3) probe 1) My favorite way to deal with debugging is to avoid it as much as possible (yeah, right! ;-) by (re)factoring the code into small, black-box pieces that can be recombined as flexibly as possible. This includes the use of higher-order functions such as MAP. In my experience, I'm much more likely to *need* debugging tricks with long sprawling functions than with concise ones. 2) Of course, I can get in a hurry and mess up even the most simple-looking functions. By wrapping a group of related functions into an object, and using data-like members of that object as scratch space, I can more easily perform a test and then look at the after-effects (or even add snapshot members) to see where I went off the rails. 3) When I keep my individual functions small and orthogonal, I usually find that a small number of well-placed PROBEs help me get a function working and tested with less effort. In a way, I'm glad that TRACE is so unwieldy! I've used other languages/platforms that had big piles of inspectors, "live" data displays, breakpoints, etc... While those things may be hard to against in *some* situations (embedded software, kernel, and device driver development, for example), I find that in most programming situations in a reasonable high-level language, they make it all too easy for me to get sloppy in my design and coding, because I've got such industrial-strength automated crutches to fall back on! -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com