# 
# 
# patch "ChangeLog"
#  from [d2e6c1948545a44a70d3951b54eeb1b7864d3c5c]
#    to [23a7fbfcb59b2dd2ccc2d473d93bf1897ab55475]
# 
# patch "HACKING"
#  from [a45c34b6fc9a25c3910eaf68c3fec00bc38a7980]
#    to [0a61d5d48d9db27c2e9614b63b9d6f98f9be7216]
# 
============================================================
--- ChangeLog	d2e6c1948545a44a70d3951b54eeb1b7864d3c5c
+++ ChangeLog	23a7fbfcb59b2dd2ccc2d473d93bf1897ab55475
@@ -1,3 +1,8 @@
+2006-06-04  Nathaniel Smith  <address@hidden>
+
+	* HACKING (Tip): Add some tips on tracking down unit test
+	failures.
+
 2006-06-03  Graydon Hoare  <address@hidden>
 
 	* *.{cc,hh}: Update editor mode lines.
============================================================
--- HACKING	a45c34b6fc9a25c3910eaf68c3fec00bc38a7980
+++ HACKING	0a61d5d48d9db27c2e9614b63b9d6f98f9be7216
@@ -119,7 +119,13 @@
 test case exists, it is strongly recommended to write a test case before
 attempting to fix the bug.
 
+Tip: if the unit tests are failing, the quickest way to find the
+problem is to search the output for the regexp \([0-9]+\) -- i.e., a
+number in parentheses.  Or, if using gdb, try setting a breakpoint on
+theboost::unit_test::first_failed_assertion function (see
+results_collector.hpp).
 
+
 Single-character macros
 -----------------------