MPW TIPS AND TRICKS

Launching MPW Faster Than a Speeding Turtle

TIM MARONEY

One myth about MPW is that it's slow, but that's an unfair description. Personally, I think "glacial" would be a more appropriate word, or perhaps "executionally challenged." However, it's possible to speed it up in a variety of ways, such as simulating the 68020 instruction set on a fully loaded Cray. On a tighter budget, you can improve MPW's launch time just by making some minor changes to your configuration.

Perhaps some of you are asking, "Who cares about launch time? Compile speed is the important thing! God built the whole world in less time than it takes me to compile my project with PPCC, and he only had a slide rule!" It's a valid objection, and I'm glad you brought it up, but many people launch MPW more often than they compile. Quite a few projects use MPW as a development workhorse because of its scripting and source control capabilities, but compile and link using language systems that aren't laboring under the delusion that they're getting paid by the hour.

I didn't invent this technique, but I've tuned it up and eliminated some trouble spots. The original was distributed on a Developer CD so old that I can't find it now. *

STATES' RITES
The trick is simple and capitalizes on an important fact about MPW tools. Because of the innovative approach MPW takes to the traditional TTY interface, it's easy to execute the output of tools by selecting the output with the mouse and pressing the Enter key. Tool writers are strongly encouraged to write executable commands as their output. Since some of the tool writers didn't get the message, there are umpty-million exceptions, but when the tool does the right thing it's very useful.

There's an even better way to select the output, which is to press Command-Z twice after running the tool, but don't say I told you so. On the Macintosh, Undo followed by Redo is supposed to return you to your original state. *

The nice people responsible for the Set, Export, Alias, AddMenu, SetKey, CheckOutDir, and MountProject commands followed MPW policy and made them reversible: giving these commands without parameters dumps a list of commands that you can execute later to return to your current state.

As it happens, in a standard MPW configuration there's not much to your state beyond the output of these seven commands. You're in a current directory and some file windows might be open, and that's about all that matters. You can save the directory and the open files with four lines of script.

You can probably see where all this is leading. MPW lets you install scripts that get run when it quits and when it starts up. Is it really faster to save your state when you quit and restore it on your next launch than it is to iterate over your startup files? The answer is an emphatic yes, at least with the usual baroque MPW configuration. You'll see much less improvement if you're already using a lightweight MPW without many startup files.

Now if you're clever, you've probably written all kinds of things that need to get loaded each time you start up. I can understand that -- I often feel like I need to get loaded every time I launch the MPW Shell myself! Maybe you've written a tool that lets you add hierarchical menus to the MPW Shell so that you can keep your wrist muscles toned, or a floating utility window with buttons for your frequently used commands. These clever hacks are going to hurt your startup time, but if you must do something every time you start up the Shell, you can move these commands into separate files that still get executed on each launch.

THAT DOES IT - I QUIT!
Saving the state is the easiest part of the trick. Just put a file named Quit in your MPW folder. You can overwrite the default Quit script if you have one, but if you need to keep it, you can name this script Quit*SaveState instead; the default Quit script will run it, as well as any other scripts named Quit*Whatever. The script should read like this, more or less:

# Quit and save state for fast startup

# We need to set Exit to 0 so that errors won't
# cause Quit or Startup to bomb, but we also want
# to maintain the user's setting of the Exit
# variable. Save and restore it.
Set SaveExit {Exit}
Export SaveExit
Set Exit 0

# State saving is turned off by creating a file
# named DontSaveState in the MPW folder.
If "`Exists "{ShellDirectory}"DontSaveState`"
    Delete -i "{ShellDirectory}"DontSaveState ð
        "{ShellDirectory}"MPW.SuspendState ð
        ≥ Dev:Null
        
Else

    # Write the state to a temporary file.
    Begin

        # Tell the restoration not to bomb.
        Echo Set Exit 0

        # Save the custom menus.
        AddMenu

        # Save the current directory.
        Echo Directory "`Directory`"
        
        # Save the open windows.
        Echo For window In "`Windows`"
        Echo '  Open "{window}" || Set Status 0'
        Echo 'End ≥ Dev:Null'
    
        # Save the aliases.
        Alias

        # Save the variables.
        Set

        # Save the exports. This runs much faster 
        # with all the exports on one line, so we
        # use -s to get all the names at once.
        Echo Export "`Export -s`"
                
        # Save the key assignments.
        SetKey
        # Save lines that will execute the UserMount
        # script if any. The script doesn't have to
        # exist, and it's harmless to throw it away
        # between saving and restoring state.
        If "`Exists "{ShellDirectory}"UserMount`"
            Echo Execute ð
                "{ShellDirectory}"UserMount ð
                "≥ Dev:Null"
        End

        # Save the mounted Projector databases and
        # their checkout directories.
        MountProject
        CheckOutDir -r

        # After the rest of the state is restored
        # with Exit set to 0 to prevent bombing,
        # save lines to restore the user's setting
        # of Exit.
        Echo Set Exit '{SaveExit}'

    End > "{ShellDirectory}"MPW.SuspendState ð
         ≥ Dev:Null

