Development Environment

  The development environment consists of an incremental Sather-to-C compiler (written in Sather), emacs and gdb support and a tcl-based code browser. A fair number of libraries are available, as well as interfaces to other systems such as Tcl. A native compiler for a variant of Sather 1.0, Sather-K is also available from Karlsruhe in Germany.

For a how-to introduction to writing your first program, please see Philippsen's tutorial which is available with the sather distribution and is also available in HTML form, pointed to by:

http://icsi.berkeley.edu/~gomes/Sather/sather-top.html

The compiler has been designed to permit the relatively easy development of a Sather interpreter. The compiler spits out virtual machine instructions which are translated into C; an interpreter for Sather must provide an interpreter for this abstract machine language. Resource constraints have not permitted its development. There is an unsupported interpreter for a subset of the language which does things differently (it does not make use of the abstract machine form); it is available in the distribution. If you are interested in working on the interpreter please contact sather-bugs or borisv, both @icsi.berkeley.edu

The 1.0 Compiler

The 1.0 compiler is available by anonymous ftp from ftp://icsi.berkeley.edu/pub/sather/, as are binaries for various platforms. The Sather-K compiler is also available from this site. For information about the platforms to which the compiler has been ported, the FAQ etc., please see the main sather page:

http://icsi.berkeley.edu/~sather The compiler options are documented in a man page under the Doc subdirectory of the distribution. There is also a document that describes the internal structure of the compiler available from http://icsi.berkeley.edu/~sather/ps/compiler.ps.gz}

Module Files

  The compiler options (documented in the man page for the compiler: man cs) allow the user to specify a list of sather, C, "module" files and other compiler flags. Files of different types are distinguished by their suffixes (.sa, .c, .module, etc.). Module files are collections of compiler options which behave exactly if they were typed in on the command line. Module files have no futher semantic meaning. This permits the usage of a single uniform, unix-like syntax whether specifying options on the command line or in a module file.

Module files are used to partition and organize the Sather library. Associated with each subdirectory of the Sather library is a module file, which just lists the sather and C files in that directory, as well as any modules contained within that directory. For instance, the System module lists the files in the system subdirectory and Socket.module. Socket.module, in turn, lists the files in the socket sub-directory. Note that path-names in a module file are relative to the location of the module file.

The current convention is that all related files should be placed in a single directory and provided with a module file. Using the code from those classes should then just be a matter of mentioning it's module file. The Sather compiler automatically includes the top-most module of the library, Library.module, which is found in the Library subdirectory of the distribution. This module in turn includes the rest of the sather library. If you do not wish to use the standard Library.module, you will need to change the value of the environmental variable SATHER_LIBRARY to point to a different module.

setenv SATHER_LIBRARY "/u/gomes/Sather1/SatherCopy/Browser/mylibrary.module"

You can use this method to avoid loading the standard Sather libraries, but don't forget to define the built-in classes ( INT, BOOL, MUTEX etc.) or the compiler will complain.

Has clauses

  If you notice -has clauses in some module classes, here is why they exist: in order to expedite parsing, the compiler permits the specification of which classes are defined in each file. For instance,

my_math.sa -has my_math.sa MY_MATH_CLASS_FOO MY_MATH_CLASS_BAR

Comments

You can put comments in a module file by using the standard Sather syntax "--". Module files also accept an extended comment syntax of the form

(*  my multi
 line 
comment
*)

Since the module file is displayed by the browser, these comments can be used to describe the nature of a particular module in the Library.

Module files with different suffixes

Module files which do not have the suffix .module must be specified with the compiler option -com <command file name>. This permits the use of the older style of .com files, which may still be necessary on some systems with file name restrictions.    

Over-riding library files

It is not particularly easy to over-ride just a single file in the library. The straightforward way to do it is to copy over the entire library and modify the file. However, as a byproduct of the current behaviour of the compiler (having to do with -has clauses), it sometimes suffices to just copy the one file you want to fix and then mention this amended file explicitly during your compile (without a -has clause). The compiler may find your version. This is clearly a hacky solution, but it often works and can save you some trouble. If it does work, it will work correctly (i.e. it will either choose your version or complain that there were two definitions - it will never silently ignore your explicitly specified version).    

Debugging Sather

Furthermore, I find that programming in Sather is a very different experience from programming in C. Far fewer bugs make it through the compilation phase, and with checking turned on, those bugs are easily detected - very often just void references, or array bounds checks which you can locate by running gdb (even without the debug flag) and looking at the stack trace at the point where the error occurs. The gdb command "where" will give you the stack trace.

I believe that gdb has a facility for name unmangling, given some table, which C++ may use. If so, it might not be too much work to hook into it. If you are interested in undertaking this task, please contact sather-bugs@icsi.berkeley.edu. Since Sather stores type information along with each object, there is the potential for a far more sophisticated debugging environment/object browser than would be possible with C++.

One more point to note: if, for some reason, you do have to debug the generated C, do not turn on the debug flag. Instead, use: -C_flag -g.

    Useful commands for debugging with gdb:

(gdb) info locals
Prints out all the locals currently visible
(gdb) print self
Prints out the pointer to the current self 
Eg: $16 = (struct FMULTIMAPSTRINT_struct *) 0x57ed8
(gdb) print *self
Prints out the value of self
$17 = {header = {tag = 4, destroyed = 0}, hsize = 3, n_targets = 50, 
  asize = 17, arr_part = {{t2 = 0x0, t1 = 0x0}}}
(gdb) print *self->arr_part@3
$15 = {"gar"}
Printing out a string/array of three elements
(gdb) bt
Print out the current contents of the stack.
(gdb) up
Go up a level in the stack. You normally start out too low (in some
abort routine). Keep going up until you hit a sather line
(gdb) down 
Go down a stack level
(gdb) break
Set a breakpoint (easier to do from within emacs)
(gdb) break sather_main
Set a break point at the sather main.
(gdb) step
Go into the next line/call
(gdb) next
Go through the next line/call
(gdb) finish
Execute till end of current function.
(gdb) continue
Continue till the next break point 
$

TAB does symbol name completion and ESC-? provides a list of completions (useful for finding mangled function and variable names). There is currently some work being done to provide name mangling under gdb.

COMING SOON!!!!

Claudio Fleiner and I have created a tool that will allow you to quite cheaply look at all your sather variables (with the sather variable names), including stack frames from within gdb. With a higher cost in compile time, you can also look at at these data structures graphically. The option will be made available sometime after 1.0.8 (since this was developed during the 1.0.8 pre-release, we will wait till after 1.0.8 is released to merge the compiler changes with our CVS source tree).

The Sather Emacs Mode

    There is an emacs editing mode available for Sather (started by Steve Omohundro, but largely written and currently maintained by Kevin K. Lewis, lewikk@aud.alcatel.com), under the Emacs directory of the distribution. The .elc files are byte-compiled, faster versions of the .el files. The documentation for the emacs mode is available at the beginning of the file sather.el. Effective use of code highlighting requires you to set up some variables as described in the beginning of sather.el.

The Browser

Documentation for the sather browser (which is written in tcl and distributed under the Browser subdirectory of the distribution) is available from the Help/ subdirectory of the Browser directory, which is accessible from the Browser's "Help" menu.