The Emacs Mode
Sather has beautiful and extensive emacs support (provided by
Kevin Lewis) in the form of a Sather mode which full font-lock support
as well as the ability to view the hierarchical structure of a
document. You can use any editor you please, of course. If you are a
vi user, you might consider using the "viper" mode in emacs to get the
benefits of the emacs highlighting while using "vi" style commands.
The emacs mode also permits selectively hiding and displaying various
levels of a Sather file (i.e. you can hide all routine bodies or entire
class bodies, displaying only the name).
The Sather browser (bs) is written in a combination of Tcl/Tk
and Sather. It builds on the compiler and is a part of the standard
Sather distribution. Using the browser you can view the type graph of
a particular program and the features of various classes used in the
program. The type graph and other program data can be viewed in
various selective ways so as to focus on the relevant information in
the program.
Web Browsing
Tools to render a set of classes in HTML browsable form are
also available
(see the library for an example).
These tools consist of a set of tcl and csh scripts and are
in a somewhat rudimentary state. They rely on several other programs
for their functionality.
If you are interested in them, send an email to
Ben Gomes.
Debugging
Debugging Sather is very different from debugging C or C++. Due to
the strong type checking, garbage collection, iteration abstraction
and clean implementation of parametrized classes, large classes of
errors are simply not possible. Thus, a very large fraction of
programming errors are discovered by the compiler at compile time.
The common experience is that it can take many times longer to get
your program to compile the first time than it would in, say, C. This
time is actually a great savings, since the compiler is telling you
about errors that you would otherwise have to discover by
edit-compile-run cycles. It is not uncommon for the resulting program
to then execute correctly the first time it typechecks completely.
Even at run-time, a Sather program cannot "crash" (provided all checks
are turned on), and this helps enormously in localizing bugs. The most
common sources of errors are void and assertion checks. When the
program is compiled with -debug, it will print out a stack trace when
an assertion is violated. This stack trace is usually
sufficient to eliminate the bug. For more complex bugs, you can use
gdb, which can be automatically invoked when an assertion fails.
The ICSI Sather compiler generates portable C which can be
annotated in various ways to make debugging easier with the standard
C debugging tools such as gdb.
The main problem with using gdb is dealing with the name mangling.
The compiler has an option, -pretty, that annotates the generated C
code to indicate the unmangled Sather names. A more powerful compiler
option, -debug, causes Sather line numbers to be used, and a set of
debugging functions to be compiled in. These functions can print out
the structure of Sather objects using the Sather names of those
objects. With the ability to set breakpoints in the Sather source,
and to view objects, you get much of the functionality you would have
with native gdb support.
If you compile your program with the option -debug_graphical, you can
graphically browse data-structures in the program using a point and
click Tk based user interface. The interaction with gdb is somewhat
clumsy, but independance from gdb permits us to avoid tracking gdb
updates.
