Were copied to Relnotes-1.[12] long ago...

2 files changed, 0 insertions, 300 deletions

diff --git a/Mac/README b/Mac/README
deleted file mode 100644
index f11e343..0000000
--- a/Mac/README
+++ /dev/null
@@ -1,169 +0,0 @@
-BUILDING PYTHON 1.2 FOR THE MACINTOSH
-*************************************
-
-Python can be built on the Mac using either THINK C 6.0 (or 7.0), or
-CodeWarrior 5.0 (for 68K and PPC).  In the past it has also been compiled
-with earlier versions of Think, but no guarantees are made that the
-source is still compatible with those versions.  (Think C 5.0 appears
-to be OK.)  Likewise, new compiler versions may effectively change the
-language accepted (or the library provided!)  and thus cause problems.
-
-MPW is a special case -- it used to be possible to build Python as
-an MPW tool using MPW 3.2, and this may still work, but I haven't
-tried this lately.  What I have tried, however, is building Python
-as a shared library for CFM-68K, using the Symantec C compiler for MPW.
-See subdirectory MPW and the README file there for more info.
-
-
-1. Using Think C 6.0 (or 7.0)
-=============================
-
-1.1 The directory structure
----------------------------
-
-I duplicate the UNIX directory structure from the distribution.  The
-subdirectories needed to compile are: Mac, Include, Parser, Python,
-Objects, Modules.  (Don't bother with Grammar and the parser
-generator, nor with the Doc subdirectory.)
-
-For running and testing, you also need Lib and its subdirectories test
-and stdwin.  You could also copy some things from the Demo/stdwin
-directory (unfortunately most other demos are UNIX specific and even
-many stdwin demos are).
-
-Make sure there is no config.c file in the Modules subdirectory (if
-you copy from a directory where you have done a UNIX build this might
-occur).  Also don't use the config.h generated on UNIX.
-
-1.2 The project file
---------------------
-
-I put all source files in one project, which I place in the parent
-directory of the source directories.
-
-1.2.1 Project type
-
-(This is the Set Project Type... dialog in the Project menu.)
-
-Set the creator to PYTH; turn on "far data"; leave "far code" and
-"separate strs" unchecked (they just serve to bloat the application).
-A partition size of 1000K should be enough to run the standard test
-suite (which requires a lot of memory because it stress tests the
-parser quite a bit) and most demos or medium-size applications.  The
-interpreter will do basic things in as little at 500K but this may
-prevent parsing larger modules.
-
-1.2.2 Compiler options
-
-(This is the Options -> THINK C ... dialog in the Edit menu.)
-
-	- Start with Factory Settings.
-
-	- In the Prefix, remove #include <MacHeaders> and add
-		#define HAVE_CONFIG_H
-
-	- Choose any optimizer and debugger settings you like.  - You
-	can choose 4-byte ints if you want.  This requires that you
-	rebuild the ANSI and unix libraries with 4-bytes ints as well
-	(better make copies with names like ANSI 32 bit).  With 4-byte
-	ints the interpreter is marginally bigger and somewhat (~10%)
-	slower, but Python programs can use strings and lists with
-	more than 32000 items (with 2-byte ints these can cause
-	crashes).  The range of Python integers is not affected (these
-	are always represented as longs).  In fact, nowadays I always
-	use 4-byte integers, since it is actually rather annoying that
-	strings >= 64K cause crashes.
-
-1.2.3 Files to add
-
-(This is the Add Files... dialog in the Source menu.)
-
-The following source files must be added to the project.  I use a
-separate segment for each begin letter -- this avoids segment
-overflow, except for 'c', where you have to put either ceval.c or
-compile.c in a separate segment.  You could also group them by
-subdirectory or function, but you may still have to split segments
-arbitrarily because of the 32000 bytes restriction.
-
-	- From Mac: all .c files.
-
-	- From Parser: acceler.c, grammar1.c,
-	myreadline.c, node.c, parser.c, parsetok.c, tokenizer.c.
-
-	- From Python: bltinmodule.c, ceval.c, cgensupport.c,
-	compile.c, errors.c, getargs.c getopt.c, graminit.c, import.c,
-	importdl.c, marshal.c, modsupport.c, mystrtoul.c,
-	pythonmain.c, pythonrun.c, sigcheck.c, structmember.c,
-	sysmodule.c, traceback.c (i.e. all .c files except dup2.c,
-	fmod.c, frozenmain.c, getcwd.c, getmtime.c, memmove.c,
-	sigcheck.c, strerror.c, strtod.c, thread.c)
-
-	- From Objects: all .c files except xxobject.c.
-
-	- From Modules: all the modules listed in config.c (in the Mac
-	subdirectory) in the initializer for inittab[], before
-	"ADDMODULE MARKER 2".  Also add md5c.c if you add md5module.c,
-	and regexpr.c if you add regexmodule.c.  (You'll find
-	macmodule.c in the Mac subdirectory, so it should already have
-	been added in a previous step.)  Note that for most modules,
-	the source file is called <name>module.c, but for a few long
-	module names it is just <module>.c.  Don't add stdwinmodule.c
-	yet,
-
-The following THINK C libraries must be added: from Standard
-Libraries, ANSI and unix; from Mac Libraries, MacTraps.  I put each
-library in a separate segment.  Also see my earlier remark on 4-byte
-ints.
-
-1.4 Adding STDWIN
------------------
-
-STDWIN is built in two separate projects: stdwin.pi contains the core
-STDWIN implementation from Ports/mac, textedit.pi contains the files
-from Packs/textedit.  Use the same compiler options as for Python and
-the same general source setup (in a sister directory of the toplevel
-Python directory).  Put all sources in the same segment.  To
-stdwin.pi, also add Tools/strdup.c and Gen/wtextbreak.c.
-
-The two projects can now be added as libraries to the Python project.
-You must also add stdwinmodule.c and add "#define USE_STDWIN" to the
-Prefix in the compiler options dialog (this only affects macmain.c and
-config.c).
-
-Note that stdwinmodule.c contains an #include statement that
-references "stdwin.h" by relative path name -- if the stdwin toplevel
-directory is not a sibling of the python toplevel directory, you may
-have to adjust the number of colons in the pathname.
-
-1.5 Resources
--------------
-
-Since I created them with ResEdit I have no text source of the
-resources needed to give the application an icon etc...  You can copy
-the size, bundle, file reference and icon resources from the
-distributed Python application with ResEdit.  THINK C automatically
-copies resources into the application file from a file
-<projectname>.rsrc.
-
-1.6 Think C 5.0
----------------
-
-Tim Gilbert adds one note that will be helpful to future Think C 5.0
-users: When you have a really big project like python, and you want to
-compile and run it, if you just hit Command-R, often Think C will
-compile the remaining files, think for a moment, and then give you a
-warning "internal error(ZREF)--please remove objects."  Don't listen
-to it.  It is lying.  What you should do instead is "Check Link..."
-and _then_ hit Run.  Why?  Ask Symantec.
-
-
-2. Using MicroWerks CodeWarrior 5.0
-===================================
-
-Essentially, follow the instructions for Think C.
-
-XXX Should at least list the project options.
-
-
---Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
-<URL:http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>
diff --git a/Mac/USING b/Mac/USING
deleted file mode 100644
index 364c3ec..0000000
--- a/Mac/USING
+++ /dev/null
@@ -1,131 +0,0 @@
-PYTHON RELEASE NOTES FOR THE MACINTOSH
-
-VERSION 1.1
-
-For the most part, Python on the Mac works just like Python under UNIX.
-The most important differences are:
-
-- Since there is no shell environment on the Mac, the start-up file
-  has a fixed name: PythonStartup.  If a file by this name exists
-  (either in the current folder or in the system folder) it is executed
-  when an interactive interpreter is started.
-
-- The default search path for modules is different: first the current
-  directory is searched, then the subdirectories 'lib', 'lib:stdwin' and
-  'demo'.  As always, you can change this (e.g. in your PythonStartup
-  file) by assigning or appending to sys.path -- use Macintosh pathnames!
-  (The default contains no absolute paths because these are unlikely
-  to make sense on other people's hard disks.)
-
-- The user interface for typing interactive commands is different.
-  This is actually the THINK C console I/O module, which is based on
-  the Mac toolbox TextEdit.  A standard Edit menu provides Cut, Copy,
-  Paste and Clear (Undo is only there for Desk Accessories).  A minimal
-  File menu provides Quit, which immediately exits the application,
-  without the usual cleanup.  You can Copy from previous output,
-  but you can't scroll back beyond the 24x80 screen.  The TAB key
-  always brings you to the end of the current input line; indentation
-  must be entered with spaces (a single space is enough).
-  End-of-file is generated by Command-D; Command-Period interrupts.
-  There is an annoying limit in the length of an input line to a single
-  screen line (less the prompt).  Use \ to input long statements.
-  Change your program if it requires long lines typed on input.
-  Even though there is no resize box, the window can be resized by
-  dragging its bottom right corner, but the maximum size is 24x80.
-
-- Tabs in module files are interpreted as 4 (four!) spaces.  This is
-  consistent with most Mac editors that I know.  For individual files
-  you can change the tab size with a comment like
-
-	# vi:set tabsize=8:
-
-  (exactly as shown here, including the colons!).  If you are consistent
-  in always using tabs for indentation on UNIX, your files will be
-  parsed correctly on the Mac, although they may look funny if you
-  have nicely lined-up comments or tables using tabs.  Never using tabs
-  also works.  Mixing tabs and spaces to simulate 4-character indentation
-  levels is likely to fail.
-
-- You can start a script from the Finder by selecting the script and
-  the Python interpreter together and then double clicking.  If you
-  make the owner of the script PYTH (the type should always be TEXT)
-  Python will be launched if you double click it!
-  There is no way to pass command line arguments to Python scripts.
-
-- The set of built-in modules is different:
-
-  = Operating system functions for the 'os' module is provided by the
-    built-in module 'mac', not 'posix'.  This doesn't have all the
-    functions from posix, for obvious reasons (if you know the Mac
-    O/S a little bit).  The functions in os.path are provided by
-    macpath, they know about Mac pathnames etc.
-    
-  = None of the UNIX specific modules ('socket', 'pwd', 'grp' etc.)
-    exists.
-    
-  = Module 'stdwin' is always available.  It uses the Mac version of
-    STDWIN, which interfaces directly with the Mac toolbox.  The most
-    important difference is in the font names; setfont() has a second
-    argument specifying the point size and an optional third one
-    specifying the variation: a single letter character string,
-    'i' for italics, 'b' for bold.  Note that when STDWIN is waiting
-    for events, the standard File and Edit menus are inactive but
-    still visible, and (most annoyingly) the Apple menu is also inactive;
-    conversely, menus put up by STDWIN are not active when the Python is
-    reading from the keyboard.  If you open Python together with a text
-    file containing a Python script, the script will be executed and
-    a console window is only generated when the script uses standard
-    input or output.  A script that uses STDWIN exclusively for its I/O
-    will have a working Apple menu and no extraneous File/Edit menus.
-    (This is because both stdwin and stdio try to initialize the
-    windowing environment; whoever gets there first owns the Apple menu.)
-    LIMITATIONS: a few recent additions to STDWIN for X11 have not yet
-    been added to the Mac version.  There are no bitmap objects, and
-    the setwinpos() and setwinsize() methods are non--functional.
-
-- Because launching an application on the Mac is so tedious, you will
-  want to edit your program with a desk accessory editor (e.g., Sigma
-  edit) and test the changed version without leaving Python.  This is
-  possible but requires some care.  Make sure the program is a module
-  file (filename must be a Python identifier followed by '.py').  You
-  can then import it when you test it for the first time.  There are
-  now three possibilities: it contains a syntax error; it gets a runtime
-  error (unhandled exception); or it runs OK but gives wrong results.
-  (If it gives correct results, you are done testing and don't need
-  to read the rest of this paragraph. :-)  Note that the following
-  is not Mac-specific -- it's just that on UNIX it's easier to restart
-  the entire script so it's rarely useful.
-  
-  Recovery from a syntax error is easy: edit the file and import it
-  again.
-  
-  Recovery from wrong output is almost as easy: edit the file and,
-  instead of importing it, call the function reload() with the module
-  name as argument (e.g., if your module is called foo, type
-  "reload(foo)").
-  
-  Recovery from an exception is trickier.  Once the syntax is correct,
-  a 'module' entry is placed in an internal table, and following import
-  statements will not re-read the file, even if the module's initialization
-  terminated with an error (one reason why this is done is so that
-  mutually recursive modules are initialized only once).  You must
-  therefore force re-reading the module with reload(), however, if this
-  happens the first time you try to import the module, the import statement
-  itself has not completed, and your workspace does not know the module
-  name (even though the internal table of moduesl does!).  The trick is
-  to first import the module again, then reload it.  For instance,
-  "import foo; reload(foo)".  Because the module object already exists
-  internally, the import statement does not attempt to execute the
-  module again -- it just places it in your workspace.
-  
-  When you edit a module you don't have to worry about the corresponding
-  '.pyc' file (a "compiled" version of the module, which loads much faster
-  than the textual version): the interpreter notices that the '.py' file
-  has changed (because its modification time has changed) and ignores the
-  '.pyc' file.  When parsing is successful, a new '.pyc' file is written;
-  if this fails (no write permission, disk full or whatever) it is
-  silently skipped but attempted again the next time the same module
-  is loaded.  (Thus, if you plan to place a Python library on a read-only
-  disk, it is advisable to "warm the cache" by making the disk writable
-  and importing all modules once.  The standard module 'importall' helps
-  in doing this.)