Add'l notes by Guido
diff --git a/Mac/MPW/README b/Mac/MPW/README
index 004ea43..f63b106 100644
--- a/Mac/MPW/README
+++ b/Mac/MPW/README
@@ -45,5 +45,62 @@
try defining the preprocessor symbol "MPW_881_BUG" in
file "Parser:acceler.c", function "fixstate", line 107.
-XXX Note that you have to edit test_grammar.py because of a bug
-in int overflow det that I haven't found yet.
+---------------------------------------------------------------
+
+Additional notes by Guido for Python 1.1:
+-----------------------------------------
+
+I have tried this with MPW 3.2 and tweaked Richards Makefiles and
+buildall script slightly to work with Python 1.1. The same configure
+file now works for THINK C 6.0 and MPW 3.2. It is essential that
+'MPW' is defined when compiling with MPW; for both compilers,
+'HAVE_CONFIG_H' should also be defined. For MPW, the buildall script
+takes care of this.
+
+I moved some files around or renamed them and modified the Makefiles
+accordingly. All Mac specific files are now in the Mac subdirectory,
+especially config.c, config.h, macmodule.c, and (new) macmain.c.
+
+I wouldn't bother with the Grammar subdirectory or the Parser generator
+(Pgen) -- the needed Pgen output files are part of the distribution.
+
+If the buildall script stops at a compilation error you are usually
+left in one of the subordinate directories.
+
+Instead of using the buildall script you can also once execute the Set
+and Export commands listed at its top (which set compiler and linker
+options) and in each of the directories Mac, Parser, Python, Objects,
+Modules and finally the python rot directory, execute the two command
+
+ make >makefile.out
+ makefile.out
+
+Or you could execute
+
+ make
+
+have a look at its output and execute selected commands from it.
+
+The buildall script executes
+
+ Directory {Python}
+
+which normally prints the current directory, because {Python}
+is not defined. If it is set to the python root directory,
+you could place buildall somewhere in your command search path and
+execute it from anywhere.
+
+If you are mixing THINK C and MPW, you may experience weird errors
+in correct modules. These disappear when you throw away the
+module's .pyc file. The errors usually have to do with string
+literals containing '\n' or '\r'. The reason is an incompatibility
+between their handling of '\n' and '\r' -- in MPW C, '\n' actually is
+ASCII CR while '\r' is ASCII LF, which is the reverse situation from
+any other ASCII based C implementation. This behaviour is inherited
+by Python compiled with MPW C. This is normally not a problem,
+but *binary* files written by one system will be mis-interpreted
+by the other, and this is what happens to the .pyc files. There is no
+easy way to fix this in the source. (This is a real shame, since the
+format of .pyc files was carefully designed to be independent of
+byte order and integer size -- deviations in the ASCII character codes
+were never anticipated.)