Add'l notes by Guido

Mac/MPW/README

@@ -45,5 +45,62 @@ at the end of the function "finddfa", line 46,
 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.)