Modified for installer and new names of various applets. Also cleaned
up anything else I saw.
This commit is contained in:
Jack Jansen
parent
9ffa432972
commit
3412c5d0fb
|
|
@ -54,7 +54,7 @@ Neeracher. The original CWGUSI is
|
|||
obtainable from <A
|
||||
HREF="ftp://sunsite.cnlab-switch.ch/software/platform/macos/src">
|
||||
ftp://sunsite.cnlab-switch.ch/software/platform/macos/src</A>.
|
||||
At the moment Python is built with a slightly modified version of GUSI 1.8.1fc2,
|
||||
At the moment Python is built with a slightly modified version of GUSI,
|
||||
these modifications are available in folder <code>Python:Mac:GUSI-mods</code>.
|
||||
|
||||
</UL>
|
||||
|
|
@ -121,32 +121,31 @@ Top-level-folder:
|
|||
zlib
|
||||
libpng
|
||||
gdbm
|
||||
MoreFiles 1.4.3 (not needed by Python, only by tcl/tk)
|
||||
Python
|
||||
Tcl/Tk Folder
|
||||
tcl8.0
|
||||
tk8.0
|
||||
MoreFiles 1.4.3
|
||||
Waste 1.2 distribution (if you want waste)
|
||||
</PRE>
|
||||
|
||||
First build GUSI. If you didn't get the python-specific GUSI you have to
|
||||
move the files from the "CWGUSI-mods" to the right
|
||||
place in the CWGUSI distribution folder. Build the MSL target for your
|
||||
platform (MSLGUSI PPC, MSLGUSI 68K or MSLGUSI CFM68K). <p>
|
||||
place in the CWGUSI distribution folder. Build the MSL version for your
|
||||
platform (ppc, 68k, cfm68k). <p>
|
||||
|
||||
Next, in
|
||||
<code>MoreFiles</code>, <code>libjpeg</code>, <code>pbmplus</code>,
|
||||
<code>zlib</code>, <code>libpng</code>, <code>gdbm</code>,
|
||||
and<code>libtiff</code> you build all projects. The projects are in "mac"
|
||||
and<code>libtiff</code> you build all projects. Sometimes the projects are in "mac"
|
||||
subfolders, sometimes they are in the main folder. Tcl/tk is a special
|
||||
case, see below. Of course, if you are only interested in one of
|
||||
static 68K, CFM68K or PPC you can skip building the other libraries.
|
||||
|
||||
<H2><A NAME="tcltk">Building Tcl/Tk</H2>
|
||||
|
||||
You need to make some minor changes to the Tcl/Tk 8.0 beta2
|
||||
distribution. You should make the CW Pro projects TclLibraries.¹ and
|
||||
TkLibraries.¹ (in the mac subfolders).
|
||||
You need to make some minor changes to the Tcl/Tk 8.0
|
||||
distribution. You should make the CW Pro projects (in the mac subfolders).
|
||||
<UL>
|
||||
|
||||
<LI> There are no cfm68k targets. You make these by copying the 68k targets,
|
||||
|
|
@ -191,14 +190,19 @@ the Python source tree. At the top level, we find the following
|
|||
folders:
|
||||
|
||||
<DL>
|
||||
<DT> build.mac
|
||||
<DD> This is where you build the PPC, CFM68K and Fat shared libraries,
|
||||
interpreter and applet framework. The Fat versions, which are derived
|
||||
from the other two, are deposited in the parent folder.
|
||||
<DT> build.mac68k.stand
|
||||
<DD> This is where you build static 68K interpreters.
|
||||
|
||||
<DT> build.macstand
|
||||
<DD> This is where you build static 68K interpreters, and possibly static
|
||||
PPC interpreters (but you probably won't need those).
|
||||
<DT> build.mac68k.shared
|
||||
<DD> This is where you build the CFM68K shared library, interpreter
|
||||
and applet framework.
|
||||
|
||||
<DT> build.macppc.shared
|
||||
<DD> This is where you build the PPC shared library, interpreter and
|
||||
applet framework. You can also build the fat applet framework here.
|
||||
|
||||
<DT> build.macppc.stand
|
||||
<DD> This is where you build a nonshared PPC interpreter (optional).
|
||||
|
||||
<DT> Demo
|
||||
<DD> Demo programs that are not Mac-specific. Some of these may not
|
||||
|
|
@ -307,11 +311,11 @@ use your imagination to work them out.
|
|||
|
||||
If you have all the optional libraries mentioned <A
|
||||
HREF="#optional">above</A> loaded buildin Python for 68K macs is a
|
||||
breeze: open the project in the folder <code>build.mac68k.stand</code>
|
||||
and build it. Do <em>not</em> run it yet, this will possibly result
|
||||
in a garbled preferences file. <p>
|
||||
breeze: open the project in the folder <code>build.macstand</code> and
|
||||
build the 68K target. Do <em>not</em> run it yet, this will possibly
|
||||
result in a garbled preferences file. <p>
|
||||
|
||||
First remove the <code>Python preferences</code> file from your
|
||||
First remove the <code>Python XXX preferences</code> file from your
|
||||
preference folder, only if you had an older version of Python
|
||||
installed. (this is also what you do if you did not heed the last
|
||||
sentence of the preceeding paragraph). Next, move the interpreter to
|
||||
|
|
@ -320,35 +324,31 @@ create a correct initial preferences file. You are now all set, and
|
|||
your tree should be completely compatible with a binary-only
|
||||
distribution. Read the release notes
|
||||
(<code>Relnotes-somethingorother</code>) and
|
||||
<code>ReadMeOrSuffer</code> in the <code>Mac</code> folder.
|
||||
<code>ReadMe</code> in the <code>Mac</code> folder.
|
||||
|
||||
<H2>Building the CFM68K interpreter</H2>
|
||||
|
||||
Building the CFM68K interpreter is as almost exactly the same as building
|
||||
the PPC interpreter, with the exception that you should read "CFM68K"
|
||||
for "PPC" every time. Continue reading with the next section.
|
||||
|
||||
<H2>Building the PPC interpreter</H2>
|
||||
<H2>Building the PPC and CFM68K interpreter</H2>
|
||||
|
||||
First you build the interpreter, core library and applet skeleton in
|
||||
folder <code>build.macppc.stand</code>. The order to build things is
|
||||
the following:
|
||||
folder <code>build.mac</code>. The projects are all linked together, so
|
||||
building the fat targets in <code>Python.prj</code> and
|
||||
<code>PythonApplet.prj</code> will result in everything being built. The
|
||||
resulting applications and fat shared library are deposited in the main
|
||||
Python folder. For completeness sake here is a breakdown of the
|
||||
projects:
|
||||
|
||||
<DL>
|
||||
|
||||
<DT> PythonCorePPC
|
||||
<DT> PythonCore (with subprojects PythonCorePPC and PythonCoreCFM68K)
|
||||
<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.
|
||||
moving the file will cause you grief later if you rebuild the library and
|
||||
forget to copy it to the extensions folder again.
|
||||
|
||||
<DT> PythonPPC
|
||||
<DT> Python
|
||||
<DD> The interpreter. This is basically a routine to call out to the
|
||||
shared library. Do
|
||||
<em>not</em> run it yet, this will possibly result in a garbled
|
||||
preferences file. See the section below on rebuilding .exp files if you
|
||||
get funny linker errors. <p>
|
||||
shared library. <p>
|
||||
|
||||
<DT> PythonAppletPPC
|
||||
<DD> The applet skeleton application. Very similar to
|
||||
|
|
@ -359,29 +359,23 @@ applet. <p>
|
|||
|
||||
</DL>
|
||||
|
||||
After creating the alias to <code>PythonCorePPC</code> you should move
|
||||
<code>PythonPPC</code> to the main Python folder. Next you remove any old
|
||||
After creating the alias to <code>PythonCore</code> you remove any old
|
||||
<code>Python XXX 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. You should also make an alias
|
||||
<code>PythonApplet</code> pointing to <code>PythonAppletPPC</code> in the main
|
||||
Python folder. (again: making an alias is preferrable to copying or moving the
|
||||
file, since this will cause the correct file to be used if you ever rebuild
|
||||
PythonAppletPPC). <p>
|
||||
to create the correct preferences file. <p>
|
||||
|
||||
Next, you have to build the extension modules in the
|
||||
<code>PlugIns</code> folder. Open each project with <code>.ppc</code> in the
|
||||
name and build it. After all
|
||||
<code>PlugIns</code> folder. The <code>PlugIns.ppc</code> project has all the
|
||||
other projects as subprojects and builds everything. After all
|
||||
the dynamically loaded modules are built you have to create a number
|
||||
of aliases: some modules live together in a single dynamic
|
||||
library. Run the <code>MkPluginAliases.py</code> script from
|
||||
library. Run the <code>ConfigurePython.py</code> script from
|
||||
<code>Mac:scripts</code> to create the aliases. <p>
|
||||
|
||||
Finally, you must build the standard applets:
|
||||
<code>EditPythonPrefs</code>, <code>mkapplet</code>, etc. This is
|
||||
<code>EditPythonPrefs</code>, <code>BuildApplet</code>, etc. This is
|
||||
easiest done with the <code>fullbuild</code> script from
|
||||
<code>Mac:scripts</code>. Answer <em>no</em> to all questions except
|
||||
when it asks whether to build the applets. <p>
|
||||
<code>Mac:scripts</code>. <p>
|
||||
|
||||
<BLOCKQUOTE>
|
||||
Actually, the <code>fullbuild</code> script can be used to build
|
||||
|
|
@ -392,13 +386,10 @@ place and use that to run fullbuild, or use the standalone PPC python
|
|||
for this. I tend to keep a standalone interpreter in a safe place for
|
||||
this use only. <p>
|
||||
|
||||
Using fullbuild is also the only easy way to buid the fat application and applet.
|
||||
See the fullbuild source for details on how to build the fat binaries "by hand".
|
||||
|
||||
</BLOCKQUOTE>
|
||||
|
||||
You are all set now, and should read the release notes and
|
||||
<code>ReadMeOrSuffer</code> file from the <code>Mac</code> folder.
|
||||
<code>ReadMe</code> file from the <code>Mac</code> folder.
|
||||
|
||||
<H2>Rebuilding <code>.exp</code> files for PPC and CFM68K</H2>
|
||||
|
||||
|
|
@ -437,7 +428,7 @@ complete Python. Take the binary distribution, add folders
|
|||
<code>Include</code>, <code>Mac:Include</code> and
|
||||
<code>Mac:mwerks</code> from the source distribution and you should be
|
||||
all set. A template for a dynamic module can be found in
|
||||
<code>xx.ppc.µ</code> or <code>xx.CFM68K.µ</code>.
|
||||
<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
|
||||
|
|
|
|||
|
|
@ -28,9 +28,9 @@ 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>PythonCorePPC</code> or <code>PythonCoreCFM68K</code>. An example project
|
||||
and source can be found in the <a href="embed">embed</a> folder.
|
||||
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.
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ on different machines, with one exception:
|
|||
<li> Unix systems terminate lines with the "linefeed" character, <code>0x0a</code>,
|
||||
<li> Macintoshes terminate lines with the "carriage return" character,
|
||||
<code>0x0d</code> and
|
||||
<li> MSDOS systems terminate lines with first a carriage return and then a linefeed.
|
||||
<li> MSDOS and Windows terminate lines with first a carriage return and then a linefeed.
|
||||
</ul>
|
||||
|
||||
Let us have a look at the program. The first interesting statement in the main
|
||||
|
|
|
|||
|
|
@ -10,10 +10,7 @@ applets, standalone applications written in Python. <A
|
|||
HREF="example2/InterslipControl-2.py">Source</A> and resource file (in
|
||||
binary and <A HREF="example2/InterslipControl-2.rsrc.hqx">BinHex</A>
|
||||
form for downloading) are available in the folder <A
|
||||
HREF="example2">example2</A>. If you want to run the program on your
|
||||
machine and you have Python 1.3 or earlier you will also need a new copy of <A
|
||||
HREF="update-to-1.3/FrameWork.py">FrameWork.py</A>, which has been
|
||||
updated since the 1.3 release. <p>
|
||||
HREF="example2">example2</A>. <p>
|
||||
|
||||
Again, we start with ResEdit to create our dialogs. Not only do we
|
||||
want a main dialog this time but also an "About" dialog, and we
|
||||
|
|
@ -31,7 +28,7 @@ off, there's the standard BNDL combo. I've picked 'PYTi' as signature
|
|||
for the application. I tend to pick PYT plus one lower-case letter for
|
||||
my signatures. The finder gets confused if you have two applications
|
||||
with the same signature. This may be due to some incorrectness on the
|
||||
side of "mkapplet", I am not sure. There is one case when you
|
||||
side of "BuildApplet", I am not sure. There is one case when you
|
||||
definitely need a unique signature: when you create an applet that has
|
||||
its own data files and you want the user to be able to start your
|
||||
applet by double-clicking one of the datafiles. <p>
|
||||
|
|
@ -135,26 +132,27 @@ nothing has changed. <p>
|
|||
|
||||
<H2><IMG SRC="html.icons/mkapplet.gif"><A NAME="applets">Creating applets</A></H2>
|
||||
|
||||
Now, if you have a PowerPC Macintosh, let us try to turn the python
|
||||
script into an applet, a standalone application. Actually,
|
||||
"standalone" is probably not the correct term here, since an applet
|
||||
does still depend on a lot of the python environment: the PythonCore
|
||||
shared library, the Python Preferences file, the python Lib folder and
|
||||
any other modules that the main module depends on. It is possible to
|
||||
get rid of all these dependencies except for the dependency on
|
||||
PythonCore, but at the moment that is still quite difficult so we will
|
||||
ignore that possibility for now. By standalone we mean here that the
|
||||
script has the look-and-feel of an application, including the ability
|
||||
to have its own document types, be droppable, etc. <p>
|
||||
Now let us try to turn the python script into an applet, a standalone
|
||||
application. This will <em>not</em> work if you have the "classic 68k"
|
||||
Python distribution, only if you have the cfm68k or PPC distribution.
|
||||
Actually, "standalone" is probably not the correct term here, since an
|
||||
applet does still depend on a lot of the python environment: the
|
||||
PythonCore shared library, the Python Preferences file, the python Lib
|
||||
folder and any other modules that the main module depends on. It is
|
||||
possible to get rid of all these dependencies except for the dependency
|
||||
on PythonCore, but at the moment that is still quite difficult so we
|
||||
will ignore that possibility for now. By standalone we mean here that
|
||||
the script has the look-and-feel of an application, including the
|
||||
ability to have its own document types, be droppable, etc. <p>
|
||||
|
||||
The easiest way to create an applet is to take your source file and
|
||||
drop it onto "mkapplet" (normally located in the Python home
|
||||
folder). This will create an applet with the same name as your python
|
||||
drop it onto "BuildApplet", located in the Python home
|
||||
folder. This will create an applet with the same name as your python
|
||||
source with the ".py" stripped. Also, if a resource file with the same
|
||||
name as your source but with ".rsrc" extension is available the
|
||||
resources from that file will be copied to your applet too. If there
|
||||
is no resource file for your script a set of default resources will be
|
||||
used, and the applet will have the default creator 'PYTa'. The latter
|
||||
used, and the applet will have the default creator 'Pyt0'. The latter
|
||||
also happens if you do have a resource file but without the BNDL
|
||||
combo. <A NAME="no-bundle">Actually</A>, for our example that would
|
||||
have been the most logical solution, since our applet does not have
|
||||
|
|
@ -164,8 +162,8 @@ having the custom icon, but that could have been done by pasting an
|
|||
icon on the finder Info window, or by providing an custon icon in your
|
||||
resource file and setting the "custom icon" finder bit. <p>
|
||||
|
||||
If you need slightly more control over the mkapplet process you can
|
||||
double-click mkapplet, and you will get dialogs for source and
|
||||
If you need slightly more control over the BuildApplet process you can
|
||||
double-click it, and you will get dialogs for source and
|
||||
destination of the applet. The rest of the process, including locating
|
||||
the resource file, remains the same. <p>
|
||||
|
||||
|
|
|
|||
|
|
@ -19,26 +19,17 @@ HREF="http://www-acs.ucsd.edu/~jstrout/python/">
|
|||
http://www-acs.ucsd.edu/~jstrout/python/</A>.
|
||||
<P>
|
||||
|
||||
The <a href="http://www.python.org/doc/lib/Top.html">Python Library Reference</a> contains a section on
|
||||
<a href="http://www.python.org/doc/lib/Macintosh-Specific-Services.html">Macintosh-specific modules</a>
|
||||
that you should also read. Documentation is also available in PostScript and other
|
||||
forms, see the <a href="http://www.python.org/doc/">documentation</a> section
|
||||
on the webserver. <p>
|
||||
The <a href="http://www.python.org/doc/lib/Top.html">Python Library
|
||||
Reference</a> contains a section on <a
|
||||
href="http://www.python.org/doc/lib/Macintosh-Specific-Services.html">Macintosh-specific
|
||||
modules</a> that you should also read. Documentation is also available
|
||||
in PostScript and other forms, see the <a
|
||||
href="http://www.python.org/doc/">documentation</a> section on the
|
||||
webserver. <p>
|
||||
|
||||
Some of these documents were actually written while I was working on a "real"
|
||||
project: creating a single-button application that will allow my
|
||||
girlfriend to read her mail (which actually pass thry <EM>my</EM>
|
||||
mailbox, so I get to read it too, but don't tell her:-) without her
|
||||
having to worry about internet connections, unix commands, etc. The
|
||||
application, when finished, will connect to the net using InterSLIP,
|
||||
start a (pseudo-)POP server on unix using rsh and use AppleScript to
|
||||
tell Eudora to connect to that server and retrieve messages. <p>
|
||||
Some of these documents were actually written a long time ago and have seen
|
||||
little maintainance, so use with care. <p>
|
||||
|
||||
These examples were all built using Python 1.3.3, which can be downloaded
|
||||
from <a href="ftp://ftp.cwi.nl/pub/jack/python/mac">ftp.cwi.nl, directory
|
||||
/pub/jack/python/mac</a>, and possibly from the <a href="ftp://ftp.python/org">
|
||||
ftp.python.org</a> server and its mirrors as well. Some examples may work
|
||||
with earlier versions of Python, some will definitely not.
|
||||
<H2>Table of contents</H2>
|
||||
|
||||
<UL>
|
||||
|
|
@ -133,5 +124,5 @@ documentation. <p>
|
|||
|
||||
<HR>
|
||||
<A HREF="http://www.cwi.nl/~jack">Jack Jansen</A>,
|
||||
<A HREF="mailto:jack@cwi.nl">jack@cwi.nl</A>, 09-September-1996.
|
||||
<A HREF="mailto:jack@cwi.nl">jack@cwi.nl</A>, 27-Aug-97.
|
||||
</BODY></HTML>
|
||||
|
|
|
|||
|
|
@ -22,21 +22,19 @@ 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 a <A HREF="http://www.python.org/python/Sources.html">python
|
||||
source distribution</A>. There is a <A
|
||||
HREF="update-to-1.3/into-PlugIns.hqx"> fixed project template</A> that
|
||||
you also need if you are going to make a dynamically loaded
|
||||
module. For PowerPC development you can actually get by without a full
|
||||
source distribution, using the PPC Development distribution (if I have
|
||||
gotten around to putting it together by the time you read
|
||||
this). You'll also need a functional python interpreter, and the
|
||||
Modulator program (which lives in <CODE>Tools:Modulator</CODE> in the
|
||||
standard source distribution). You may also find that Guido's <A
|
||||
Next, you need a <A
|
||||
HREF="http://www.python.org/python/Sources.html">python source
|
||||
distribution</A>. For PowerPC and cfm68k development you can actually
|
||||
get by without a full source distribution, using the Development
|
||||
distribution (if I have gotten around to putting it together by the time
|
||||
you read this). You'll also need a functional python interpreter, and
|
||||
the Modulator program (which lives in <CODE>Tools:Modulator</CODE> in
|
||||
the standard source distribution). 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>
|
||||
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>
|
||||
|
||||
|
|
@ -95,11 +93,8 @@ 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>
|
||||
|
||||
On systems with the Tk windowing API for Python (currently only
|
||||
unix/X11 systems, but mac support may be available when you read this)
|
||||
this is extremely simple. It is actually so simple that it pays to
|
||||
create the skeleton module under unix and ship the code to your
|
||||
mac. You start modulator and are provided with a form in which you
|
||||
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>
|
||||
|
|
@ -161,7 +156,7 @@ 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>Adding a module to 68K Python</H2>
|
||||
<H2>Adding a module to Classic 68K Python</H2>
|
||||
|
||||
What you do now depends on whether you're developing for PowerPC (or
|
||||
for CFM68K) or for "traditional" mac. For a traditional 68K Python,
|
||||
|
|
@ -206,18 +201,16 @@ your projects will all be smaller). Moreover, you can distribute a
|
|||
plugin module by itself without haveing to distribute a complete
|
||||
python interpreter. <p>
|
||||
|
||||
Go to the "PlugIns" folder and copy the files xxmodule.µ,
|
||||
xxmodule_config.h and xxmodule.µ.exp to interslipmodule.µ,
|
||||
interslipmodule_config.h and interslipmodule.µ.exp, respectively. Edit
|
||||
interslipmodule.µ.exp and change the name of the exported routine
|
||||
"initxx" to "initinterslip". Open interslipmodule.µ with CodeWarrior,
|
||||
Go to the "PlugIns" folder and copy the files xx.prj,
|
||||
and xx.prj.exp to interslipmodule.prj and
|
||||
interslipmodule.prj.exp, respectively. Edit
|
||||
interslipmodule.prj.exp and change the name of the exported routine
|
||||
"initxx" to "initinterslip". Open interslipmodule.prj with CodeWarrior,
|
||||
remove the file xxmodule.c and add interslipmodule.c and make a number
|
||||
of adjustments to the preferences:
|
||||
<UL>
|
||||
<LI> in C/C++ language, set the header file to interslipmodule_config.h
|
||||
<LI> in PPC linker, set the entry point to "initinterslip"
|
||||
<LI> in PPC PEF, set the fragment name to "interslipmodule"
|
||||
<LI> in PPC Project, set the output file name to "interslipmodule.slb".
|
||||
<LI> in PPC target, set the output file name to "interslipmodule.pcc.slb",
|
||||
<LI> in cfm68k target set the output file name to "interslipmodule.cfm68k.slb".
|
||||
</UL>
|
||||
Next, compile and link your module, fire up python and do the same
|
||||
tests as for 68K python. <p>
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Using Python 1.4 on the Macintosh</TITLE>
|
||||
<TITLE>Using Python 1.5 on the Macintosh</TITLE>
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<H1>Using Python 1.4 on the Macintosh</H1>
|
||||
<H1>Using Python 1.5 on the Macintosh</H1>
|
||||
<HR>
|
||||
|
||||
This document is an introduction to using Python on the Apple
|
||||
|
|
@ -42,8 +42,8 @@ interpreter in interactive mode by double-clicking its icon: <p>
|
|||
This should give you a text window with an informative version string
|
||||
and a prompt, something like the following:
|
||||
<PRE>
|
||||
Python 1.4 (Oct 27 1996) [CW PPC w/GUSI]
|
||||
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
|
||||
Python 1.5 (#0 Aug 27, 1997) [CW PPC w/GUSI MSL]
|
||||
Copyright 1991-1997 Stichting Mathematisch Centrum, Amsterdam
|
||||
>>>
|
||||
</PRE>
|
||||
The version string tells you the version of Python, whether it was
|
||||
|
|
@ -189,6 +189,8 @@ The options modify the interpreters behaviour in the following way:
|
|||
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.
|
||||
|
|
@ -279,9 +281,9 @@ 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 python this is a standalone
|
||||
<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>Scripts</CODE> folder. <p>
|
||||
script in the <CODE>Mac:Scripts</CODE> folder. <p>
|
||||
|
||||
The interface to edit the preferences is rather clunky for the current
|
||||
release. <p>
|
||||
|
|
@ -310,8 +312,8 @@ 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>mkapplet</CODE> program. You create an
|
||||
applet by dropping the python source script onto mkapplet.
|
||||
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>
|
||||
|
||||
|
|
@ -320,7 +322,7 @@ 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 (of the same release and architecture) will work. <p>
|
||||
have a Python system will work. <p>
|
||||
|
||||
<h2>Customizing applets</h2>
|
||||
|
||||
|
|
@ -394,10 +396,11 @@ 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 examine <code>sys.path</code>.
|
||||
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. <p>
|
||||
Python folder</em>. This will regenerate the preferences file. You may also
|
||||
have to run the ConfigurePython applet again. <p>
|
||||
|
||||
<h2>Where to go from here</h2>
|
||||
|
||||
|
|
@ -405,7 +408,7 @@ The next section to check out is the <a href="index.html">annotated sample progr
|
|||
|
||||
<HR>
|
||||
<A HREF="http://www.cwi.nl/~jack">Jack Jansen</A>,
|
||||
<A HREF="mailto:jack@cwi.nl">jack@cwi.nl</A>, 20-Nov-1996.
|
||||
<A HREF="mailto:jack@cwi.nl">jack@cwi.nl</A>, 27-Aug-1997.
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
|
|||
Loading…
Reference in New Issue