Documentation

The Sixth Edition Mx Manual (2004) is now fully integrated into the Mx Manual which is available in Postscript and Adobe PDF formats. Also see the Quick Reference Chart, known as the Mx Key on that page.

Downloading Software

• Please note that Win3.1 support will be no longer available.
• Upgrade if there is new version of backend and front end by clicking help/about menu
• Mouse roller support
• Changing variable font of selected node by clicking Preference/font/variable font menu
• Interfacing to Merlin package
• Data file generation and editing in GUI
• Mx header window, which allows parameterized style script to be run
• Allow sub and super index for both path label and variable names
• Change color for all drawings, for easy copy/paste to other application
• Synchronized error message with backend
• Simple Emacs editor key strokes

Important note for Windows-XP users

For Windows-XP users with administrator privileges (e.g., Administrator), you can install MxGui to the default folder, which is “C:\Program Files\mx”. If you then want other users to use the examples, you will need to copy all files in the “C:\Program Files\mx\examples” to a folder where the user has write access and instruct user to run the examples in that subdirectory. You can also install MxGui to a non-system folder such as “C:\mx”. Users who do not have administrator privilege can only install MxGui to a folder to which they have write access.

So, in summary: installation to C:\mx will always work for XP. Installation to C:\program files\mx will work for the administrator only.

System	Version	Date
Mx Win9x/2K/NT version 2.5MB	1.7.03	Oct. 30, 2009
Unix servers (see below)	1.50ish	June 2001
Setup for 64bits OS	1.7.03	May 17, 2009

Mx Unix Server

Download the unix server for your system by clicking the appropriate link in the table below. It’s best if the system administrator does the installation but you can install your own personal copy if they won’t cooperate.

Install MX on Unix

1. Download the compressed tar file for your unix system
2. Unpack it with a command such as: zcat mx-sys.tar.Z | tar xvf –

This will create a directory mx-1.42/ that contains the binary program files, and an INSTALL file with installation instructions. Please let us know if you run into difficulties.

Basically all that is involved is copying the binaries from mx-1.42 to /usr/local/bin or to a similar location that is typically in every user’s path.

System	Version	Date
Digital Unix 4.0D (OSF/1)	1.50	Dec 09, 1999
Linux (generic)	1.52b	Jan 22, 2004
Mac OSX **	1.55	Apr 22, 2004
Sunos 5.7	1.50	Apr. 07, 2000
SGI Irix 6.2	1.50
HPUX	1.50	Dec 09, 1999
IBM AIX 4.1	1.50	Dec 09, 1999

**Note: you may also require installation of these libraries in a directory /opt/ibmcmp/lib (use, e.g., cd /opt/ibmcmp ; zcat ibmlibs.tar.gz | tar xvf – to install); and mkdir /opt/ibmcmp if needed first.

Installation

New installation

For a new installation, save mxgui.zip to an empty directory. Unzip it, using a windows shareware zip utility such as Winzip or a DOS one like Pkunzip. Run the setup utility to install the program.

Update Version

To install the update simply unzip into the bin sub-directory of the MxGui installation directory, and allow it to overwrite the files.

Notes

To ensure easy installation on all systems, all the system files are written to the install directory. Nothing is written to your local system directory (e.g., C:\windows\system). If your system directory is on a write-protected network drive, install will work fine, but you may not see the 3d effects (pretty buttons etc.). To correct this, make sure you have ctl3dv2.dll in your windows/system directory (you could copy it from the bin sub-directory of the Mx GUI installation directory, if you can get permission to write these files to the system directory).

Sending Feedback

We love feedback! It’s the best way to make the software better.

Bug Reporting

Bug reporting is the first job of the Beta-Tester. Generally, it is not very difficult to find bugs in Beta release software. More difficult is the process of isolating and reporting the bug in a manner that makes it possible for the programmer to quickly reproduce and fix the bug. Anything you do to help the programmer along will speed the release of MxGUI.