End

# Sometimes anomalies prevent the Worksheet from
# auto-saving at Quit time; make sure it does.
Save "{Worksheet}"

Every time you quit the MPW Shell normally, this Quit script will save your complete state to a file named MPW.SuspendState in your MPW folder. You probablynoticed that this can be turned off by creating a file named DontSaveState. You don't have to do this by hand; if you'll just wait a gosh- darn minute, I'll give you a menu command for it.

Unfortunately, the Choose command, which lets you mount a file server, isn't reversible; that is, it doesn't put out a list of Choose commands that you could run later to remount your servers. Using this Quit script, though, you can create a file named UserMount in your MPW folder that will be executed every time you launch, before any attempt is made to remount your saved projects. This file should contain Choose commands that mount the servers on which your Projector databases are located. If you're not using Projector or other remote services, there's no reason to create this file. Here's an example, assuming I have a Projector database on the volume "Rendezvous" on the server "Development" in the zone "Engineering Heck":

if !"`Exists Rendezvous:`"
    choose -u 'Tim Maroney' -askpw ð
        "Engineering Heck:Development:Rendezvous"
end

First, observe the use of the back quote ( `), that otherwise useless key at the top left of your keyboard. MPW uses it the same way ascsh (pronounced "sea-shell"), the seminal UNIX shell from Berkeley: a command inside back quotes is executed and its output is inserted into the command line containing it. In this case, the Directory, Windows, and Export commands are backquoted, capturing their output so that it can be combined with other text using the Echo command. The Exists command is backquoted so that its output can be treated as a conditional expression.

Another handy fact is that compound statements, like Begin...End blocks, conditionals, and loops, are treated as single commands that can be redirected in their entirety. This saves a lot of needless repetition: you don't have to redirect each statement inside the block. Note the use of the error redirection operator ">=", typed as Option-period. Like UNIX, MPW Shell has separate output and error channels that can be redirected independently. In this Quit script, errors are redirected to yet another UNIXism, the faux file "Dev:Null," which is another way of saying send them to oblivion.

You can find out more about the various redirection options in MPW by starting up the MPW Shell and giving the command Help Characters. For clarity, the help text refers to the error channel as the "diagnostic file specification." *

One very important feature of MPW is its set of built-in variables. You can set up any variables you want by using the Set command, and expand them by putting them in curly brackets; there are also quite a few built-in variables that tell you things about the state of the MPW Shell and let you modify its behavior. The ShellDirectory variable is used extensively in the script; when expanded ("{ShellDirectory}") it yields the path name of the folder containing the MPW Shell, where many useful things are stored. The old name for this variable is "MPW," which you can still use as a synonym.

Another built-in variable is Exit. If Exit isn't 0, script commands that fail will bring the execution of their script to a screeching halt; if it is 0, subsequent script commands will go on regardless of earlier failures, much like some people's conversational gambits at trade-show parties. These fast-launch scripts set Exit to 0, because if there's a failure at some point, the rest of the state should still be saved and restored. In normal MPW setups, Exit is set to 1 most of the time, but since idiosyncratic MPW configurations set it to 0 as the default, some special work is needed to save and restore the user's Exit setting. This is done by saving Exit in a custom variable named SaveExit, which records Exit at the beginning of the Quit script and restores it at the conclusion of the MPW.SuspendState script.

HAPPINESS IS A WARM BOOT
The startup sequence is slightly more complicated. After all, you've got to iterate over all those startup files sometime. The approach I'm using distinguishes between a cold boot, which does a pretty normal startup, and a warm boot, which starts up quickly from MPW.SuspendState.

"Cold boot" and "warm boot" are terms that old-time programmers will remember from the manual kick-starters on the original Model T computers.*

There's a menu item you can use to force the next launch to be a cold boot, or you can throw away the MPW.SuspendState file before launching for the same effect. The cold boot mechanism exists mostly for the sake of paranoia, so programmers tend to use it frequently. Generally speaking, you don't need to do a cold boot after you change your startup files; you can just select the change and press Enter. The modifications will get stored in the saved state the next time you quit.

MPW comes with a file named Startup that gets executed each time the Shell is launched. Rename Startup to ColdStartup and put the following in a new Startup file:

# Restore the state if possible; else cold boot.
# ∑∑ means redirect to end of file.
If "`Exists "{ShellDirectory}MPW.SuspendState"`"
    Execute "{ShellDirectory}MPW.SuspendState"
       ∑∑ "{Worksheet}"
    Set ColdBoot 0
Else
    Beep 2g,3 2f,3 2a,3     # Hum a merry tune
    Begin
        Echo "MPW.SuspendState was not found."
        Echo "Here's your Cold Boot..."
    End ∑∑ "{Worksheet}"
    Execute "{ShellDirectory}ColdStartup"
    Set ColdBoot 1
End

Export ColdBoot

# Do anything that needs doing each launch
# (UserStartup*X files in EachBoot folder).
If "`Exists -d "{ShellDirectory}EachBoot"`"
    For fileName in `(Files ð
                "{ShellDirectory}"EachBoot:UserStartup*≈ ð
                || Set Status 0) >= Dev:Null`
        Execute "{fileName}"
    End
    Unset fileName
End
Unset ColdBoot

The default Startup script runs all the files whose names start with "UserStartup*" in the MPW folder: UserStartup*Utilities, UserStartup*EraseBootBlocks, UserStartup*AlterPersonnelRecords, and so forth. You just moved the default Startup script to ColdStartup, so these files will get reexecuted whenever you do a cold boot. Also, in case you need to do something every time you launch regardless of whether it's a cold or a warm boot, you can put it in a UserStartup*Whatever file in a folder named EachBoot in the MPW folder.

Sometimes you need to do something different at startup depending on whether it's a cold or a warm boot. The Startup script above sets a variable named ColdBoot so that you can distinguish between cold and warm startups. In one of your startup scripts, you can use the ColdBoot variable in a conditional construct. For instance, suppose you're part of a large project with a centrally maintained MPW configuration that uses a custom tool named HierMenu to create a hierarchical menu. HierMenu is called from the central UserStartup*Project script at cold boot, but because it's not a standard part of MPW, it also needs to get called from an EachBoot script at warm boot -- the state isn't automatically saved by the Quit script. You don't want to edit the shared file UserStartup*Project because you'll have to laboriously reapply your change every time the build engineers improve the central copy, but you can't run HierMenu more than once without bringing the system to its knees. The solution is to create a UserStartup*DoHierMenu file in your EachBoot folder which only runs HierMenu in the case of a warm boot, like so:

If ¬ "{ColdBoot}"
HierMenu HierItem MainMenu 'Title for Item'
End

I promised you a menu command to do a cold boot. Here it is (in the immortal words of Heidi Fleiss, don't say I never gave you anything). Put this in a file named UserStartup*ColdBootItem in your MPW folder:

AddMenu File '(-' '' # menu separator
AddMenu File "Quit with Cold Boot..." ð
    'confirm "Quit with cold boot?" && ð (Set Exit 0; ð
    Echo > "{ShellDirectory}"DontSaveState; ð
    Quit)'

MEASURING PERFORMANCE WISELY
If you measure performance by elapsed time, MPW can be slow. However, real-world performance has more to do with usefulness than with theoretical throughput. I don't use my computer to run Dhrystone benchmarks: I use it to accomplish tasks. MPW gives me the power to accomplish the complex and bizarre tasks of programming automatically.

Real-world friendliness is always relative to a particular set of users and a particular set of tasks. The very things that make UNIX and MPW unfriendly to novice users make them friendly to programmers, who have the unusual skill of memorizing arcane commands and connecting them in useful ways. Don't get me wrong; MPW is not the final frontier of development environments. A true next-generation software authoring system would make command shells and project files seem equally ridiculous, but command-line interfaces for programmers are a sound approach, at least for now. And with a little tuning, they can begreatly improved. In future columns I'll be sharing more tips on making the worksheet a pleasant place to live.

TIM MARONEY is a leather-wearing vegetarian from Berkeley, California. He's been published in MacTutor and Gnosis magazines and in the San Francisco Chronicle. Tim is currently working as a contractor at Apple on the next release of the Macintosh operating system. When he's not standing on his head, he's usually peering at eldritch tomes such as the R'lyeh Text and the SOM User's Guide. No, that's not what we expected him to look like either. *

Thanks to Dave Evans, Greg Robbins, and Jeroen Schalk for reviewing this column. Thanks also to beta testers Arnaud Gourdol, Jon Kalb, and Ron Reynolds.*