Starting Up

  MrEd starts up with the following sequence:

   
• System File: The system  is read from a file called ``mrsystem.ss '' with the following search path on Windows and Unix:
  • The search path defined by the MREDSYS  system evironment variable
  • The ``PLTHOME/mred/system'', where ``PLTHOME'' is replaced with the value of the PLTHOME  environment variable
  • In the ``system'' directory in the current working directory (Windows only)
  • The ``/usr/local/lib/plt/mred/system '' directory (Unix only)
  • The ``/usr/lib/plt/mred/system '' directory (Unix only)
  • The ``/usr/local/lib/mred/system '' directory (Unix only)
  • The ``/usr/lib/mred/system '' directory (Unix only)
  and one the Macintosh will look first in the current working directory and second in a directory named system in the current working directory.

  A different system can be specified with the ``-s '' flag; this flag must be the fist command line flag and the system file name must be the next argument. (Command line flags on the Macintosh are discussed below.)

• mzlib: The system sets the MzScheme library path and loads the core mzlib library. The search path for the mzlib library is:
  • One directory up, then into a ``mzlib'' directory.
  • One directory up, then into a ``mzscheme'' directory and then ``mzlib'' directory.
  • Two directories up, then into a ``mzscheme'' directory and then ``mzlib'' directory.
  • ``PLTHOME/mzscheme/mzlib'', where ``PLTHOME'' is replaced with the value of the PLTHOME  environment variable. If the environment variable is undefined, ``/usr/local/lib/plt/ (Unix) or ``C: PLT'' (Windows) is used. (Unix and Windows only)

  In addition to setting the MzScheme library path, the system defines two global path variables:

  •  mred:system-source-directory -- The system's directory.
  •  mred:plt-home-directory -- The home directory for PLT tools. If the environment variable PLTHOME is defined, it is used. Otherwise, if there is a grandparent directory of mred:system-source-directory, it is used. If PLTHOME is not defined and mred:system-source-directory does not have a grandparent, mred:system-source-directory is used directly.

  Both mred:system-source-directory and mred:plt-home-directory are normalized paths.

• Initialization: After the system is loaded, mred:initialize is called with the remaining command line arguments, as strings.

    These are the recognized command-line flags:

  -e The next argument is evaluated as a Scheme expression. The -f flag can be specified many times to load many files.

  -f The next argument is treated as a Scheme filename and is loaded. The -f flag can be specified many times to load many files.

  -nu This is used to specify a non-unit startup. See below for more information.

  -- If this flag is encountered, all remaining command line areguments are treated as filenames and are opened for editing.

  If a filename is by itself on the command line it is opend for editing.

  For example, this Unix shell command starts up MrEd with the default system, defines testing to be #t, and loads the file ``myprog.ss'' and opens ``mynextprog.ss'' for editing

   
    mred -e "(define testing #t)" -f myprog.ss mynextprog.ss 
  

• Application Startup: After the command line arguments have been processed, mred:make-application@ is called. mred:make-application@ is expected to be a thunk which returns a signed unit which imports both mred^ and mzlib:core^, and defines all of the identifiers in the signature mred:application^. That signed unit is then linked with mred@, to produce all of the system.
• User Setup: Finally the system mred:user-setup loads ``.mredrc '' from the user's home directory (``mredrc.ss '' in the current working directory for Windows and the Macintosh) if the file exists.

  The user setup is not always loaded last. In general it is loaded when all of the variables that begin with ``mred:'' are defined. So, if you are using the ``-nu'' flag, the user setup is loaded before any of the files on the command line are loaded and if you are not using the ``-nu'' flag, the user setup is loaded after all of the command line arguments have been processed.

If you are writing your own MrEd application, you will need to redefine mred:make-application@. It should return a signed unit matching the mred:application^ signature. It should import identifiers defined in mred^ and in mzlib:core^. mred^ contains all of the system, and mred:application^ contains two identifiers, console and eval-string. console should be a frame which will be used as the application's main frame. If it is not a frame, MrEd will create a frame with only a quit button to be the application's main frame. eval-string should take one argument, a string, and evaluate it. If your application does not include an evaluator eval-string can just return (void).

Also, you may want to redefine mred:make-invokable-unit. mred:make-invokable-unit builds a signed compound unit which links together the system and the result of mred:make-application@. If your applicatoin needs to change the linking interface, redefine mred:make-invokable-unit. See mrsystem.ss in the MrEd system directory for an example.

If you want to make a mred application without using units, pass -nu on the command line before loading your files. If you use -nu, MrEd will call mred:startup with no arguments and use the value that mred:startup returns as the default application frame.

  If the system is not found, or if there is an uncaught error while the system is loaded, then the load is aborted and a plain text editing window is opened.

• Starting MrEd on the Macintosh
• Changing the System