traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

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

This commit is contained in:
Jack Jansen 1996-03-18 13:47:22 +00:00
parent 065796072c
commit 0f7af3f795
2 changed files with 0 additions and 300 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

169
Mac/README
View File

@ -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>

131
Mac/USING
View File

@ -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.)