Unitized Applications

We recommend the use of signed units for the design of MrEd applications. MrEd provides extra support for unitized applications that it does not provide for non-unitizied applications (aside from the benefits of using units). That support includes:

• The ability to only load portions of MrEd at startup, and
• an OS-like facility to startup multiple MrEd applications (all running in the same operating system process) and still provide protection between the applications. This is called MzOS.

An application consists of a collection containing at least three libraries. The first library is named info.ss and specifies the names of the other files as well as information for the splash screen. The second library contains only the main signed unit with all the definitions; and the third one specifies signatures and macros.

The initial environment for loading these libraries will include only:

• MzScheme's built-in procedures and syntax;
• The wx: procedures and classes;
• The refer.ss MzLib library; and
• The invsig.ss and debug.ss libraries from the system collection.

The info.ss library must return a procedure. That procedure must accept two argments, a symbol and a failure thunk. It will be passed various symbols to obtain information about the application. If the procedure is passed a symbol it does not recognize, it should call the failure thunk. It will be passed:

'name a string, naming the application

'app-unit-library a filename, naming the application unit. This file should be in the same collection as the info.ss file. This unit will be invoked with invoke-open-unit/sig. See Units for more info.

'app-sig-library a filename, naming the file that contains all of the signature and macro definitions . This file should be in the same collection as the info.ss file.

'splash-image-path a complete pathname, naming an image file to be used on the splash screen or #f if no splash screen should be opened (see also collection-path in library collections).

'splash-max a number, indicating how many files are loaded while the application starts.

'splash-depth a number, indicating how deep the recursive loads are.

The last three, 'splash-image-path, 'splash-max, and 'splash-depth are optional. If 'slash-image-path is not provided, no splash screen will be shown. If either of the 'splash-max or 'splash-depth is wrong or not provided, they will only be used the first time the application starts up. After that, the actual number of files is recorded and used on subsequent startups of the application. See the splash screen section for more info.

The 'app-unit-library file must contain a unit/sig that accepts only one import, matching the mred:application-imports^ signature. The signature only contains one name, argv, which will be a vector of strings representing the command line arguments. This signature is part of the initial basis in MrEd, but not in DrScheme's R4RS+ language. In DrScheme, to get this signature, evaluate: (require-library "invsig.ss" "system")

You will probably want to use the wx: and mred: names described in this manual. To do that, you should link your application to the mred library. The mred library is in the linkwx.ss file of the mred collection. It imports mzlib:core^ from MzLib and exports mred^, which contains all of the names defined in this manual.

Here is the contents of an example unit file:

(compound-unit/sig (import [I : mred:application-imports^])
   (link [mzlib : mzlib:core^ ((reference-library-unit/sig "corer.ss"))]
         [wx : wx^ (wx@)]
         [mred : mred^
            ((reference-library-unit/sig "linkwx.ss" "mred") mzlib wx)]
         [myapp : mred:application^
            ((reference-unit/sig "myapp.ss") wx mred I)])
   (export (unit myapp)))

The example unit's imports signature is the mred:application-imports^ signature, and expects myapp.ss to be a file containing a unit whose import signature is the mred^ signature, the wx^ signature and the mred:application-imports^ signature. It exports the myapp unit, which means the names exported by that unit will be put into the current namespace.

The 'app-sig-library file must contain any signature or macro defintions that the 'app-unit-library refers to. To match the above example, it must contain:

(reference-library "sig.ss" "mred")

Since most aplications will have a unit very similar to the above example, the mred collection's file: exapp.ss contains a procedure that expects a unit to used in place of myapp, above. So, using that file, the example becomes:

((reference-library "exapp.ss" "mred")
 (reference-unit/sig "myapp.ss"))

See the MrEd collections for more information about how to use the mred: names in a unitized application.

After the collection is prepared, invoke mred like this: mred -A collection

where collection is the name of the collection.

If your application fits the constraints that allow analysis by the Static Debugger (see PLT MrSpidey: Static Debugger Manual), you should use the -w flag to write out a unit that the Static Debugger recognizes. The -w flags expects a filename to come after it and after your app starts up, MrEd will write out a Static Debugger friendly file that you can then use to analyze your application. If you application uses the wx library, you will need to change the linking structure of your application to use the unit wxr.ss in the mred library.