M3ZUME(1)                                                            M3ZUME(1)

NAME
       m3zume - create Zeus IE (interesting event) stubs from event specs

SYNTAX
       m3zume  [-testdir dir] [-Obliq ofile] [-Obliq3D ofile] [-Juno viewname]
       [-3D] eventfiles...

DESCRIPTION
       m3zume takes a relatively terse specification of events for a Zeus ani-
       mation  and produces from it the Modula-3 .i3 and .m3 files that define
       the Zeus-mediated communication between the algorithm  and  the  views.
       The event specifications are in files with ".evt" extensions.

       With  no  arguments m3zume reads the event files and for each, combines
       it with template files to produce derived files:

            <basename>AlgClass.{i3,m3},           <basename>ViewClass.{i3,m3},
            <basename>IE.{i3,m3},      <basename>DataView.{i3,m3},      <base-
       name>TranscriptView.{i3,m3,fv}, and      <basename>EventData.fv.

       where <basename> is the basename of the <eventfile>.

       When the -Obliq flag is set, m3zume reads the event file as before, and
       produces the following derived files:

            <basename><ofile>ObliqView.{i3,m3}

       When  the  -Obliq3D flag is set, m3zume reads the event file as before,
       and produces the following derived files:

            <basename><ofile>Obliq3DView.{i3,m3}

       When the -Juno flag is set, m3zume reads the event file as before,  and
       produces the following derived files:

            <basename><viewname>JunoView.{i3,m3}

       When  the  -3D  flag is set, m3zume reads the event file as before, and
       produces the following derived files:

            <basename>3DViewClass.{i3,m3},

       For testing purposes, the template file  directory  may  be  overridden
       using the -testdir command-line option.

       If  Baz()  is  an event procedure defined in Foo.evt, then FooIE.Baz is
       called to signal the occurrence of the event.
       The main part of the event file is a list of slightly modified Modula-3
       headers  for  the  procedures  that the algorithm will call to generate
       events.  Before any of these procedure  headers,  the  procedure  argu-
       ments,  followed  by  a  section introduced by the keyword ALGDATA that
       contains the data fields that should belong to a  <basename>AlgClass.T.

       The procedure headers use keywords OUTPUT, FEEDBACK, and UPDATE in lieu
       of PROCEDURE.  Output events (PROCEDURE is allowed  as  a  synonym  for
       OUTPUT)  are  generated  by  an  algorithm and delivered to views; they
       occur with VBT.mu unlocked and the algorithm Running.  Feedback  events
       are delivered to the algorithm; they are typically generated by a view.
       Feedback events occur with VBT.mu  locked  and  the  algorithm  Paused.
       Update  events  are  generated  by an algorithm in response to feedback
       events and are delivered to views; they occur with  VBT.mu  locked  and
       the algorithm Paused.

       Each  argument  type in a procedure header is followed by the name of a
       function [in square brackets] that  will  convert  the  argument  to  a
       printable  TEXT.   This function name is generally ZFmt.<something>, or
       the empty string if the argument type is TEXT.  The square brackets are
       necessary, even if the argument type is TEXT.  You don't need to IMPORT
       the ZFmt interface, but you should IMPORT any other  interfaces  needed
       for format conversion.

       m3zume  allows  only  a restricted set of argument types.  The names of
       argument types may not contain blanks (for example,  "REF  BOOLEAN"  is
       not  allowed); you may need to create an auxiliary interface that gives
       names to the types you want to use in your .evt file.  Open arrays  are
       not allowed.  Default values for arguments are not allowed.

DIAGNOSTICS
       Poor.   Malformed  event  files  may  be accepted by the first phase of
       m3zume processing, only to be rejected during the second phase  (m3pp).
       Even  worse,  if the first phase detects an error, the error message it
       produces will only show up in the output file as an  unparsable  state-
       ment flagged by m3pp.

BUGS
       The  derived  modules  that m3zume produces may have unused interfaces,
       variables, and/or procedures.  Expect a few warnings from the compiler.
       (Ignore  this  unless  you have to modify a template file.)  The IMPORT
       statements in template files must have the word "IMPORT" at the head of
       the  line  and  have all the imports on a single line.  This simplifies
       the task of complying with Modula-3's restriction that  interfaces  may
       be imported only once.
       The  -GEF flag is no longer supported. See Steve Glassman if you'd like
       to take over the GEF package.
       John Hershberger
       John Hershberger and Marc H. Brown

                                                                     M3ZUME(1)