summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJack Jansen <jack.jansen@cwi.nl>2003-11-19 14:54:25 (GMT)
committerJack Jansen <jack.jansen@cwi.nl>2003-11-19 14:54:25 (GMT)
commitd338b6e31727d2ebd7393ec20fa44ab50653e290 (patch)
treeb033d21fd9097790e12c195e29b8db9c8582dd57
parent28ecf70db57828db2ca279643bf9aeca7662f35c (diff)
downloadcpython-d338b6e31727d2ebd7393ec20fa44ab50653e290.zip
cpython-d338b6e31727d2ebd7393ec20fa44ab50653e290.tar.gz
cpython-d338b6e31727d2ebd7393ec20fa44ab50653e290.tar.bz2
Removing the obvious OS9-only documentsĀ§
-rw-r--r--Mac/Demo/building.html424
-rw-r--r--Mac/Demo/cgi.html90
-rw-r--r--Mac/Demo/cgi/cgitest.cgi.py2
-rw-r--r--Mac/Demo/cgi/cgitest.cgi.rsrcbin8072 -> 0 bytes
-rw-r--r--Mac/Demo/cgi/realcgitest.py59
-rw-r--r--Mac/Demo/embed.html44
-rw-r--r--Mac/Demo/embed/demo.c71
-rw-r--r--Mac/Demo/embed/embeddemo.prjbin78479 -> 0 bytes
-rw-r--r--Mac/Demo/freezing.html151
-rw-r--r--Mac/Demo/interslip/InterslipLib.c97
-rw-r--r--Mac/Demo/interslip/InterslipLib.h20
-rw-r--r--Mac/Demo/interslip/interslipmodule.c225
-rw-r--r--Mac/Demo/mpwextensions.html484
-rw-r--r--Mac/Demo/plugins.html324
-rw-r--r--Mac/Demo/printing/PrintingDemo.py93
-rw-r--r--Mac/Demo/using.html429
16 files changed, 0 insertions, 2513 deletions
diff --git a/Mac/Demo/building.html b/Mac/Demo/building.html
deleted file mode 100644
index 06cf399..0000000
--- a/Mac/Demo/building.html
+++ /dev/null
@@ -1,424 +0,0 @@
-<HTML>
-<HEAD>
-<TITLE>Building MacPython-OS9 from source</TITLE>
-</HEAD>
-<BODY>
-<H1>Building MacPython-OS9 from source</H1>
-<HR>
-
-This document explains how to build MacPython-OS9 from source. This is
-necessary if you want to make modifications to the Python core. Building
-Python is not something to be undertaken lightly, you need a reasonable
-working knowledge of the CodeWarrior development environment, a good net
-connection and probably quite some time too. <p>
-
-Note that if you only want to build new extension modules you don't need to
-build Python from source, see the <a href="#extending">note on extending Python</a>.<p>
-
-The information density in this file is high, so you should probably
-print it and read it at your leasure. Most things are explained only
-once (and probably in the wrong place:-). <p>
-
-<blockquote>
-First a warning: this information may become outdated if a new CodeWarrior is
-released after MacPython. The
-<a href="http://www.cwi.nl/~jack/macpython.html">MacPython homepage</a> will
-hopefully have updated instructions in that case. These instructions are for CW7,
-it is rumoured you may encounter some problems with newer versions of CodeWarrior.
-</blockquote>
-
-I am interested in feedback on this document, send your
-comments to the <A
-HREF="http://www.python.org/sigs/pythonmac-sig/">Mac Python Special
-Interest Group</A>.
-
-<H2>What you need.</H2>
-
-The following things you definitely need:
-
-<UL>
-
-<LI> You need a MacPython source distribution, of course. You can
-obtain one via <A HREF="http://www.cwi.nl/~jack/macpython.html">
-http://www.cwi.nl/~jack/macpython.html</A> (which has up-to-date links
-to the other packages needed too) and possibly also from the standard
-<A HREF="ftp://ftp.python.org/pub/python/mac">python.org ftp
-site</A>. <BR>
-
-A better alternative is to check the sources straight out of the CVS
-repository, see below. Most of the packages mentioned here are also
-available through CVS. Check the section on <a href="#cvs">CVS
-repository use</a> below.
-
-<LI> You need MetroWerks CodeWarrior. The current distribution has
-been built with CodeWarrior Pro 7.1. Ordering information is
-available on the <A HREF="http://www.metrowerks.com/">MetroWerks
-homepage</A>. Building Python with MPW, Think/Symantec C or the OSX
-developer tools is impossible without major surgery.
-
-<LI> You need GUSI version 2, the Grand Unified Socket Interface, by
-Matthias Neeracher. The original GUSI is obtainable from <A
-HREF="ftp://gusi.sourceforge.net/pub/gusi/">
-ftp://gusi.sourceforge.net/pub/gusi/</A>. At
-the moment Python is built with a modified version of GUSI
-with Carbon adaptations, so it may be better to check the <A
-HREF="http://www.cwi.nl/~jack/macpython.html">MacPython homepage</A>
-for a GUSI that is most easily used for building Python.
-
-</UL>
-
-<A NAME="optional">The MacPython project files are configured to
-include a plethora of optional modules</A>, and these modules need a
-number of extra packages. To use the project files as-is you have to
-download these packages too. Python has all such modules as
-dynamically loaded modules, so if you don't need a certain package it
-suffices to just refrain from builing the extension module.
-Here are the locations for the various things
-you need:
-
-<UL>
-
-<LI> Waste, a TextEdit replacement written by Marco Piovanelli, <A
-HREF="mailto:piovanel@kagi.com">&lt;piovanel@kagi.com&gt;</A>. Python
-was built using version 2.0, which is included in the CodeWarrior
-package. You can also obtain it from <A
-HREF="http://www.merzwaren.com/waste">&lt;http://www.merzwaren.com/waste&gt;</A>
-and various other places.
-
-<LI> Gdbm library for the Mac. Available from Jack's Mac software page at
-<A HREF="http://www.cwi.nl/~jack/macsoftware.html">
-http://www.cwi.nl/~jack/macsoftware.html</A> and <A HREF="ftp://ftp.cwi.nl/pub/jack/mac">
-ftp://ftp.cwi.nl/pub/jack/mac</A>.
-
-<LI> JPEG library by the Independent JPEG Group. A version including
-Mac projects can be found at Jack's page mentioned above.
-The most recent JPEG library can always be obtained from <A
-HREF="ftp://ftp.uu.net/graphics/jpeg/">ftp://ftp.uu.net/graphics/jpeg/</A>.
-
-<LI> The netpbm/pbmplus, libtiff, zlib and png libraries. The netpbm distribution
-(which includes libtiff) is generally available on Internet ftp
-servers. For Python pbmplus, an older incarnation of netpbm, is
-functionally identical to netpbm, since Python only uses the library
-and not the complete applications. A distribution with correct
-projects and library source only is available from, you guessed it, Jack's Mac software
-page mentioned above.
-
-</UL>
-
-<H2>Setting Up</H2>
-
-Now that you have collected everything you should start with building
-the various parts. If you don't want to fix
-access paths try to set things up as follows:
-
-<PRE>
-Top-level-folder:
- GUSI2
- imglibs
- jpeg
- netpbm
- libtiff
- zlib
- png
- gdbm
- Python
- Modules
- ...
- Mac
- Modules
- Build
- ...
-</PRE>
-
-If your setup of the libraries is exactly the same as mine (which is
-not very likely, unless you happen to work from the same CVS
-repository) you can use the project <code>buildlibs.prj</code> in the
-<code>:Mac:Build</code> folder to build all needed libraries in one
-fell swoop, otherwise you will have to build the libraries one by
-one. <p>
-
-First build GUSI, the Carbon variant.
- <p>
-
-Next, in
-<code>libjpeg</code>, <code>pbmplus</code>,
-<code>zlib</code>, <code>libpng</code>, <code>gdbm</code>,
-and<code>libtiff</code> you build all projects. Usually the projects are in "mac"
-subfolders, sometimes they are in the main folder. Tcl/tk is a special
-case, see below.
-
-<H2>The organization of the Python source tree</H2>
-
-Time for a short break, while we have a look at the organization of
-the Python source tree. At the top level, we find the following
-folders:
-
-<DL>
-<DT> Demo
-<DD> Demo programs that are not Mac-specific. Some of these may not
-work.
-
-<DT> Extensions
-<DD> Extensions to the interpreter that are not Mac-specific. Contains
-the <code>img</code>, <code>Imaging</code> and <code>Numerical</code> extensions
-in this distribution.
-
-<DT> Grammar
-<DD> The Python grammar. Included for reference only, you cannot build
-the parser on a Mac.
-
-<DT> Include
-<DD> Machine-independent header files.
-
-<DT> Modules
-<DD> Machine-independent optional modules. Not all of these will work
-on the Mac.
-
-<DT> Lib
-<DD> Machine-independent modules in Python.
-
-<DT> Lib:lib-dynload
-<DD> This is where the dynamically-loaded plugin modules live.
-
-<DT> Lib:plat-mac
-<DD> This is where most of the Mac-specific modules live. The modules here
-are available both in MacPython-OS9 and MacPython-OSX.
-
-<DT> Objects
-<DD> Machine-independent code for various object types. Most of these are
-not really optional: the interpreter will not function without them.
-
-<DT> Parser
-<DD> The Python parser (machine-independent).
-
-<DT> Python
-<DD> The core interpreter. Most files are machine-independent, some
-are unix-specific and not used on the Mac.
-
-<DT> Tools
-<DD> Tools for python developers. Contains <code>modulator</code> which
-builds skeleton C extension modules, <code>bgen</code> which generates
-complete interface modules from information in C header files and
-<code>freeze</code> which is used to turn Python scripts into real
-applications (used by MacFreeze and BuildApplication) There are some
-readme files, but more documentation is sorely needed.
-
-</DL>
-
-The mac-specific stuff lives in the <code>Mac</code> folder:
-<DL>
-<DT> Build
-<DD> This is where the project files live and where you build the
-libraries, shared libraries, executables and plugin modules. All the
-resulting binaries, except for intermedeate results, are deposited in
-the toplevel folder or the :Lib:lib-dynload folder (for plugin modules).
-
-<DT> Compat
-<DD> Unix-compatability routines. Most of these are not used anymore,
-since GUSI provides a rather complete emulation, but you may need
-these if you are trying to build a non-GUSI python.
-
-<DT> Demo
-<DD> Mac-specific demo programs, some of them annotated.
-
-<DT> Include
-<DD> Mac-specific but compiler-independent include files.
-
-<DT> Lib
-<DD> MacPython-OS9 specific standard modules which are not shared with
-MacPython-OSX.
-
-<DT> Modules
-<DD> Mac-specific builtin modules. Theoretically these are all
-optional, but some are rather essential (like
-<code>macosmodule</code>). A lot of these modules are generated with
-<code>bgen</code>, in which case the bgen input files are included so
-you can attempt to regenerate them or extend them.
-
-<DT> MPW
-<DD> MPW-specific files. These have not been used or kept up-to-date
-for a long time, so use at your own risk.
-
-<DT> mwerks
-<DD> Mwerks-specific sources and headers. Contains glue code for
-Pythons shared-library architecture, a replacement for
-<code>malloc</code> and a directory with various projects for building
-variations on the Python interpreter. The <code>mwerks_*.h</code>
-files here are the option-setting files for the various interpreters
-and such, comparable to the unix command-line <code>-D</code> options
-to the compiler. Each project uses the correct option file as its
-"prefix file" in the "C/C++ language" settings. Disabling optional
-modules (for the 68K interpreter), building non-GUSI interpreters and
-various other things are accomplished by modifying these files (and
-possibly changing the list of files included in the project window, of
-course).
-
-<DT> OSX
-<DD> Specific to MacPython-OSX, not used by MacPython-OS9.
-
-<DT> OSXResources
-<DD> Specific to MacPython-OSX, not used by MacPython-OS9.
-
-<DT> Python
-<DD> Mac-specific parts of the core interpreter.
-
-<DT> Resources
-<DD> Resource files needed to build the interpreter.
-
-<DT> Scripts
-<DD> A collection of various mac-specific Python scripts. Some are
-essential, some are useful but few are documented, so you will have to
-use your imagination to work them out.
-
-<DT> Tools
-<DD> A collection of tools, usually bigger than those in the scripts
-folder. The important ones here are the IDE and macfreeze. The IDE is built
-with the buildIDE.py script, which puts the resulting applet in the toplevel
-folder. Macfreeze is usually invoked through the BuildApplication script,
-but for more control over the freezing process you can run the main script here.
-
-
-<DT> Unsupported
-<DD> Modules that are not supported any longer but may still work with a little effort.
-</DL>
-
-<H2>Building the PPC interpreter</H2>
-
-First you optionally build the external libraries with buildlibs.prj. <p>
-
-Then, the <code>fullbuild</code> script can be used to build
-everything, but you need a fully-functional interpreter before you can
-use it (and one that isn't rebuilt in the process: you cannot rebuild
-a running program). You could copy the interpreter to a different
-place and use that to run fullbuild. The <code>PythonStandSmall.prj</code>
-project builds an interpreter that is suited to this, and it can also come
-in handy if you need to debug things (which is easier in a static program). <p>
-
-In case you want to build by hand, or in case the <code>fullbuild</code>
-script does not work, here is a breakdown of the various projects. <p>
-
-The projects for interpreter and core library are linked together, so
-building the PythonInterpreter target
-in <code>PythonInterpreter.prj</code>
-will result in the whole core being built, but not the extension modules. <p>
-
-You will get about 100 warnings on "missing prototype" for the various module init
-routines, ignore these. You will also get numerous warnings on functions from GUSI which
-override functions from MSL, ignore these too. <p>
-
-Here is a breakdown of the projects:
-
-<DL>
-
-<DT> PythonCore
-<DD> The shared library that contains the bulk of the interpreter and
-its resources.
-It is a good idea to immedeately put an alias to this
-shared library in the <code>Extensions</code> folder of your system
-folder. Do exactly that: put an <em>alias</em> there, copying or
-moving the file will cause you grief later if you rebuild the library and
-forget to copy it to the extensions folder again. The ConfigurePythonXXX applets
-will also do this. <br>
-
-<DT> PythonInterpeter
-<DD> The interpreter. This is basically a routine to call out to the
-shared library. <p>
-
-<DT> Plugin projects
-<DD> Each plugin module has a separate project, and these can be rebuilt on
-the fly. Fullbuild (or actually it's little helper genpluginprojects) takes
-care of this.
-</DL>
-
-After creating the alias to <code>PythonCore</code> you remove any old
-<code>Python XXXX Preferences</code> file from the <code>Preferences</code> folder
-(if you had python installed on your system before) and run the interpreter once
-to create the correct preferences file. <p>
-
-Next, you have to build the extension modules.
-If you don't use fullbuild simply open each project and build it.
-<p>
-
-Finally, you must build the standard applets:
-<code>EditPythonPrefs</code>, <code>BuildApplet</code>, etc. For the N-th time:
-fullbuild does this for you, but you can also manually drag/drop them onto
-BuildApplet. <p>
-
-You are all set now, and should read the release notes and
-<code>ReadMe</code> file from the <code>Mac</code> folder.
-
-Rebuilding .exp files is no longer needed since CodeWarrior 7.
-
-<H2><a name="cvs">Using the CVS source archive</a></H2>
-
-It is possible (and probably best) to access the Python sources through remote CVS. The
-advantage of this is that you get the very latest sources, so any bug
-fixed or new features will be immedeately available. This is also the
-disadvantage, of course: as this is the same tree as is used for
-development it may sometimes be a little less stable. <p>
-
-The CVS client of choice is Alexandre Parenteau's MacCVS. It can be
-obtained through the <a href="http://www.wincvs.org">WinCVS
-homepage</a>. MacCVS uses Internet Config to set file types correctly
-based on the filename extension. In the maccvs preferences you should
-also set (in the "binary files" section) "use mac encoding:
-applesingle" and (in the "text files" section) "use ISO latin 1
-conversion". <p>
-
-It is a good idea to disable Quicktime Exchange in the Quicktime control
-panel if you are on OS9 or before. Quicktime Exchange will magically map
-some extensions to filetypes, and this can seriously hinder you if, for
-instance, <code>.bmp</code> is not a Windows bitmap file. <p>
-
-The Python sources are checked out from the main
-Python CVS archive on sourceforge.net, see the <a
-href="http://www.python.org/download/cvs.html">Source access via
-CVS</a> page for details. When you check the sources out you will get
-something like <code>Python:dist:src</code>, and under that the
-<code>Modules</code>, <code>Lib</code>, <code>Mac</code> etc hierarchy. The
-<code>src</code> folder can be renamed to <code>Python</code>, and
-is what this document refers to as the "toplevel Python folder". <P>
-
-The CVS repository does not contain all the projects for the plugin modules,
-these are built with <code>fullbuild.py</code> normally. For this reason
-it is probably a good idea to first build <code>PythonStandSmall.prj</code>,
-which builds a fairly minimal interpreter, and then follow the
-fullbuild instructions</a>.
-
-<H2>Odds and ends</H2>
-
-Some remarks that I could not fit in elsewhere:
-
-<UL>
-
-<LI> It may be possible to use the <code>PythonCore</code> shared
-library to embed Python in another program, if your program can live
-with using GUSI for I/O. Use PythonCore in stead of your MSL C library
-(or, at the very least, link it before the normal C library). Ask for help
-on PythonMac-SIG if you have problems with this.
-
-<LI> <a name="extending"></a>It is possible to build PPC extension
-modules without building a complete Python. The binary distribution
-installer can optionally install all the needed folders (the develop
-option). A template for a dynamic module can be found in
-<code>xx.prj</code>.
-
-<LI> The Python shared library architecture is a variant of the architecture
-described as "application with shared libraries and dropins" in the MetroWerks
-"Targeting MacOS" documentation. The Python Application and applet-template use
-the <code>MSL AppRuntime.Lib</code> runtime library (with properly set CFM
-initialization and termination routines). PythonCore uses <code>MSL Runtime.Lib</code>,
-which is really intended for standalone programs but which we fool into working by
-providing a dummy main program.
-It is linked statically into PythonCore (and exported to the applications and plugins)
-so we do not have to distribute yet another shared library. Plugin modules use
-<code>MSL ShlibRuntime.Lib</code> (not the dropin runtime: modules are never unloaded)
-and obtain the rest from PythonCore. PythonCore uses a
-non-standard initialization entry point, <code>__initialize_with_resources</code>, to
-be able to obtain resources from the library file later on. Plugins can do the same
-(_tkinter does) or use the standard <code>__initialize</code> entry point.
-
-
-</UL>
-</BODY>
-</HTML>
diff --git a/Mac/Demo/cgi.html b/Mac/Demo/cgi.html
deleted file mode 100644
index 01ea85e..0000000
--- a/Mac/Demo/cgi.html
+++ /dev/null
@@ -1,90 +0,0 @@
-<HTML><HEAD><TITLE>Using python to create CGI scripts</TITLE></HEAD>
-<BODY>
-<H1>Using python to create CGI scripts</H1>
-<HR>
-
-In this document we will (eventually) explain how to create Python CGI scripts
-for use with Personal WebServer, WebStar and probably other Mac-based HTTP servers too.
-Since CGI scripts are AppleEvent servers on the mac we will also learn
-a little about general AppleEvent server programming and about applet
-debugging. <p>
-
-<blockquote>Note that the current setup is very preliminary, and hence
-itis probably not wise to base your strategic products on the information
-in this document:-) In stead, play with the code here and join the
-<a href="mailto:pythonmac-sig-request@python.org">pythonmac-sig</a>, where
-we I would like to have a discussion on a real design for a Mac CGI framework
-(preferrably something that will make CGI scripts portable to unix and other
-platforms).
-</blockquote>
-
-<h2>AppleEvent servers</h2>
-
-Since AppleEvent clients are easier to write and understand than servers
-you should probably read the section on <a href="applescript.html">Open Scripting
-clients in Python</a> first. <p>
-
-Next, let us have a look at the AE Server framework,
-<a href="../Lib/toolbox/MiniAEFrame.py">MiniAEFrame.py</a>.
-This file contains two classes, <code>MiniApplication</code> and <code>AEServer</code>.
-MiniApplication is a tiny replacement for <code>FrameWork.Application</code>,
-suitable if your application does not need windows and such.
-
-AEServer is a bit of glue that does part of the appleevent decoding for you. You
-call <code>installaehandler</code> passing it the class and id (4-char strings)
-of the event you have a handler for and the handler callback routine. When the
-appleevent occurs your callback is called with the right arguments. For now,
-your argument names are the 4-char values used internally by Open Scripting,
-eventually there will be a translation similar to what the generated OSA client
-suites provide. <p>
-
-You can test AEServer by double-clicking it. It will react to the standard
-run/open/print/quit OSA commands. If it is running as a normal python script and you
-drag a file onto the interpreter the script will tell you what event it got. <p>
-
-<h2>A Minimal CGI script</h2>
-
-To try a CGI script you will first need a http server. Apple's Personal Webserver
-is fine, but I have also used the
-shareware
-<a href="http://www.stairways.com/netpresenz/">NetPresenz</a>
-by Peter Lewis
-(don't forget to pay if you give it more than a test run!). Install your
-http server, and make sure that it can serve textual documents. <p>
-
-Next, let us have a look at our example CGI scripts. CGI scripts have to be
-applications, so we will have to make an applet as explained in
-<a href="example2.html">example 2</a>. Our applet code,
-<a href="cgi/cgitest.cgi.py">cgitest.cgi.py</a> is a rather minimal <code>execfile</code>
-statement. The reason for this is debugging: the real code is in
-<a href="cgi/realcgitest.py">realcgitest.py</a>, and this way you do not have
-to run mkapplet again every time you change the code. Rename realcgitest.py
-to cgitest.cgi.py once you are satisfied that it works. <p>
-
-The resource file is not very special, with one exception: since we want to do
-our own appleevent handling we don't want the Python initialization code to
-create argc and argv for use, since this might gobble up any appleevents we are
-interested in. For this reason we have included a 'Popt' resource that disables
-the argv initialization. An easy way to create this resource is to drop
-the <code>.rsrc</code> file (or the finished applet, if you like) onto
-<code>EditPythonPrefs</code> and set the "no argv processing" option. <p>
-
-The code itself is actually not too complicated either. We install handlers
-for "open application" and "quit" (stolen from the test code in MiniAEFrame)
-and the <code>"WWW\275"/"sdoc"</code> event, the event sent on CGI execution.
-The cgi handler pretty-prints the CGI arguments in HTML and returns the whole
-string that is to be passed to the client. The actual parameters passed
-are explained in <a href="http://www.biap.com/datapig/mrwheat/cgi_params.html">
-http://www.biap.com/datapig/mrwheat/cgi_params.html</a>. <p>
-
-To test the script drop <code>cgitest.cgi.py</code> onto <code>mkapplet</code>,
-move the resulting <code>cgitest.cgi</code> to somewhere where it is reachable
-by NetPresenz, and point your web browser towards it. Note that this assume you have
-already renamed realcgitest.py to cgitest.cgi.py, otherwise you'll also have
-to copy that file along. <p>
-
-For Apple's Personal Webserver you need to do a bit more: you have to copy the
-cgi applet to somewhere in your "Webpages" folder and you have to tell the webserver
-(in the control panels) that your CGI script exists. I don't understand what the various
-types of cgi scripts mean, but experiment with them.
-</BODY></HTML>
diff --git a/Mac/Demo/cgi/cgitest.cgi.py b/Mac/Demo/cgi/cgitest.cgi.py
deleted file mode 100644
index ce59710..0000000
--- a/Mac/Demo/cgi/cgitest.cgi.py
+++ /dev/null
@@ -1,2 +0,0 @@
-# Debug applets quickly.
-execfile('realcgitest.py')
diff --git a/Mac/Demo/cgi/cgitest.cgi.rsrc b/Mac/Demo/cgi/cgitest.cgi.rsrc
deleted file mode 100644
index c8aa9f4..0000000
--- a/Mac/Demo/cgi/cgitest.cgi.rsrc
+++ /dev/null
Binary files differ
diff --git a/Mac/Demo/cgi/realcgitest.py b/Mac/Demo/cgi/realcgitest.py
deleted file mode 100644
index e51cb97..0000000
--- a/Mac/Demo/cgi/realcgitest.py
+++ /dev/null
@@ -1,59 +0,0 @@
-"""cgitest - A minimal CGI applet. Echos parameters back to the client.
-"""
-
-from MiniAEFrame import AEServer, MiniApplication
-import MacOS
-
-debug=1
-
-class CGITest(AEServer, MiniApplication):
-
- def __init__(self):
- MiniApplication.__init__(self)
- AEServer.__init__(self)
- self.installaehandler('aevt', 'oapp', self.open_app)
- self.installaehandler('aevt', 'quit', self.quit)
- self.installaehandler('WWW\275', 'sdoc', self.cgihandler)
- if debug:
- self.installaehandler('****', '****', self.otherhandler)
- oldparams = MacOS.SchedParams(0, 0)
- self.mainloop()
- apply(MacOS.SchedParams, oldparams)
-
- def quit(self, **args):
- self.quitting = 1
-
- def open_app(self, **args):
- pass
-
- def otherhandler(self, *args, **kwargs):
- print 'Unknown AppleEvent'
- print 'args', args
- print 'kwargs', kwargs
-
- def cgihandler(self, pathargs, **args):
- if debug:
- print 'CGI request', pathargs, args
- rv = """HTTP/1.0 200 OK
-Server: Unknown; python-cgi-script
-MIME-Version: 1.0
-Content-type: text/html
-
-<title>Python CGI-script results</title>
-<h1>Python CGI-script results</h1>
-<hr>
-"""
- rv = rv+'<br><b>Direct object:</b> %s\n'%pathargs
-
- for key in args.keys():
- if key[0] != '_':
- rv = rv + '<br><b>%s:</b> %s\n'%(key, args[key])
- rv = rv +'<hr>\nSee you next time!\n'
-
- # Note: if you want to quit after each request enable the line
- # self.quitting = 1
-
- return rv
-
-if __name__ == '__main__':
- CGITest()
diff --git a/Mac/Demo/embed.html b/Mac/Demo/embed.html
deleted file mode 100644
index e0ca756..0000000
--- a/Mac/Demo/embed.html
+++ /dev/null
@@ -1,44 +0,0 @@
-<HTML>
-<HEAD>
-<TITLE>Embedding Python on the Mac</TITLE>
-</HEAD>
-<BODY>
-<H1>Embedding Python on the Mac</H1>
-<HR>
-<B>Note</B>: if you have a binary-only release of MacPython you will not
-have this demo installed. Install the developer option (in the standard installer) or
-a source release if you want to embed
-Python in other applications. <p>
-
-Embedding Python on the mac is pretty similar to embedding it on other
-platforms, but a few points need mentioning:
-
-<UL>
-<LI> You call <CODE>PyMac_Initialize()</CODE> in stead of
-<CODE>Py_Initialize()</CODE>. The prototype is in <CODE>macglue.h</CODE>.
-This call initializes the toolbox, GUSI (if needed), sets up the correct
-resource files and calls Py_Initialize.
-
-<LI> You have to be consequent in your use of GUSI. If the library uses
-it so should your program and vice versa.
-
-<LI> The console-behaviour (close-on-exit, etc) is controlled by Python
-but you can overwrite this with <code>PyMac_SetConsoleHandler()</code>.
-</UL>
-
-The Python environment is started with a dummy argc and argv, and initial
-startup options are obtained through the usual means, except that the
-user pression the option-key will not result in an interactive dialog.
-You can, however, set startup options on your program in the same way as you
-do for applets, by dragging your application to <code>EditPythonPrefs</code>. <p>
-
-The most logical way to embed Python is to link it against the shared
-library <code>PythonCore</code>. An example project and source can be
-found in the <a href="embed">embed</a> folder. <p>
-
-This example code also shows how to override the console: if you pass the
-<code>-q</code> argument in the argument box output is thrown away. If you
-pass the <code>-d</code> option the output is sent to <code>DebugStr</code>
-(so be sure to use this only when running the example under a debugger).
-</BODY>
-</HTML>
diff --git a/Mac/Demo/embed/demo.c b/Mac/Demo/embed/demo.c
deleted file mode 100644
index a022f94..0000000
--- a/Mac/Demo/embed/demo.c
+++ /dev/null
@@ -1,71 +0,0 @@
-/* Example of embedding Python in another program */
-
-#include "Python.h"
-#include "macglue.h"
-
-static char *argv0;
-
-long my_writehandler(char *buf, long count)
-{
- long mycount;
- unsigned char mybuf[255];
-
- mycount = count;
- if (mycount > 255 ) mycount = 255;
- mybuf[0] = (unsigned char)mycount;
- strncpy((char *)mybuf+1, buf, mycount);
- DebugStr(mybuf);
- return count;
-}
-
-main(argc, argv)
- int argc;
- char **argv;
-{
- /* So the user can set argc/argv to something interesting */
- argc = ccommand(&argv);
- /* Save a copy of argv0 */
- argv0 = argv[0];
-
- /* If the first option is "-q" we don't open a console */
- if ( argc > 1 && strcmp(argv[1], "-q") == 0 ) {
- PyMac_SetConsoleHandler(PyMac_DummyReadHandler, PyMac_DummyWriteHandler,
- PyMac_DummyWriteHandler);
- } else
- if ( argc > 1 && strcmp(argv[1], "-d") == 0 ) {
- PyMac_SetConsoleHandler(PyMac_DummyReadHandler, my_writehandler,
- my_writehandler);
- }
- /* Initialize the Python interpreter. Required. */
- PyMac_Initialize();
-
- /* Define sys.argv. It is up to the application if you
- want this; you can also let it undefined (since the Python
- code is generally not a main program it has no business
- touching sys.argv...) */
- PySys_SetArgv(argc, argv);
-
- /* Do some application specific code */
- printf("Hello, brave new world\n\n");
-
- /* Execute some Python statements (in module __main__) */
- PyRun_SimpleString("import sys\n");
- PyRun_SimpleString("print sys.builtin_module_names\n");
- PyRun_SimpleString("print sys.argv\n");
-
- /* Note that you can call any public function of the Python
- interpreter here, e.g. call_object(). */
-
- /* Some more application specific code */
- printf("\nGoodbye, cruel world\n");
- /* Exit, cleaning up the interpreter */
- Py_Exit(0);
- /*NOTREACHED*/
-}
-
-/* This function is called by the interpreter to get its own name */
-char *
-getprogramname()
-{
- return argv0;
-}
diff --git a/Mac/Demo/embed/embeddemo.prj b/Mac/Demo/embed/embeddemo.prj
deleted file mode 100644
index 778755a..0000000
--- a/Mac/Demo/embed/embeddemo.prj
+++ /dev/null
Binary files differ
diff --git a/Mac/Demo/freezing.html b/Mac/Demo/freezing.html
deleted file mode 100644
index 1580bce..0000000
--- a/Mac/Demo/freezing.html
+++ /dev/null
@@ -1,151 +0,0 @@
-<HTML>
-<HEAD>
-<TITLE>Creating standalone applications with Python</TITLE>
-</HEAD>
-<BODY>
-<H1>Creating standalone applications with Python</H1>
-
-With <a href="example2.html#applet">BuildApplet</a> you can build a standalone
-Python application that works like
-any other Mac application: you can double-click it, run it while the
-Python interpreter is running other scripts, drop files on it, etc. It is, however,
-still dependent on the whole Python installation on your machine: the PythonCore
-engine, the plugin modules and the various Lib folders.<p>
-
-In some cases you may want to create a true application, for instance because
-you want to send it off to people who may not have Python installed on their
-machine, or because you the application is important and you do not want changes
-in your Python installation like new versions to influence it.
-
-<H2>The easy way</H2>
-
-The easiest way to create an application from a Python script is simply by dropping
-it on the <code>BuildApplication</code> applet in the main Python folder.
-BuildApplication has a similar interface as BuildApplet: you drop a script on
-it and it will process it, along with an optional <code>.rsrc</code> file.
-<P>
-
-What BuildApplication does, however, is very different. It parses your script,
-recursively looking for all modules you use, bundles the compiled code for
-all these modules in PYC resources, adds the executable machine code for the
-PythonCore engine, any dynamically loaded modules you use and a main program, combines
-all this into a single file and adds a few preference resources (which you
-can inspect with <code>EditPythonPrefs</code>, incidentally) to isolate the
-new program from the existing Python installation.<P>
-
-Usually you do not need to worry about all this, but occasionally you may have
-to exercise some control over the process, for instance because your
-program imports modules that don't exist (which can happen if your script
-is multi-platform and those modules will never be used on the Mac). See
-the section on <a href="#directives">directives</a> below for details.
-If you get strange error messages about missing modules it may also be worthwhile
-to run macfreeze in report mode on your program, see below.
-<P>
-
-<H2>Doing it the hard way</H2>
-
-With the <EM>macfreeze</EM> script, for which BuildApplication is a simple
-wrapper, you can go a step further and create CodeWarrior projects and
-sourcefiles which can then be used to build your final application. While
-BuildApplication is good enough for 90% of the use cases there are situations
-where you need macfreeze itself, mainly if you want to embed your frozen Python
-script into an existing C application, or when you need the extra bit of speed:
-the resulting application will start up a bit quicker than one generated
-with BuildApplication. <p>
-
-When you start
-<code>Mac:Tools:macfreeze:macfreeze.py</code> you are asked for the
-script file, and you can select which type of freeze to do. The first
-time you should always choose <em>report only</em>, which will produce a
-listing of modules and where they are included from in the console
-window. Macfreeze actually parses all modules, so it may crash in the
-process. If it does try again with a higher debug value, this should
-show you where it crashes. <p>
-
-<h2><a name="directives">Directives</a></h2>
-
-For more elaborate programs you will often see that freeze includes
-modules you don't need (because they are for a different platform, for
-instance) or that it cannot find all your modules (because you modify
-<code>sys.path</code> early in your initialization). It is possible to
-include directives to tell macfreeze to add items to the search path and
-include or exclude certain modules. All your directives should be in the
-main script file. <p>
-
-Directives have the following form:
-<pre>
-# macfreeze: command argument
-</pre>
-The trigger <code>macfreeze:</code> must be spelled exactly like that,
-but the whitespace can be any combination of spaces and tabs. Macfreeze
-understands the following directives:
-
-<DL>
-<DT> <code>path</code>
-<DD> Prepend a folder to <code>sys.path</code>. The argument is a
-pathname, which should probably be relative (starting with a colon) and
-is interpreted relative to the folder where the script lives.
-
-<DT> <code>include</code>
-<DD> Include a module. The module can either be given by filename or by
-module name, in which case it is looked up through the normal method.
-
-<DT> <code>exclude</code>
-<DD> Exclude a module. The module must be given by modulename. Even when
-freeze deems the module necessary it will not be included in the
-application.
-
-<DT> <code>optional</code>
-<DD> Include a module if it can be found, but don't complain if it can't.
-
-</DL>
-
-There is actually a fourth way that macfreeze can operate: it can be used
-to generate only the resource file containing the compiled <code>PYC</code>
-resources. This may be useful if you have embedded Python in your own
-application. The resource file generated is the same as for the CodeWarrior
-generation process. <p>
-
-<h2>Freezing with CodeWarrior</h2>
-
-To freeze with CodeWarrior you need CodeWarrior, obviously, and a full
-source distribution of Python. You select the <em>Codewarrior source and
-project</em> option. You specify an output folder, which is by default
-the name of your script with <code>.py</code> removed and
-<code>build.</code> prepended. If the output folder does not exist yet
-it is created, and a template project file and bundle resource file are
-deposited there. Next, a source file <code>macfreezeconfig.c</code> is
-created which includes all builtin modules your script uses, and a
-resource file <code>frozenmodules.rsrc</code> which contains the
-<code>PYC</code> resources for all your Python modules. <p>
-
-The project expects to live in a folder one level below the Python root
-folder, so the next thing you should do is move the build folder there.
-It is a good idea to leave an alias with the same name in the original
-location: when you run freeze again it will regenerate the
-<code>frozenmodules.rsrc</code> file but not the project and bundle
-files. This is probably what you want: if you modify your python sources
-you have to re-freeze, but you may have changed the project and bundle
-files, so you don't want to regenerate them. <p>
-
-An alternative is to leave the build folder where it is, but then you
-have to adapt the search path in the project. <p>
-
-The project is set up to include all the standard builtin modules, but
-the CW linker is smart enough to exclude any object code that isn't
-referenced. Still, it may be worthwhile to remove any sources for
-modules that you are sure are not used to cut back on compilation time.
-You may also want to examine the various resource files (for Tcl/Tk, for
-instance): the loader has no way to know that these aren't used. <p>
-
-You may also need to add sourcefiles if your script uses non-standard
-builtin modules, like anything from the <code>Extensions</code> folder. <p>
-
-The <code>frozenbundle.rsrc</code> resource file contains the bundle
-information. It is almost identical to the bundle file used for applets,
-with the exception that it sets the <code>sys.path</code> initialization
-to <code>$(APPLICATION)</code> only. This means that all modules will only
-be looked for in PYC resources in your application. <p>
-
-</BODY>
-</HTML>
diff --git a/Mac/Demo/interslip/InterslipLib.c b/Mac/Demo/interslip/InterslipLib.c
deleted file mode 100644
index 32c9717..0000000
--- a/Mac/Demo/interslip/InterslipLib.c
+++ /dev/null
@@ -1,97 +0,0 @@
-/*
-** InterslipLib - Routines to talk to InterSLIP. Version 1.1, 31-Oct-1995.
-**
-**
-** (c) Jack Jansen, CWI, 1995 <jack@cwi.nl>
-*/
-
-#include <Devices.h>
-
-#include "InterslipLib.h"
-
-static CntrlParam iopb;
-static short refnum = -1;
-
-OSErr is_open()
-{
- if ( refnum >= 0 ) return 0;
- return OpenDriver("\p.InterSLIP", &refnum);
-}
-
-OSErr is_connect()
-{
- iopb.ioCRefNum = refnum;
- iopb.ioVRefNum = refnum;
- iopb.ioCompletion = (UniversalProcPtr) 0;
- iopb.csCode = 2;
- return PBControlImmed((ParmBlkPtr)&iopb);
-}
-
-OSErr is_disconnect()
-{
- iopb.ioCRefNum = refnum;
- iopb.ioVRefNum = refnum;
- iopb.ioCompletion = (UniversalProcPtr) 0;
- iopb.csCode = 3;
- return PBControlImmed((ParmBlkPtr)&iopb);
-}
-
-OSErr is_status(long *status, long *msgseqnum, StringPtr *msg)
-{
- long *csp;
- OSErr err;
-
- iopb.ioCRefNum = refnum;
- iopb.ioVRefNum = refnum;
- iopb.ioCompletion = (UniversalProcPtr) 0;
- iopb.csCode = 4;
- if( err = PBControlImmed((ParmBlkPtr)&iopb) )
- return err;
- csp = (long *)&iopb.csParam;
- *status = csp[0];
- *msgseqnum = csp[1];
- *msg = (unsigned char *)csp[2];
- return 0;
-}
-
-OSErr is_getconfig(long *baudrate, long *flags,
- Str255 idrvnam, Str255 odrvnam, Str255 cfgnam)
-{
- long *csp;
- OSErr err;
-
- iopb.ioCRefNum = refnum;
- iopb.ioVRefNum = refnum;
- iopb.ioCompletion = (UniversalProcPtr) 0;
- iopb.csCode = 6;
- csp = (long *)&iopb.csParam;
- csp[2] = (long)idrvnam;
- csp[3] = (long)odrvnam;
- csp[4] = (long)cfgnam;
- if( err = PBControlImmed((ParmBlkPtr)&iopb) )
- return err;
- *baudrate = csp[0];
- *flags = csp[1];
- return 0;
-}
-
-OSErr is_setconfig(long baudrate, long flags,
- Str255 idrvnam, Str255 odrvnam, Str255 cfgnam)
-{
- long *csp;
- OSErr err;
-
- iopb.ioCRefNum = refnum;
- iopb.ioVRefNum = refnum;
- iopb.ioCompletion = (UniversalProcPtr) 0;
- iopb.csCode = 7;
- csp = (long *)&iopb.csParam;
- csp[0] = baudrate;
- csp[1] = flags;
- csp[2] = (long)idrvnam;
- csp[3] = (long)odrvnam;
- csp[4] = (long)cfgnam;
- return PBControlImmed((ParmBlkPtr)&iopb);
-}
-
-
diff --git a/Mac/Demo/interslip/InterslipLib.h b/Mac/Demo/interslip/InterslipLib.h
deleted file mode 100644
index 1ca2276..0000000
--- a/Mac/Demo/interslip/InterslipLib.h
+++ /dev/null
@@ -1,20 +0,0 @@
-/*
-** InterSLIP API.
-*/
-
-#include <Types.h>
-
-/* States */
-#define IS_IDLE 0
-#define IS_WMODEM 1
-#define IS_DIAL 2
-#define IS_LOGIN 3
-#define IS_RUN 4
-#define IS_DISC 5
-
-OSErr is_open(); /* Open InterSLIP driver (optional) */
-OSErr is_connect();/* Connect */
-OSErr is_disconnect(); /* Disconnect */
-OSErr is_status(long *, long *, StringPtr *); /* Get status, msg seq#, msg pointer */
-OSErr is_getconfig(long *, long *, Str255 , Str255 , Str255 ); /* get config */
-OSErr is_setconfig(long , long , Str255 , Str255 , Str255 ); /* set config */
diff --git a/Mac/Demo/interslip/interslipmodule.c b/Mac/Demo/interslip/interslipmodule.c
deleted file mode 100644
index dc2c7a8..0000000
--- a/Mac/Demo/interslip/interslipmodule.c
+++ /dev/null
@@ -1,225 +0,0 @@
-/***********************************************************
-Copyright 1991-1995 by Stichting Mathematisch Centrum, Amsterdam,
-The Netherlands.
-
- All Rights Reserved
-
-Permission to use, copy, modify, and distribute this software and its
-documentation for any purpose and without fee is hereby granted,
-provided that the above copyright notice appear in all copies and that
-both that copyright notice and this permission notice appear in
-supporting documentation, and that the names of Stichting Mathematisch
-Centrum or CWI not be used in advertising or publicity pertaining to
-distribution of the software without specific, written prior permission.
-
-STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO
-THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
-FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE
-FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
-WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
-ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
-OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-
-******************************************************************/
-
-#include "Python.h"
-#include "InterslipLib.h"
-#include "macglue.h"
-
-static PyObject *ErrorObject;
-
-/* ----------------------------------------------------- */
-
-static char pyis_open__doc__[] =
-"Load the interslip driver (optional)"
-;
-
-static PyObject *
-pyis_open(self, args)
- PyObject *self; /* Not used */
- PyObject *args;
-{
- OSErr err;
-
- if (!PyArg_ParseTuple(args, ""))
- return NULL;
- err = is_open();
- if ( err ) {
- PyErr_Mac(ErrorObject, err);
- return NULL;
- }
- Py_INCREF(Py_None);
- return Py_None;
-}
-
-static char pyis_connect__doc__[] =
-"Tell the driver to start a connect"
-;
-
-static PyObject *
-pyis_connect(self, args)
- PyObject *self; /* Not used */
- PyObject *args;
-{
- OSErr err;
-
- if (!PyArg_ParseTuple(args, ""))
- return NULL;
- err = is_connect();
- if ( err ) {
- PyErr_Mac(ErrorObject, err);
- return NULL;
- }
- Py_INCREF(Py_None);
- return Py_None;
-}
-
-static char pyis_disconnect__doc__[] =
-"Tell the interslip driver to start a disconnect"
-;
-
-static PyObject *
-pyis_disconnect(self, args)
- PyObject *self; /* Not used */
- PyObject *args;
-{
- OSErr err;
-
- if (!PyArg_ParseTuple(args, ""))
- return NULL;
- err = is_disconnect();
- if ( err ) {
- PyErr_Mac(ErrorObject, err);
- return NULL;
- }
- Py_INCREF(Py_None);
- return Py_None;
-}
-
-static char pyis_status__doc__[] =
-"Return (numeric_status, message_seqnum, message_string) status tuple"
-;
-
-static PyObject *
-pyis_status(self, args)
- PyObject *self; /* Not used */
- PyObject *args;
-{
- long status, seqnum;
- StringPtr message;
- OSErr err;
-
- if (!PyArg_ParseTuple(args, ""))
- return NULL;
- err = is_status(&status, &seqnum, &message);
- if ( err ) {
- PyErr_Mac(ErrorObject, err);
- return NULL;
- }
- return Py_BuildValue("iiO&", (int)status, (int)seqnum, PyMac_BuildStr255, message);
-}
-
-static char pyis_getconfig__doc__[] =
-"Return configuration data (ibaud, obaud, flags, idrvname, odrvname, cfgname)"
-;
-
-static PyObject *
-pyis_getconfig(self, args)
- PyObject *self; /* Not used */
- PyObject *args;
-{
- long baudrate, flags;
- Str255 idrvname, odrvname, cfgname;
- OSErr err;
- int ibaud, obaud;
-
- if (!PyArg_ParseTuple(args, ""))
- return NULL;
- err = is_getconfig(&baudrate, &flags, idrvname, odrvname, cfgname);
- if ( err ) {
- PyErr_Mac(ErrorObject, err);
- return NULL;
- }
- ibaud = (baudrate >> 16) & 0xffff;
- obaud = baudrate & 0xffff;
- return Py_BuildValue("iiiO&O&O&", ibaud, obaud, (int)flags, PyMac_BuildStr255, idrvname,
- PyMac_BuildStr255, odrvname, PyMac_BuildStr255, cfgname);
-}
-
-static char pyis_setconfig__doc__[] =
-"Set configuration data (ibaud, obaud, flags, idrvname, odrvname, cfgname)"
-;
-
-static PyObject *
-pyis_setconfig(self, args)
- PyObject *self; /* Not used */
- PyObject *args;
-{
- long baudrate;
- int flags;
- Str255 idrvname, odrvname, cfgname;
- OSErr err;
- int ibaud, obaud;
-
- if (!PyArg_ParseTuple(args, "iiiO&O&O&", &ibaud, &obaud, &flags, PyMac_GetStr255, idrvname,
- PyMac_GetStr255, odrvname, PyMac_GetStr255, cfgname))
- return NULL;
- baudrate = (ibaud << 16) | obaud;
- err = is_setconfig(baudrate, (long)flags, idrvname, odrvname, cfgname);
- if ( err ) {
- PyErr_Mac(ErrorObject, err);
- return NULL;
- }
- Py_INCREF(Py_None);
- return Py_None;
-}
-
-/* List of methods defined in the module */
-
-static struct PyMethodDef pyis_methods[] = {
- {"open", pyis_open, 1, pyis_open__doc__},
- {"connect", pyis_connect, 1, pyis_connect__doc__},
- {"disconnect", pyis_disconnect, 1, pyis_disconnect__doc__},
- {"status", pyis_status, 1, pyis_status__doc__},
- {"getconfig", pyis_getconfig, 1, pyis_getconfig__doc__},
- {"setconfig", pyis_setconfig, 1, pyis_setconfig__doc__},
-
- {NULL, NULL} /* sentinel */
-};
-
-
-/* Initialization function for the module (*must* be called initinterslip) */
-
-static char interslip_module_documentation[] =
-""
-;
-
-void
-initinterslip()
-{
- PyObject *m, *d;
-
- /* Create the module and add the functions */
- m = Py_InitModule4("interslip", pyis_methods,
- interslip_module_documentation,
- (PyObject*)NULL,PYTHON_API_VERSION);
-
- /* Add some symbolic constants to the module */
- d = PyModule_GetDict(m);
- ErrorObject = PyString_FromString("interslip.error");
- PyDict_SetItemString(d, "error", ErrorObject);
-
- /* XXXX Add constants here */
-
- PyDict_SetItemString(d, "IDLE", PyInt_FromLong(IS_IDLE));
- PyDict_SetItemString(d, "WMODEM", PyInt_FromLong(IS_WMODEM));
- PyDict_SetItemString(d, "DIAL", PyInt_FromLong(IS_DIAL));
- PyDict_SetItemString(d, "LOGIN", PyInt_FromLong(IS_LOGIN));
- PyDict_SetItemString(d, "RUN", PyInt_FromLong(IS_RUN));
- PyDict_SetItemString(d, "DISC", PyInt_FromLong(IS_DISC));
-
- /* Check for errors */
- if (PyErr_Occurred())
- Py_FatalError("can't initialize module interslip");
-}
-
diff --git a/Mac/Demo/mpwextensions.html b/Mac/Demo/mpwextensions.html
deleted file mode 100644
index 742cbc2..0000000
--- a/Mac/Demo/mpwextensions.html
+++ /dev/null
@@ -1,484 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
-<HTML>
-
-<HEAD>
-
-<TITLE>HOWTO: Compiling Python Modules with MPW</TITLE>
-
-</HEAD>
-
-<BODY>
-
-<H1>HOWTO: Compiling Python Modules with MPW</H1>
-
-<blockquote>
-This HOWTO is a slightly reformatted version of an original by
-<A HREF="mailto:cwebster@nevada.edu">Corran Webster</A>, whose
-<A HREF="http://www.nevada.edu/~cwebster/Python/">Python page</A>
-may contain a more up-to-date version.
-</blockquote>
-<HR>
-
-<P>
-The <A HREF="http://www.cwi.nl/~jack/macpython.html">Macintosh version</A>
-of the <A HREF="http://www.python.org/">Python programming language</A> is
-usually compiled with <A HREF="http://www.metrowerks.com/">Metrowerks
-CodeWarrior</A>. As a result, C extension modules are also usually
-compiled with CodeWarrior, and the documentation and sample code reflects
-this. CodeWarrior is a commercial product, and may be beyond the budgets
-of hobbyist hackers, making them dependent on others to compile C extension
-modules. At the present time, many standard C extension modules compile
-"out of the box" on the Macintosh, but in only a few cases is the plugin
-for the Macintosh included in the distribution.
-</P>
-
-<P>
-The <A HREF="http://developer.apple.com/tools/mpw-tools/">Macintosh
-Programmer's Workshop</A> (MPW) is Apple's development environment, and is
-freely available for <A
-HREF="ftp://ftp.apple.com/developer/Tool_Chest/Core_Mac_OS_Tools/MPW_etc./">download</A>
-from Apple, as well as on their Developer CDs. Since Python was originally
-developed using MPW, before CodeWarrior became the dominant MacOS
-development environment, most of the idiosyncrasies of MPW are already
-supported, and compilation of C extension modules in MPW is possible.
-</P>
-
-<P>
-This HOWTO only deals with compiling for PowerPC Macintoshes. The process
-should be similar for 68k Macintoshes using the code fragment manager, but
-I have not attempted this - my old Mac is running NetBSD.
-</P>
-
-<P>
-This way of compiling modules is still experimental. Please read the
-caveats section below.
-</P>
-
-<H2><A NAME="setup">Setting Up MPW for Compiling Python Modules</A></H2>
-
-<P>
-This assumes that you have successfully installed both MPW and Python with
-the Developer's Kit on your Macintosh.
-</P>
-
-<P>
-The first step is to let MPW know where you keep Python. This step is not
-strictly necessary, but will make development easier and improve
-portability. Create a new file in the <CODE>Startup Items</CODE> folder of
-MPW called <A HREF="Python"><CODE>Python</CODE></A>. Type the lines:
-</P>
-
-<PRE>
-set Python "Macintosh HD:Applications:Python 1.5.2c1:"
-set PythonIncludes "{Python}Include"
-set PythonMacIncludes "{Python}Mac:Include"
-set PythonCore "{Python}PythonCore"
-
-export Python PythonIncludes PythonMacIncludes PythonCore
-</PRE>
-
-<P>
-where <CODE>Macintosh HD:Applications:Python 1.5.2c1:</CODE> is replaced by
-the path to the directory where you keep your copy of Python, and the other
-variables reflect where you keep your header files and Python core files.
-The locations here are the standard for Python 1.5.2c1, but they are
-different for Python 1.52b2 and earlier (most notably, the PythonCore is
-kept in the Extensions folder).
-</P>
-
-<P>
-Next, you need to update the <A HREF="config.h"><CODE>config.h</CODE></A>
-file for the <CODE>MrC</CODE> compiler included with MPW. This header file
-is located in the <CODE>:Mac:Include</CODE> folder in the standard
-distribution. You can update it by hand, by adding the lines:
-</P>
-
-<PRE>
-#ifdef __MRC__
-#define BAD_STATIC_FORWARD
-#endif
-</PRE>
-
-<P>
-at the after the similar defines for <CODE>__MWERKS__</CODE> and
-<CODE>__SC__</CODE> in the file. This step is critical: many modules,
-including ones in the standard distribution, will not compile properly
-without this modification (see common problems below).
-</P>
-
-<P>
-Copies of both the <A HREF="Python"><CODE>Python</CODE></A> startup item
-for MPW and the <A HREF="config.h"><CODE>config.h</CODE></A> are included
-here for your convenience.
-</P>
-
-<P>
-If you are porting Unix modules to the mac, you may find it useful to
-install <A
-HREF="http://www.iis.ee.ethz.ch/~neeri/macintosh/gusi-qa.html">GUSI</A> for
-your copy of MPW. GUSI provides some amount of POSIX compatibility, and is
-used by Python itself for this purpose - at the very least having it's
-header files available may be useful. Also of note for people porting Unix
-modules, the most recent alpha version (4.1a8) of <CODE>MrC</CODE> and
-<CODE>MrCpp</CODE> at this writing permits using unix-style pathnames for
-includes via the <CODE>-includes unix</CODE> command line option. I have
-not experimented heavily with this, but will be doing so in the future and
-report my findings.
-</P>
-
-<P>
-You now have MPW and Python set up to allow compilation of modules.
-</P>
-
-<H2><A NAME="compiling">Compiling a Module</A></H2>
-
-<P>
-This assumes that you have a C extension module ready to compile. For
-instructions on how to write a module, see the Python documentation.
-</P>
-
-<P>
-There are three approaches you can take to compiling in MPW: using the
-command line interface, using the MPW <CODE>CreateMake</CODE> command
-(available as the "Create build commands..." menu item, and writing a
-Makefile by hand.
-</P>
-
-<P>
-Before you start any of these, you'll need to know:
-</P>
-
-<UL>
- <LI>The names and locations of the C source files. In the examples, this
- is the file <A HREF="xxmodule.c"><CODE>xxmodule.c</CODE></A>, and is in
- MPW's current working directory.
- <LI>The name that Python expects to import your module under. In the
- examples, this is <CODE>xx</CODE>, so the shared library file will be
- called <CODE>xx.ppc.slb</CODE>.
- <LI>The location of any additional header files use by the C source. The
- example does not use any additional header files.
- <LI>The location of any additional shared libraries which the module needs
- to link to. The example does not link to any other shared libraries.
- <LI>The name of the entry point to your module. This is usually the last
- function in the main C source file, and the name usually starts with
- <CODE>init</CODE>. In the examples, this is <CODE>initxx</CODE>.
-</UL>
-
-<H3>Using the Command Line</H3>
-
-<P>
-For simple modules consisting of one or two C files, it's often convenient
-to simply use commands in a MPW Worksheet. Usually you will want to set
-MPW's working directory to the directory containing the C source code. The
-following commands compile and link the standard Python test module <A
-HREF="xxmodule.c"><CODE>xxmodule.c</CODE></A>:
-</P>
-
-<PRE>
-MrC "xxmodule.c" -o "xx.c.x" -w off -d HAVE_CONFIG_H &#8706;
- -i "{PythonMacIncludes}" &#8706;
- -i "{PythonIncludes}"
-PPCLink &#8706;
- -o "xx.ppc.slb" &#8706;
- "xx.c.x" &#8706;
- -t 'shlb' &#8706;
- -c 'Pyth' &#8706;
- -xm s &#8706;
- -d &#8706;
- "{PythonCore}" &#8706;
- "{SharedLibraries}InterfaceLib" &#8706;
- "{SharedLibraries}MathLib" &#8706;
- "{SharedLibraries}StdCLib" &#8706;
- "{PPCLibraries}StdCRuntime.o" &#8706;
- "{PPCLibraries}PPCCRuntime.o" &#8706;
- "{PPCLibraries}PPCToolLibs.o" &#8706;
- -export initxx
-</PRE>
-
-<P>
-(Note: The last character on each line should appear as "partial
-derivative" symbol, which you type as <KBD>option-d</KBD> and which is
-MPW's line continuation symbol.)
-</P>
-
-<P>
-Any additional header files should be specified by adding their directories
-as extra <CODE>-i</CODE> options to the <CODE>MrC</CODE> command. Any
-additional shared libraries should be added before the PythonCore library
-in the <CODE>PPCLink</CODE> command.
-</P>
-
-<P>
-If there is more than one source file, you will need to duplicate the
-compile command for each source file, and you will need to include all the
-object files in the place where <CODE>"xx.c.x"</CODE> appears in the
-<CODE>PPCLink</CODE> command.
-</P>
-
-<H3>Using CreateMake</H3>
-
-<P>
-For more complex modules, or modules that you are writing yourself, you
-will probably want to use a makefile. Unfortunately MPW's makefiles are
-incompatible with the standard Unix makefiles, so you will not be able to
-use any makefiles which come with a C module.
-</P>
-
-<P>
-Usually, you will want the makefile to reside in the same directory as the
-C source code, so you should set MPW's working directory to that directory
-before proceeding.
-</P>
-
-<P>
-To create a makefile for the standard Python test module <A
-HREF="xxmodule.c"><CODE>xxmodule.c</CODE></A>:
-</P>
-
-<UL>
- <LI>Select "Create build commands..." from the "Build" Menu.
- <LI>Type <KBD>xx.ppc.slb</KBD> for the Program Name.
- <LI>Select "Shared Library" for the Program Type.
- <LI>Select "PowerPC Only" for the Target.
- <LI>Click on the "Source Files..." button, and add your module's C source
- files to the list.
- <LI>Click on the "Other Options..." button and change the creator type to
- "Pyth". If you are using additional header files, you can also add their
- directories at this stage. Click on "Continue" once you have done this.
- <LI>Click on the "Exported Symbols..." button and type <KBD>initxx</KBD>
- into the entry field. Click on "Continue" once you have done this.
- <LI>At this stage, your CreateMake window should look like this: <IMG
- SRC="html.icons/createmake.png" ALT="[picture of commando window for CreateMake]">
- <LI>Click on the "CreateMake" button.
-</UL>
-
-<P>
-You will now need to edit the makefile that was just created. Open the
-file "xx.ppc.slb.make" in the current directory and make the following
-changes:
-</P>
-
-<UL>
- <LI>Change the line
-
- <PRE>
-Includes =
-</PRE>
-
- <P>
- to read
- </P>
-
- <PRE>
-Includes = -i "{PythonIncludes}" -i "{PythonMacIncludes}"
-</PRE>
-
- <P>
- If you have any additional headers than need to be included, you can add
- them here as well.
- <LI>Change the line
-
- <PRE>
-PPCCOptions = {Includes} {Sym&#8226;PPC}
-</PRE>
-
- <P>
- to read
- </P>
-
- <PRE>
-PPCCOptions = -w off -d HAVE_CONFIG_H {Includes} {Sym&#8226;PPC}
-</PRE>
-
- <P>
- <LI>After the line
-
- <PRE>
- -xm s &#8706;
-</PRE>
-
- <P>
- add
- </P>
-
- <PRE>
- -d &#8706;
- "{PythonCore}" &#8706;
-</PRE>
-
- <P>
- If you have any other shared libraries you need to link to, add each on a
- line before PythonCore, terminating each line with a <CODE>&#8706;</CODE>.
- </P>
-
-</UL>
-
-<P>Save the file. You are now ready to build.
-</P>
-
-<P>
-Go to the "Build" or "Full Build" menu items, type in
-<KBD>xx.ppc.slb</KBD>, and MPW should take things from there. Any time you
-need to rebuild the shared library, you can simply do another "Build" or
-"Full Build".
-</P>
-
-<H3>Writing a Makefile by Hand</H3>
-
-<P>
-For modules which have complex interdependencies between files, you will
-likely need a more sophisticated makefile than the one created by
-<CODE>CreateMake</CODE>. You will need to be familiar with the MPW
-makefile format, but you can get a start by either using
-<CODE>CreateMake</CODE> to get a simple starting point, or taking another
-MPW makefile as a starting point.
-</P>
-
-<P>
-It is beyond the scope of this HOWTO to go into the generalities of MPW
-makefiles. Documentation on MPW's <CODE>Make</CODE> command can be found
-with the MPW distribution, in particular the documents <A
-HREF="http://developer.apple.com/tools/mpw-tools/books.html#Building">Building
-and Maintaining Programs with MPW (2nd Edition)</A> and the <A
-HREF="http://developer.apple.com/tools/mpw-tools/books.html#CommandRef">MPW
-Command Reference</A>.
-</P>
-
-<P>
-There are a couple of important points to keep in mind when writing a
-makefile by hand:</P>
-
-<UL>
- <LI>When there are multiple symbols with the same name in object files or
- shared libraries, <CODE>PPCLink</CODE> used the symbol from the file which
- appears first in arguments of the <CODE>PPCLink</CODE> command. For this
- reason, you will usually want the PythonCore and any other shared libraries
- which are not part of the standard MPW runtime environment to appear before
- the standard runtime libraries. This is particularly the case with
- StdCLib. The "-d" option turns off the (often copious) warnings about
- multiply defined symbols.
- <LI>You will want to make sure that the <CODE>HAVE_CONFIG_H</CODE>
- preprocessor symbol is defined for most C source files using the <CODE>-d
- HAVE_CONFIG_H</CODE> option to <CODE>MrC</CODE>.
-</UL>
-
-<P>
-The file <A HREF="xx.ppc.slb.make.sit.hqx"><CODE>xx.ppc.slb.make</CODE></A>
-is included here for you to use as a starting point.
-</P>
-
-<H2><A NAME="using">Using the Extension Module</A></H2>
-
-<P>
-Once you have compiled your extension module, you will need to let Python
-know where it is. You can either move it into a place on Python's search
-path - such as the <CODE>:Mac:Plugins</CODE> folder - or modify the path to
-include the location of your new module using the
-<CODE>EditPythonPrefs</CODE> applet.
-</P>
-
-<P>
-Your work may not be completely done, as many extension modules have a
-Python wrapper around them. If the Python was not written with portability
-in mind, you may need to do some more work to get that up and running.
-Indeed, if the Python part uses OS-specific features, like pipes, you may
-have to completely rewrite it if you can make it work at all.
-</P>
-
-<H2><A NAME="problems">Common Problems</A></H2>
-
-<P>
-There are a couple of common problems which occur when porting a module
-from another platform. Fortunately, they are often easy to fix.
-</P>
-
-<H3>Static Forward Definitions</H3>
-
-<P>
-If you get a compiler error which looks something like:
-</P>
-
-<PRE>
-File "xxmodule.c"; line 135 #Error: 'Xxo_Type' is already defined
-</PRE>
-
-<P>
-then most likely either you have not set up <CODE>config.h</CODE> correctly
-to handle static forward definitions, or the module author has not adhered
-to the standard python conventions. If the second is the case, find where
-the variable is first defined, and replace the <CODE>static</CODE> with
-<CODE>staticforward</CODE>. Then find the second place it is defined
-(usually the line where the compiler complained) and replace
-<CODE>static</CODE> with <CODE>statichere</CODE>.
-</P>
-
-<P>
-If you have set up things correctly, you should now be able to compile.
-</P>
-
-<H3>Automatic Type Conversion</H3>
-
-<P>
-<CODE>MrC</CODE> seems to be a little pickier about automatically
-converting from one type to another than some other C compilers. These can
-often be fixed by simply adding an explicit cast to the desired type.
-</P>
-
-<P>
-XXX There may be a compiler option which relaxes this. That would be a
-better solution.
-</P>
-
-<H2><A NAME="caveats">Caveats</A></H2>
-
-<P>
-As Jack Jansen pointed out on the Mac Python mailing list, there could
-potentially be conflicts between the MetroWerks C runtime which the Python
-core and standard modules was compiled with, and the MPW C runtime which
-your extension module is compiled with. While things seem to work fine in
-everyday use, it is possible that there are bugs which have not been
-discovered yet. Most likely these world take the form of standard C
-functions (most likely I/O functions due to conflicts between the SIOUX
-libraries and the SIOW libraries) not working as they are supposed to, or
-memory leaks caused by improper malloc/free.
-</P>
-
-<P>
-Some such problems have been demonstrated by compiling modules with
-PythonCore linked after StdCLib - printf does not work properly in this
-setup, and I suspect that there will also be malloc/free problems in
-situations where the module allocates memory which is later disposed of by
-Python, or vice-versa. Compiling with PythonCore taking precedence over
-StdCLib seems to give the correct behaviour.
-</P>
-
-<P>
-This method of compiling should be considered experimental for the time
-being. <STRONG>Use it at your own risk.</STRONG>
-</P>
-
-<P>
-If you notice any quirks in modules compiled this way, or have insight into
-what may go wrong or right with this situation, <A
-HREF="mailto:cwebster@nevada.edu">please contact me</A> so that I can add
-it to the HOWTO.
-</P>
-
-<P>
-The ideal solution to this problem would be to get Python to compile using
-MPW (and a Python MPW Tool would be very neat indeed). However, that does
-seem to be a major project.
-</P>
-
-<DIV class=footer>
-<HR>
-<BR>
-&copy;<A HREF="mailto:cwebster@nevada.edu">Corran Webster</A>, 1999. <BR>
-<!-- #LASTMODIFIED TEXT="Last modified" FORM="SHORT,TIME" -->
-Last modified 14/12/99 12:17 PM
-<!-- /#LASTMODIFIED -->
-</DIV>
-
-</BODY>
-
-</HTML>
diff --git a/Mac/Demo/plugins.html b/Mac/Demo/plugins.html
deleted file mode 100644
index a49da68..0000000
--- a/Mac/Demo/plugins.html
+++ /dev/null
@@ -1,324 +0,0 @@
-<HTML><HEAD><TITLE>Creating a C extension module on the Macintosh</TITLE></HEAD>
-<BODY>
-<H1>Creating a C extension module on the Macintosh</H1>
-<HR>
-
-This document gives a step-by-step example of how to create a new C
-extension module on the mac. For this example, we will create a module
-to interface to the programmers' API of InterSLIP, a package that
-allows you to use MacTCP (and, hence, all internet services) over a
-modem connection. The actual example does not work anymore, as both
-MacTCP and Interslip died long ago, but the text is still mostly
-correct.<p>
-
-<H2>Prerequisites</H2>
-
-There are a few things you need to pull this off. First and foremost,
-you need a C development environment. Actually, you need a specific
-development environment, CodeWarrior by <A
-HREF="http://www.metrowerks.com/">MetroWerks</A>. You will
-need Version 7 or later. You may be able to get by with an older
-version of CodeWarrior or with another development environment (Up to
-about 1994 python was developed with THINK C, and in the dim past it
-was compiled with MPW C) assuming you have managed to get Python to
-compile under your development environment, but the step-by-step
-character of this document will be lost. <p>
-
-Next, you need to install the Developer option in the MacPython installer.
-You may also find that Guido's <A
-HREF="http://www.python.org/doc/ext/ext.html">Extending and embedding
-the Python interpreter</A> is a very handy piece of documentation. I
-will skip lots of details that are handled there, like complete
-descriptions of <CODE>Py_ParseTuple</CODE> and such utility routines, or
-the general structure of extension modules. <p>
-
-<H2>InterSLIP and the C API to it</H2>
-
-InterSLIP, the utility to which we are going to create a python
-interface, is a system extension that does all the work of connecting
-to the internet over a modem connection. InterSLIP is provided
-free-of-charge by <A
-HREF="http://www.intercon.com/">InterCon</A>. First it connects to
-your modem, then it goes through the whole process of dialling,
-logging in and possibly starting the SLIP software on the remote
-computer and finally it starts with the real work: packing up IP
-packets handed to it by MacTCP and sending them to the remote side
-(and, of course, the reverse action of receiving incoming packets,
-unpacking them and handing them to MacTCP). InterSLIP is a device
-driver, and you control it using a application supplied with it,
-InterSLIP Setup. The API that InterSLIP Setup uses to talk to the
-device driver is published in the documentation and, hence, also
-useable by other applications. <p>
-
-I happened to have a C interface to the API, which is all ugly
-low-level device-driver calls by itself. The C interface is in <A
-HREF="interslip/InterslipLib.c">InterslipLib.c</A> and <A
-HREF="interslip/InterslipLib.h">InterslipLib.h</A>, we'll
-concentrate here on how to build the Python wrapper module around
-it. Note that this is the "normal" situation when you are writing a
-Python extension module: you have some sort of functionality available
-to C programmers and want to make a Python interface to it. <p>
-
-<H2>Using Modulator</H2>
-
-The method we describe in this document, using Modulator, is the best
-method for small interfaces. For large interfaces there is another
-tool, Bgen, which actually generates the complete module without you
-lifting a single finger. Bgen, however, has the disadvantage of having
-a very steep learning curve, so an example using it will have to wait
-until another document, when I have more time. <p>
-
-First, let us look at the <A
-HREF="interslip/InterslipLib.h">InterslipLib.h</A> header file,
-and see that the whole interface consists of six routines:
-<CODE>is_open</CODE>, <CODE>is_connect</CODE>,
-<CODE>is_disconnect</CODE>, <CODE>is_status</CODE>,
-<CODE>is_getconfig</CODE> and <CODE>is_setconfig</CODE>. Our first
-step will be to create a skeleton file <A
-HREF="interslip/@interslipmodule.c">@interslipmodule.c</A>, a
-dummy module that will contain all the glue code that python expects
-of an extension module. Creating this glue code is a breeze with
-modulator, a tool that we only have to tell that we want to create a
-module with methods of the six names above and that will create the
-complete skeleton C code for us. <p>
-
-Why call this dummy module <CODE>@interslipmodule.c</CODE> and not
-<CODE>interslipmodule.c</CODE>? Self-preservation: if ever you happen
-to repeat the whole process after you have actually turned the
-skeleton module into a real module you would overwrite your
-hand-written code. By calling the dummy module a different name you
-have to make <EM>two</EM> mistakes in a row before you do this. <p>
-
-If you installed Tk support when you installed Python this is extremely
-simple. You start modulator and are provided with a form in which you
-fill out the details of the module you are creating. <p>
-
-<IMG SRC="html.icons/modulator.gif" ALIGN=CENTER><p>
-
-You'll need to supply a module name (<CODE>interslip</CODE>, in our
-case), a module abbreviation (<CODE>pyis</CODE>, which is used as a
-prefix to all the routines and data structures modulator will create
-for you) and you enter the names of all the methods your module will
-export (the list above, with <CODE>is_</CODE> stripped off). Note that
-we use <CODE>pyis</CODE> as the prefix instead of the more logical
-<CODE>is</CODE>, since the latter would cause our routine names to
-collide with those in the API we are interfacing to! The method names
-are the names as seen by the python program, and the C routine names
-will have the prefix and an underscore prepended. Modulator can do
-much more, like generating code for objects and such, but that is a
-topic for a later example. <p>
-
-Once you have told modulator all about the module you want to create
-you press "check", which checks that you haven't omitted any
-information and "Generate code". This will prompt you for a C output
-file and generate your module for you. <p>
-
-<H2>Using Modulator without Tk</H2>
-
-
-Modulator actually uses a two-stage process to create your code: first
-the information you provided is turned into a number of python
-statements and then these statements are executed to generate your
-code. This is done so that you can even use modulator if you don't
-have Tk support in Python: you'll just have to write the modulator
-python statements by hand (about 10 lines, in our example) and
-modulator will generate the C code (about 150 lines, in our
-example). Here is the Python code you'll want to execute to generate
-our skeleton module: <p>
-
-<CODE><PRE>
- import addpack
- addpack.addpack('Tools')
- addpack.addpack('modulator')
- import genmodule
-
- m = genmodule.module()
- m.name = 'interslip'
- m.abbrev = 'pyis'
- m.methodlist = ['open', 'connect', 'disconnect', 'status', \
- 'getconfig', 'setconfig']
- m.objects = []
-
- fp = open('@interslipmodule.c', 'w')
- genmodule.write(fp, m)
-</PRE></CODE>
-
-Drop this program on the python interpreter and out will come your
-skeleton module. <p>
-
-Now, rename the file to interslipmodule.c and you're all set to start
-developing. The module is complete in the sense that it should
-compile, and that if you import it in a python program you will see
-all the methods. It is, of course, not yet complete in a functional
-way... <p>
-
-<H2>Creating a plugin module</H2>
-
-The easiest way to build a plugin module is to use the distutils package,
-this works fine on MacOS with CodeWarrior. See the distutils documentation
-for details. Keep in mind that even though you are on the Mac you specify
-filenames with Unix syntax: they are actually URLs, not filenames.
- <p>
-
-Alternatively you can build the project file by hand.
-Go to the ":Mac:Build" folder and copy the files xx.carbon.mcp,
-and xx.carbon.mcp.exp to interslipmodule.carbon.mcp and
-interslipmodule.carbon.mcp.exp, respectively. Edit
-interslipmodule.carbon.mcp.exp and change the name of the exported routine
-"initxx" to "initinterslip". Open interslipmodule.carbon.mcp with CodeWarrior,
-remove the file xxmodule.c and add interslipmodule.c and make a number
-of adjustments to the preferences:
-<UL>
-<LI> in PPC target, set the output file name to "interslipmodule.carbon.slb",
-<LI> if you are working without a source distribution (i.e. with a normal
-binary distribution plus a development distribution) you will not have
-a file <code>PythonCoreCarbon</code>. The installation process has deposited this
-file in the System <code>Extensions</code> folder under the name
-<code>PythonCoreCarbon <i>version</i></code>. Add that file to the project, replacing
-<code>PythonCoreCarbon</code>.
-<LI> you must either download and build GUSI (if your extension module uses sockets
-or other Unix I/O constructs) or remove GUSI references from the Access Paths
-settings. See the <a href="building.html">Building</a> document for where to get GUSI
-and how to build it.
-</UL>
-Next, compile and link your module, fire up python and test it. <p>
-
-<H2>Getting the module to do real work</H2>
-
-So far, so good. In half an hour or so we have created a complete new
-extension module for Python. The downside, however, is that the module
-does not do anything useful. So, in the next half hour we will turn
-our beautiful skeleton module into something that is at least as
-beautiful but also gets some serious work done. For this once,
-<EM>I</EM> have spent that half hour for you, and you can see the
-results in <A
-HREF="interslip/interslipmodule.c">interslipmodule.c</A>. <p>
-
-We add
-<CODE><PRE>
- #include "InterslipLib.h"
- #include "macglue.h"
-</PRE></CODE>
-to the top of the file, and work our way through each of the methods
-to add the functionality needed. Starting with open, we fill in the
-template docstring, the value accessible from Python by looking at
-<CODE>interslip.open.__doc__</CODE>. There are not many tools using
-this information at the moment, but as soon as class browsers for
-python become available having this minimal documentation available is
-a good idea. We put "Load the interslip driver" as the comment
-here. <p>
-
-Next, we tackle the body of <CODE>pyis_open()</CODE>. Since it has no
-arguments and no return value we don't need to mess with that, we just
-have to add a call to <CODE>is_open()</CODE> and check the return for
-an error code, in which case we raise an error:
-<CODE><PRE>
- err = is_open();
- if ( err ) {
- PyErr_Mac(ErrorObject, err);
- return NULL;
- }
-</PRE></CODE>
-The routine <CODE><A NAME="PyErr_Mac">PyErr_Mac()</A></CODE> is a
-useful routine that raises the exception passed as its first
-argument. The data passed with the exception is based on the standard
-MacOS error code given, and PyErr_Mac() attempts to locate a textual
-description of the error code (which sure beats the "error -14021"
-messages that so many macintosh applications tell their poor
-users). <p>
-
-We will skip pyis_connect and pyis_disconnect here, which are pretty
-much identical to pyis_open: no arguments, no return value, just a
-call and an error check. With pyis_status() things get interesting
-again: this call still takes 3 arguments, and all happen to be values
-returned (a numeric connection status indicator, a message sequence
-number and a pointer to the message itself, in MacOS pascal-style
-string form). We declare variables to receive the returned values, do
-the call, check the error and format the return value. <p>
-
-Building the return value is done using <CODE><A
-NAME="Py_BuildValue">Py_BuildValue</A></CODE>:
-<CODE><PRE>
- return Py_BuildValue("iiO&", (int)status, (int)seqnum, PyMac_BuildStr255, message);
-</PRE></CODE>
-Py_BuildValue() is a very handy routine that builds tuples according
-to a format string, somewhat similar to the way <CODE>printf()</CODE>
-works. The format string specifies the arguments expected after the
-string, and turns them from C objects into python objects. The
-resulting objects are put in a python tuple object and returned. The
-"i" format specifier signifies an "int" (hence the cast: status and
-seqnum are declared as "long", which is what the is_status() routine
-wants, and even though we use a 4-byte project there is really no
-reason not to put the cast here). Py_BuildValue and its counterpart
-Py_ParseTuple have format codes for all the common C types like ints,
-shorts, C-strings, floats, etc. Also, there is a nifty escape
-mechanism to format values about which is does not know. This is
-invoked by the "O&" format: it expects two arguments, a routine
-pointer and an int-sized data object. The routine is called with the
-object as a parameter and it should return a python objects
-representing the data. <CODE>Macglue.h</CODE> declares a number of
-such formatting routines for common MacOS objects like Str255, FSSpec,
-OSType, Rect, etc. See the comments in the include file for
-details. <p>
-
-<CODE>Pyis_getconfig()</CODE> is again similar to pyis_getstatus, only
-two minor points are worth noting here. First, the C API return the
-input and output baudrate squashed together into a single 4-byte
-long. We separate them out before returning the result to
-python. Second, whereas the status call returned us a pointer to a
-<CODE>Str255</CODE> it kept we are responsible for allocating the
-<CODE>Str255</CODE> for getconfig. This is something that would have
-been easy to get wrong had we not used prototypes everywhere. Morale:
-always try to include the header files for interfaces to libraries and
-other stuff, so that the compiler can catch any mistakes you make. <p>
-
-<CODE>Pyis_setconfig()</CODE> finally shows off
-<CODE>Py_ParseTuple</CODE>, the companion function to
-<CODE>Py_BuildValue</CODE>. You pass it the argument tuple "args"
-that your method gets as its second argument, a format string and
-pointers to where you want the arguments stored. Again, standard C
-types such as strings and integers Py_ParseTuple knows all about and
-through the "O&" format you can extend the functionality. For each
-"O&" you pass a function pointer and a pointer to a data area. The
-function will be called with a PyObject pointer and your data pointer
-and it should convert the python object to the correct C type. It
-should return 1 on success and 0 on failure. Again, a number of
-converters for standard MacOS types are provided, and declared in
-<CODE>macglue.h</CODE>. <p>
-
-Next in our source file comes the method table for our module, which
-has been generated by modulator (and it did a good job too!), but
-which is worth looking at for a moment. Entries are of the form
-<CODE><PRE>
- {"open", pyis_open, 1, pyis_open__doc__},
-</PRE></CODE>
-where the entries are python method name, C routine pointer, flags and
-docstring pointer. The value to note is the 1 for the flags: this
-signifies that you want to use "new-style" Py_ParseTuple behaviour. If
-you are writing a new module always use this, but if you are modifying
-old code which calls something like <CODE>getargs(args, "(ii)",
-...)</CODE> you will have to put zero here. See "extending and
-embedding" or possibly the getargs.c source file for details if you
-need them. <p>
-
-Finally, we add some code to the init module, to put some symbolic
-constants (codes that can by returned by the status method) in the
-module dictionary, so the python program can use "interslip.RUN"
-instead of the cryptic "4" when it wants to check that the interslip
-driver is in RUN state. Modulator has already generated code to get at
-the module dictionary using PyModule_GetDict() to store the exception
-object, so we simply call
-<CODE><PRE>
- PyDict_SetItemString(d, "IDLE", PyInt_FromLong(IS_IDLE));
-</PRE></CODE>
-for each of our items. Since the last bit of code in our init routine
-checks for previous errors with <CODE>PyErr_Occurred()</CODE> and
-since <CODE>PyDict_SetItemString()</CODE> gracefully handles the case
-of <CODE>NULL</CODE> parameters (if <CODE>PyInt_FromLong()</CODE>
-failed, for instance) we don't have to do error checking here. In some
-other cases you may have to do error checking yourself. <p>
-
-This concludes our crash-course on writing Python extensions in C on
-the Macintosh. If you are not done reading yet I suggest you look
-back at the <A HREF="index.html">MacPython Crashcourse index</A> to
-find another topic to study. <p>
diff --git a/Mac/Demo/printing/PrintingDemo.py b/Mac/Demo/printing/PrintingDemo.py
deleted file mode 100644
index a42ac2f..0000000
--- a/Mac/Demo/printing/PrintingDemo.py
+++ /dev/null
@@ -1,93 +0,0 @@
-import Printing
-from Carbon import Qd
-from Carbon import Fm
-from Carbon import Res
-
-# some constants
-PostScriptBegin = 190 # Set driver state to PostScript
-PostScriptEnd = 191 # Restore QuickDraw state
-PostScriptHandle = 192 # PostScript data referenced in handle
-
-CHUNK_SIZE = 0x8000 # max size of PicComment
-
-def PostScript(text):
- """embed text as plain PostScript in print job."""
- handle = Res.Resource('')
- Qd.PicComment(PostScriptBegin, 0, handle)
- while text:
- chunk = text[:CHUNK_SIZE]
- text = text[CHUNK_SIZE:]
- handle.data = chunk
- Qd.PicComment(PostScriptHandle, len(chunk), handle)
- handle.data = ''
- Qd.PicComment(PostScriptEnd, 0, handle)
-
-# create a new print record
-printrecord = Printing.NewTPrintRecord()
-
-# open the printer
-Printing.PrOpen()
-try:
- # initialize print record with default values
- Printing.PrintDefault(printrecord)
-
- # page setup, ok is 0 when user cancelled
- ok = Printing.PrStlDialog(printrecord)
- if not ok:
- raise KeyboardInterrupt
- # at this stage, you should save the print record in your document for later
- # reference.
-
- # print job dialog, ok is 0 when user cancelled
- ok = Printing.PrJobDialog(printrecord)
- if not ok:
- raise KeyboardInterrupt
-
- # once per document
- port = Printing.PrOpenDoc(printrecord)
- # port is the Printer's GrafPort, it is also the current port, so no need to Qd.SetPort(port)
- try:
- # start printing a page
- # XXX should really look up what pages to print by
- # inspecting the print record.
- Printing.PrOpenPage(port, None)
- try:
- # use QuickDraw like in any other GrafPort
- Qd.FrameRect((10, 250, 100, 500))
- Qd.FrameRect((10, 510, 100, 600))
- Qd.MoveTo(10, 100)
- Qd.TextSize(50)
- Qd.TextFont(Fm.GetFNum("Helvetica"))
- Qd.DrawString("It rreally works!")
- Qd.MoveTo(10, 150)
- Qd.TextSize(20)
- Qd.DrawString("(and now for a little PostScript...)")
-
- # example PostScript code
- ps = """
- % the coordinate system is the quickdraw one, which is flipped
- % compared to the default PS one. That means text will appear
- % flipped when used directly from PostScript.
- % As an example we start by defining a custom scalefont operator
- % that corrects this.
- /myscalefont{[exch 0 0 2 index neg 0 0]makefont}def
- 0.75 setgray
- 0 0 moveto
- 0 30 lineto 10000 30 lineto
- 10000 0 lineto closepath fill
- 0 setgray
- 5 25 moveto /Courier findfont 20 myscalefont setfont
- (Printed with PostScript!) show
- 2 setlinewidth [10 10 5 10] 0 setdash 5 5 moveto 400 0 rlineto stroke
- """
- # embed the PostScript code in the print job
- PostScript(ps)
- finally:
- # when done with the page
- Printing.PrClosePage(port)
- finally:
- # when done with the document
- Printing.PrCloseDoc(port)
-finally:
- # when done printing
- Printing.PrClose()
diff --git a/Mac/Demo/using.html b/Mac/Demo/using.html
deleted file mode 100644
index 5048ac3..0000000
--- a/Mac/Demo/using.html
+++ /dev/null
@@ -1,429 +0,0 @@
-<HTML>
-<HEAD>
-<TITLE>Using Python 2.0 on the Macintosh</TITLE>
-</HEAD>
-<BODY>
-<H1>Using Python 2.0 on the Macintosh</H1>
-<HR>
-
-This document is an introduction to using Python on the Apple
-Macintosh. It does not introduce the language itself, for this you
-should refer to the <A
-HREF="http://www.python.org/doc/tut/tut.html">Python Tutorial</A> by
-Guido van Rossum. This guide more-or-less replaces chapter two of the
-tutorial, and provides some additional material. <p>
-
-The tutorial, along with other indispensible documentation like the
-library reference and such, is also available in a number of different
-formats at <a href="http://www.python.org">
-www.python.org</a>. The Adobe Acrobat <code>.pdf</code>
-files are probably a good choice for reading or printing the documents
-from your mac. <p>
-
-There is currently no good tutorial for the mac-specific features of
-Python, but to whet your appetite: it has interfaces to many MacOS
-toolboxes (quickdraw, sound, quicktime, open scripting, etc) and
-various portable toolboxes are available too (Tk, complex
-numbers, image manipulation, etc). Some <A HREF="index.html">
-annotated sample programs</A> are available to give you an idea of
-Python's power. <P>
-
-<h2>Using Python</h2>
-
-The best way to start using Python is by using the <code>Python IDE</code>,
-an integrated development environment with editor, debugger, class browser, etc.
-Unfortunately the IDE is not yet documented here. Fortunately, however, it does not
-need much documentation, so your best bet is to try it. <p>
-
-<h2>Invoking the bare interpreter</h2>
-
-An alternative method to use Python (and the method this document unfortunately emphasizes,
-see the comment above) is to use the bare interpreter and an external text editor.
-The name of the interpreter is <CODE>PythonInterpreter</CODE> and it is
-recognizable by the "16 ton" icon. You start the
-interpreter in interactive mode by double-clicking its icon: <p>
-
-<img src="html.icons/python.gif"><p>
-
-This should give you a text window with an informative version string
-and a prompt, something like the following:
-<PRE>
-Python 1.5.1 (#122 Aug 27, 1997) [CW PPC w/GUSI MSL]
-Copyright 1991-1997 Stichting Mathematisch Centrum, Amsterdam
-&gt;&gt;&gt;
-</PRE>
-The version string tells you the version of Python, whether it was
-built for PPC or 68K macs and possibly some options used to build the
-interpreter. If you find a bug or have a question about how the
-interpreter works it is a good idea to include the version information
-in your message. <p>
-
-At the prompt you can type interactive python commands. See the
-tutorial for more information. The interactive window works
-more-or-less like a Communication Toolbox or Telnet window: you type
-commands at the bottom and terminate them with the <EM>[return]</EM>
-or <EM>[enter]</EM> key. Interpreter feedback also appears at the
-bottom of the window, and the contents scroll as output is added. You
-can use copy and paste in the normal way, but be sure to paste only at
-the bottom of the document.
-
-<h2>Creating Python scripts</h2>
-
-The Python interpreter works in a way that is different from what you
-would expect of a macintosh program: the interpreter is just that: an
-interpreter. There is no builtin editor or other development
-support. Hence, to create a Python script you need an external text
-editor. For a first script you can use any editor that can create
-plain, unstyled text files, such as <CODE>SimpleText</CODE>. <p>
-
-For more serious scripts, though, it is advisable to use a programmers
-editor, such as <CODE>BBEdit</CODE> or <CODE>Alpha</CODE>. BBEdit is
-my favorite: it comes in a commercial version but also in a
-fully-functional free version <CODE>BBEdit Lite</CODE>. You can
-download it from the <A HREF="http://www.barebones.com/">BareBones</A>
-site. The free version will probably provide all the functionality
-you will ever need. Besides the standard edit facilities it has
-multi-file searches and many other goodies that can be very handy when
-editing programs. <p>
-
-After you have created your script in the editor of your choice you
-drop it on the interpreter. This will start the interpreter executing
-the script, again with a console window in which the output appears
-and in which you can type input if the script requires it. Normally
-the interpreter will close the window and quit as soon as the script
-is done executing, see below under <A HREF="#startup">startup
-options</A> for a way to change this. <p>
-
-<blockquote>
-There is a BBEdit extension available that allows you to run Python
-scripts more-or-less straight from your bbedit source window. Check
-out the <code>Mac:Tools:BBPy</code> folder.
-</blockquote>
-
-It is a good idea to have the names of all your scripts end in
-<CODE>.py</CODE>. While this is not necessary for standalone scripts
-it is needed for modules, and it is probably a good idea to start the
-habit now. <p>
-
-If you do not like to start the Python interpreter afresh for each
-edit-run cycle you can use the <CODE>import</CODE> statement and
-<CODE>reload()</CODE> function to speed things up in some cases. Here
-is Guido's original comment for how to do this, from the 1.1 release
-notes: <P>
-
-<BLOCKQUOTE>
-
-Make sure the program is a module file (filename must be a Python
-identifier followed by '<CODE>.py</CODE>'). 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. <P>
-
-Recovery from a syntax error is easy: edit the file and import it
-again. <P>
-
-Recovery from wrong output is almost as easy: edit the file and,
-instead of importing it, call the function <CODE>reload()</CODE> with
-the module name as argument (e.g., if your module is called
-<CODE>foo</CODE>, type <CODE>reload(foo)</CODE>). <P>
-
-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 <CODE>reload()</CODE>,
-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, <CODE>import foo; reload(foo)</CODE>. 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. </BLOCKQUOTE>
-
-<h2>Clickable python scripts</h2>
-
-If you create your script with the correct creator and type, creator
-<CODE>'Pyth'</CODE> and type <CODE>'TEXT'</CODE>, you can double-click
-your script and it will automatically invoke the interpreter. If you
-use BBEdit you can tell it about the Python file type by adding it to
-the "file types" sections of the preferences. Then, if you save a file
-for the first time you can tell BBEdit to save the file as a Python
-script through the "options" choice of the save dialog. <p>
-
-The <CODE>Scripts</CODE> folder contains a script
-<CODE>fixfiletypes</CODE> that will recursively traverse a folder and
-set the correct creator and type for all files ending in
-<CODE>.py</CODE>. <p>
-
-<BLOCKQUOTE>
-Older releases of Python used the creator code
-<CODE>'PYTH'</CODE> in stead of <CODE>'Pyth'</CODE>. If you still have
-older Python sources on your system and named them with
-<CODE>'.py'</CODE> extension the <CODE>fixfiletypes</CODE> script will
-correct them.
-</BLOCKQUOTE>
-
-<h2>Interaction with the user</h2>
-
-Normally, the interpreter will check for user input (mouse clicks,
-keyboard input) every once in a while, so it is possible to switch to
-other applications while a script runs. It is also possible to
-interrupt the interpreter with the standard command-period keypress,
-this will raise the <CODE>KeyboardInterrupt</CODE> exception. Scripts
-may, however, turn off this behaviour to facilitate their own event
-handling. Such scripts can only be killed with the
-command-option-escape shortcut.
-
-<h2><A NAME="startup">startup options</A></h2>
-
-If the <EM>option</EM> key is depressed when Python starts executing
-the interpreter will bring up an options dialog thru which you can
-influence the way the interpreter behaves. Keep the option key
-depressed until the dialog comes up. <p>
-
-<img src="html.icons/options.gif"><p>
-
-The options modify the interpreters behaviour in the following way:
-<ul>
-<li> the interpreter goes to interactive mode (in stead of
-exiting) after a script has terminated normally,
-<li> for every module imported a line is printed telling you where the
-module was loaded from,
-<li> do not print the values of expressions executed as statements in
-an interactive python (obsolete),
-<li> do not buffer stdout and stderr,
-<li> print some debugging output during the parsing phase,
-<li> keep the output window open when a script terminates.
-</ul>
-In addition, you can enter a unix-style command line which is passed
-to the script in <CODE>sys.argv</CODE>. Sys.argv[0] is always the name
-of the script being executed, additional values can be passed
-here. Quoting works as expected. <p>
-
-<BLOCKQUOTE>
-<EM>Warning:</EM> redirecting standard input or standard output in the
-command-line dialog does not work. This is due to circumstances beyond my
-control, hence I cannot say when this will be fixed.
-</BLOCKQUOTE>
-
-The default options are also settable on a system-wide basis, see the
-section on <A HREF="#preferences">editing preferences</A>. <p>
-
-<h2>Module search path</h2>
-
-The module search path, <CODE>sys.path</CODE>, contains the folders
-python will search when you import a module. The path is settable on a
-system-wide basis (see the preferences section), and normally
-comprises the current folder (where the script lives), the
-<CODE>Lib</CODE> folder and some of its subfolders and possibly some
-more. <p>
-
-<h2>Working folder</h2>
-
-The unix concept of a <I>working directory</I> does not translate
-directly to a similar concept on the Macintosh. To facilitate easy
-porting and the use of relative pathnames in scripts the interpreter
-simulates a working directory. When a script is started the initial
-working directory is the folder where the script lives. In case of an
-interactive interpreter the working directory is the folder where the
-interpreter lives. <P>
-
-By the way: the "standard file" folder, the folder that is presented
-to the user initially for an <I>open</I> or <I>save</I> dialog, does
-<EM>not</EM> follow the Python working directory. Which folder is
-initially shown to the user is usually one of (a) the application
-folder, (b) the "Documents" folder or (c) the folder most recently
-used for such a dialog (in any Python program). This is standard MacOS
-behaviour, so don't blame Python for it. The exact behaviour is
-settable through a control panel since System 7.5.
-
-<h2>Interactive startup file</h2>
-
-If the folder containing the interpreter contains a file named
-<CODE>PythonStartup</CODE> this file is executed when you start an
-interactive interpreter. In this file you could import modules you
-often use and other such things. <p>
-
-
-<h2>Compiled python scripts</h2>
-
-Once a python module has been imported the interpreter creates a
-compiled version which is stored in a file with the ".py" extension
-replaced by ".pyc". These compiled files, with creator
-<CODE>'Pyth'</CODE> and type <CODE>'PYC '</CODE> load faster when
-imported (because they do not have to be parsed). The <CODE>Lib</CODE>
-folder contains a script <CODE>compileall.py</CODE>, running this
-script will cause all modules along the python search path to be
-precompiled, which will speed up your programs. Compiled files are
-also double-clickable. <p>
-
-<h2>Python resources</h2>
-
-MacPython has the ability to collect a number of compiled modules
-together in the resource fork of a single file. This feature is useful
-if you distribute a python program and want to minimize clutter: you
-can put all the needed modules in a single file (which could even be
-the interpreter itself). <p>
-
-If the module search path contains a filename as one of its entries
-(as opposed to a folder name, which is the normal case) this file will
-be searched for a resource with type <CODE>'PYC '</CODE> and a name
-matching the module being imported. <p>
-
-The <CODE>scripts</CODE> folder contains a script
-<CODE>PackLibDir</CODE> which will convert a number of modules (or
-possibly a complete subtree full of modules) into such a resource
-file.
-
-<h2><A NAME="preferences">Setting interpreter preferences</A></h2>
-
-The python interpreter keeps a preferences file in the standard
-location in the system folder. In this preferences file it remembers
-the default module search path and the default settings for the
-runtime options. The preferences are settable via
-<CODE>EditPythonPrefs</CODE>. For PPC/cfm68k python this is a standalone
-program living in the main Python folder, for 68K python it is a
-script in the <CODE>Mac:Scripts</CODE> folder. <p>
-
-The interface to edit the preferences is rather clunky for the current
-release. <p>
-
-<img src="html.icons/preferences.gif"><p>
-
-In the editable text field at the top you enter the initial module
-search path, using newline as a separator. There are two special
-values you can use here: an initial substring <CODE>$(PYTHON)</CODE>
-will expand to the Python home folder and a value of
-<CODE>$(APPLICATION)</CODE> will expand to the the python application
-itself. Note that the text field may extend "beyond the bottom" even
-though it does not have a scroll bar. Using the arrow keys works,
-though.<p>
-
-The Python home folder $(PYTHON) is initially, when you install Python,
-set to the folder where the interpreter lives. You can change it here. <p>
-
-Finally, you can set the default startup options here, through a
-sub-dialog.
-
-<h2>Applets</h2>
-
-An applet is a fullblown application written in Python, similar to an
-AppleScript applet (and completely different from a Java
-applet). Applets are currently supported on PowerPC macintoshes and on
-68K macintoshes if you use the CFM68K version of the interpreter,
-and are created using the <CODE>BuildApplet</CODE> program. You create an
-applet by dropping the python source script onto BuildApplet.
-<a href="example2.html">Example 2</a> is a more involved applet
-with its own resource file, etc. <p>
-
-Note that while an applet behaves as a fullblown Macintosh application
-it is not self-sufficient, so distributing it to a machine without an
-installed Python interpreter will not work: it needs the shared python
-execution engine <CODE>PythonCore</CODE>, and probably various modules
-from the Lib and PlugIns folders. Distributing it to a machine that does
-have a Python system will work. <p>
-
-<h2>Customizing applets</h2>
-
-Applets can have their own settings for the startup options and module
-search path. Dropping an applet on the <CODE>EditPythonPrefs</CODE>
-application allows you to set these, in the same way as
-double-clicking EditPythonPrefs allows you to set the system-wide
-defaults. <p>
-
-Actually, not only applets but also the interpreter itself can have
-non-default settings for path and options. If you make a copy of the
-interpreter and drop this copy onto EditPythonPrefs you will have an
-interpreter that has a different set of default settings. <p>
-
-<h2>Where to go from here</h2>
-
-The previously mentioned <A
-HREF="http://www.python.org/doc/tut/tut.html">Python Tutorial</A> is
-an excellent place to start reading if you have never used Python
-before. Other documentation such as the library reference manual is
-indexed at the <A HREF="http://www.python.org/doc/">Python
-Documentation</A> page. <p>
-
-There are some <A HREF="index.html">annotated sample programs</A>
-available that show some mac-specific issues, like use of various
-toolboxes and creation of Python applets. <p>
-
-The <CODE>Demo</CODE> and <CODE>Mac:Demo</CODE>
-folders in the Macintosh distribution
-contains a number of other example programs. Most of these are only
-very lightly documented, but they may help you to understand some
-aspects of using Python. <p>
-
-Finally, there is a <code>Mac:Contrib</code> folder that contains
-a few contributions to Python that I couldn't fit in the normal tree
-but did want to distribute (many other contributions are contained
-throughout the distribution, but you don't see them, really).
-
-The best way to contact fellow Macintosh Python programmers is to join
-the MacPython Special Interest Group mailing list. Send a message with
-"info" in the body to <A
-HREF="mailto:pythonmac-sig-request@python.org">pythonmac-sig-request@python.org</A>
-or view the <A
-HREF="http://www.python.org/sigs/pythonmac-sig/">Pythonmac SIG
-page</A> on the <A HREF="http://www.python.org">www.python.org</A> WWW
-server. <p>
-
-<h2>Troubleshooting</h2>
-
-A rather baffling error message can be "PythonCore not found" when you
-start the interpreter and you are sure that PythonCore is available. The
-message should actually say "Not enough memory in the system heap to
-load PythonCore".
-Blame Apple for the confusing message. <p>
-
-There appear to be problems with QuickTime for the CFM68K version of the
-interpreter. If you experience these please contact the SIG: some people
-use quicktime without problems and some not, and we are still hunting for
-the cause. <p>
-
-Python is a rather safe language, and hence it should be difficult to
-crash the interpreter of the system with a Python script. There is an
-exception to this rule, though: the modules that interface to the
-system toolboxes (windowing, quickdraw, etc) do very little error
-checking and therefore a misbehaving program using these modules may
-indeed crash the system. Such programs are unfortunately rather
-difficult to debug, since the crash does not generate the standard
-Python stack trace, obviously, and since debugging print statements
-will often interfere with the operation of the program. There is
-little to do about this currently. <p>
-
-Probably the most common cause of problems with modules ported from
-other systems is the Mac end-of-line convention. Where unix uses
-linefeed, 0x0a, to separate lines the mac uses carriage return,
-0x0d. To complicate matters more a lot of mac programming editors like
-BBEdit and emacs will work happily with both conventions, so the file
-will appear to be correct in the editor but cause strange errors when
-imported. BBEdit has a popup menu which allows you to inspect (and
-set) the end-of-line convention used in a file. <p>
-
-Python attempts to keep its preferences file up-to-date even when you
-move the Python folder around, etc. If this fails the effect will be
-that Python cannot start or, worse, that it does work but it cannot find
-any standard modules. In this case, start Python and examine <code>sys.path</code>.
-If it is incorrect remove any Python preferences file from the system
-folder and start the interpreter <em>while the interpreter sits in the main
-Python folder</em>. This will regenerate the preferences file. You may also
-have to run the ConfigurePython applet again. <p>
-
-<h2>Your five minutes are up. Next!</h2>
-
-The next section to check out is the <a href="index.html">annotated sample programs</a>.<p>
-
-<HR>
-<A HREF="http://www.cwi.nl/~jack">Jack Jansen</A>,
-<A HREF="mailto:jack@cwi.nl">jack@cwi.nl</A>, 10-Sep-00.
-
-</BODY>
-</HTML>