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

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.

Last change: 6/04/96 The Sather Team (sather@icsi.berkeley.edu)