Small comment: In addition to discoverability, try to have this go
direct to *understanding* of how&when to use "errortrace".
(Multiple times over the years, I have been doing crucial performance
optimizations to server code, and remnants of various versions of
"errortrace" kept getting added back into the code. Pattern: get it
optimized, incidentally also remove killer "errortrace" bits, then
someone merges the changes, and some terrible "#! ... -l errortrace" or
ancient "require ... errortrace.ss" somehow sneaks back into several
different places each in multiple branches, sneaks back into hurting
production capacity. Even if you provide a switch in the app-specific
build environment to enable/disable errortrace. With lots of code and
lots of branches and merging, it seems that errortrace can be like bed
bugs -- terrorizing you with small bites everywhere, and you just can't
get rid of it. This might seem like a CM and merging problem, not an
"errortrace" problem, but it seems somewhat peculiar to "errortrace" in
practice. I am forming a theory that some programmers are afraid to let
a merge remove whatever cargo-cult incantations they found in the past
gave them better backtraces, damn any consequences. :) Hence my
suggestion to have your improved discoverability send the programmer
direct to *understanding*, rather than to cargo-cult "add this magical
snippet to your project" with an implied "and never lose the faith".)
(Like many programming pragmatics, I know it looks silly to consider
this seemingly little thing a matter of importance worth mention, but my
view from the ground is that it has been important.)
Neil V.
____________________
Racket Users list:
http://lists.racket-lang.org/users