So you run into a bug. What comes next? First you need to be able to reliably and repeatedly reproduce the bug. This is absolutely essential. If the programmer can’t reproduce the bug, he can’t test to see if changes in the program make the bug go away. Second, you need to be able to reproduce the bug in the minimum number of clicks and keystrokes from the time you first enter the program. It turns out that this will help the programmer in two ways. First, the programmer will need to repeatedly make changes in the source code and then run the program to test the changes. The shorter the path to reproducing the bug, the quicker he can see if his changes work. Second, and more importantly, by isolating the bug to its minimum cause, you have managed to tell the programmer where to look in the code for the source of the bug. A clever Beta-Tester can save a programmer hours or sometimes even days of debugging effort tracking down a single bug in tens of thousands of lines of source code.

How does an Beta-Tester find the minimum steps that will reliably recreate a bug? The first part happens _before_ you run into the bug. You need to be careful to remember exactly what you are doing at all times. That way, when you do run into a bug you can think back and recall everything you did for the past 10 or even 20 steps.

Suppose you just found a bug and now you want to be able to recreate the situation in which the bug occurs. The first mistake that novice Alpha-Testers make is that they hurry on, madly clicking this and that, hoping the bug will show itself again. Often, once a bug has manifested itself, the program will begin to exhibit many kinds of strange symptoms: all completely dependent on the first occurrence of the bug. In those cases, most often if you cure the first bug, the remaining symptoms disappear as well. The first thing to do when you encounter a bug is to carefully remember everything that led up to the bug: what panels are open, what preferences were set, and most important of all, what were you doing immediately prior to seeing the bug. It is most likely that the combination of things you were doing is what triggered the bug. The programmer needs to be able to recreate those steps in order to test his cures for the bug. So remember and write down what you were doing, even things that seemed irrelevant to you. “I just went out to the kitchen to get a glass of milk,” might be just a bit too irrelevant.

Next, you need to try to recreate the bug from scratch. By this, we mean that you need to quit the MxGUI, re-start the program and try to get to the bug in the minimum number of steps (clicks of the mouse or keystrokes). This process can be frustrating if you weren’t careful about remembering what you were doing. If you can’t recreate the bug, we will ask you to report it anyway along with your best guess of what you were doing at the time. We will then need to wait until other people run into the bug and we can correlate their reports with yours.

If you can successfully recreate the bug, it’s time to play Sherlock Holmes. Try to eliminate the impossible and whatever remains, however improbable, will be the culprit. Start the MxGUI again and see if you can recreate the bug while eliminating steps. Every time you eliminate a step, you eliminate between 10 and 1000 lines of code that the programmer doesn’t have to consider as a potential cause for the bug. Soon, you will most likely develop a theory for why this bug occurs. We want you to report both the minimum steps to recreate the bug, and your theory for why the bug occurs. A good Beta-Tester can speed up the process of fixing bugs by an order of magnitude.

User Interface Reporting

We need to know about how people perceive the MxGUI software interface. Some things may be surprisingly easy to do and others may be surprisingly difficult. We have been working on MxGUI for so long and we know it so intimately that we can never have the fresh perspective that you have. We need to know what you think about the interface in detail: both the good parts and the bad parts.

It would help us if you kept something of a journal of your experiences with the interface as you first learn to use it. Write down everything that surprises you. If the program does something you don’t expect — something that’s not a bug but just confusing — write it down. If you get yourself into a dead-end where you just can’t get the program to behave the way you wish it would, write it down. Of course, after you’ve learned the program you will know what to expect. That’s why we need you to write it down just as you are first learning to use it. These journals will help us in two ways. First, we can use them to improve our documentation and help files to answer questions from other people who will be confused in the same way as you were. Second, we may be able to change elements of the interface in future releases to eliminate the confusing and unexpected behaviors. The ideal interface works just as people expect and no one needs to refer to the documentation at all.

We would love to received critiques of the interface after you have been using it for some time. Remember, there is a better chance of us meeting your wish-list for features in future releases if you tell us what your wish-list is!

If you want to experiment with other example Mx scripts they can be downloaded from the Mx examples page

Mx Gui Bugs

Known problems with the Mx Gui:

• Some path diagrams from earlier versions may be difficult to modify. This is being worked on.

Please send feedback to the Mx Developer.