This release of the Modula-3 AST Toolkit (2.1) contains a number of
bug fixes, plus a number of improvements to the "m3check" tool.  A few
packages (m3tk-files, m3tk-toolframe, m3tk-syn, m3tk-dep) have
interface changes, that might require client recompilation, so these
are indicated by a version change (.2 -> .2.1).

Here are some details:

m3check.2.1
-----------

Bugs fixed:
-----------
1. Crash when removing a generic instantiation that had certain errors 
(e.g. formal/actual mismatch) which caused the instantiated AST to 
be null. 

2. The "WhoImports X" command was reporting all imports of X as indirect
(marked by an *). 

3. Doesnt crash when warning about unused variables.

4. No spurious error message generated when assigning to a field "x"
   of an object type in a NEW, when a method "x" exists earlier in the
   type hierarchy.

5. No crash after reporting the illegal import of a generic interface.

New commands:
-------------
Last

  Repeat the last command

Dir dir

  Iff you started m3check up with the -D option, prepend directory
  "dir" to the search path.

Performance improvements/New features.

1. I have reworked the code which scans the file system for changes,
   and fixed the odd performance buglet. As a result, the "Scan" command
   is substantially faster, sufficiently so that it can be used routinely
   after edits. As part of this rework I have (finally!) separated
   the command which scans for changes from the compilation comands.
   The new command "ScanDirs" does the former and the new command
   "Compile" compiles changed and dependent modules. The old "Scan" command
   is defined as "ScanDirs; Compile", for compatibility with previous
   versions. "ScanDirs" essentially snapshots the state of the external
   world, affecting commands like "ListUnits", and can be invoked
   repeatedly without performing compilations. A "Compile" compiles
   those units that have changed, and dependent units, based on the
   current snapshot and the one that was in effect at the time of
   the last invocation of "Compile".

   In addition, the default state of a directory in which to find
   interfaces is now read-only. I excerpt from the man page:

     Initially, m3check designates all directories on the search path, other
     than the current working directory and those specified with the
     CompileInDir list, as read-only. After the initial scan of the file
     system, a read-only directory is not re-scanned. That is, the
     information last gathered is assumed still to be accurate.  This
     strategy helps to minimise the duration of subsequent scans.  However,
     it is possible to toggle the read-only status of a directory via the
     interactive command ChangeDirStatus (see below). So, for example, if a
     library directory is updated during the execution of m3check, you can
     change its status to writable, scan for the updated files, and then set
     the status back to read-only.  Note that the current working directory
     cannot be made read-only.

   The "ChangeDirStatus" command takes a pathname and either a "R" or "W"
   as arguments, and sets the status accrdingly.

   Many other command that used to be slow, e.g. "ListUnits",
   "WriteM3Makefile", now execute much faster.

2. If the file ".m3check" exists in the directory from which m3check
   is invoked, the commands in the file are executed immediately on
   startup, before any "InitialCommands" on the command line, and
   before entering interactive mode. 

3. In case you are confused about which version of a unit m3check
   is compiling, you can list its full pathname and date of
   last modification with the "ShowLocationInterface" or
   "ShowLocationModule" commands.

4. If you define search paths with "m3path" files, you can "freeze"
   the current path (p) as if you had initially started "m3check" up
   with a "-D p" on the command line. This avoids re-reading the
   "m3path" files in all those directories, and repeatedly
   forming, presumably, the same transitive closure. The command to
   do this is "FreezeM3Path" and can be executed after at least
   one "ScanDirs".

5. I have documented the "@" command for interactively executing
   a set of commands from a file.


shell-compile
-------------
Although it's use is not restricted to m3check, I have included
some gnuemacs lisp code to handle error messages in *shell*
buffers. The idea being that you run m3check under a gnuemacs shell
and process the errors in place. Here is a description:

;; This is a hack of the standard compile code to work in a
;; *shell* buffer. The function shell-next-error, bound to
;; C-cC-n, takes the next error message off the list held in
;; shell-compilation-error-list, and behaves exactly as the
;; standard next-error function. If the list is empty, new
;; errors are searched for starting at the buffer position given
;; by the variable shell-compilation-parsing-end, which 
;; initially has the value 1. You can reset the value with
;; C-cC-s, which sets the variable to the cursor position, 
;; and throws away the current list of errors. You can use
;; this to give up on a batch of errors by keying C-cC-s
;; with the cursor set after the last error message, or revisit
;; an earlier message by keying C-cC-s with the cursor set
;; just before the message and then keying C-cC-n.

;; It is left up to you to decide if you want to rebind
;; the standard key binding for next-error (C-x`) to
;; shell-next-error.


Mick Jordan, October 8th 1992.