guile-debugging 0.13 released

[Neil Jerram]

Available at http://download.gna.org/guile-debugging/; NEWS below.

Please note that this doesn't yet include William Xu's socket patch,
or other fixes/enhancements discussed within the last three weeks;
I'll work on those and make another release soon (I hope!).


Regards,
     Neil


The main reason for this release is to test and verify the waters
after the merge back into Guile CVS (with its concomitant module name
changes), but it also includes a few enhancements and fixes that have
accumulated since the 0.12 release.

* Distribution changes

** Merge back into Guile CVS

Most of this package has now been merged into core Guile CVS, but in
such a way that I can still make independent releases of
"guile-debugging" when that is useful.

As part of this merge, all the module names have changed.  The GDS
Scheme files have changed from (ossau ...) to (ice-9 ...) and the
debugging-related Scheme files (which means all the others) have
changed from (ossau ...) to (ice-9 debugging ...).

* Enhancements

** Return values in trace output are indicated by "=>"

In trace output, the trace/info procedure now displays "=>" before the
return value.  When the returned value is a list or pair, this makes
it clearer that the trace line is describing a return value and not a
new evaluation.

** Debugger shows source location automatically, when single stepping

When using the command line debugger to single step, under Guile 1.6,
the debugger now shows the source location at each step automatically.
Previously source location info was only shown in response to "info
frame" or as part of a backtrace.  (With Guile >=1.7, the command line
debugger already showed the source location automatically.)

* Documentation improvements

** New Examples chapter in the manual (now in the Guile manual)

The manual now has a chapter of Examples right after the Introduction,
to give an idea of what guile-debugging can do and to address some
common scenarios.

* Bug fixes

The following problems have been fixed.

** Unnecessarily frequent modification of persistent breakpoints file

The GDS elisp code uses a cache to avoid modifying this file when the
set of breakpoints isn't really changing, but there was a bug which
corrupted the cache and so caused the breakpoints file to be modified
when not really necessary, such as when just loading or saving a
Scheme file with breakpoints in it.