Removed unintentional trailing spaces in text files.
This commit is contained in:
Serhiy Storchaka
parent
1770fde94c
commit
bfbfc8deb2
|
|
@ -117,7 +117,7 @@ dictorsetmaker: ( (test ':' test (comp_for | (',' test ':' test)* [','])) |
|
|||
classdef: 'class' NAME ['(' [arglist] ')'] ':' suite
|
||||
|
||||
arglist: (argument ',')* (argument [',']
|
||||
|'*' test (',' argument)* [',' '**' test]
|
||||
|'*' test (',' argument)* [',' '**' test]
|
||||
|'**' test)
|
||||
# The reason that keywords are test nodes instead of NAME is that using NAME
|
||||
# results in an ambiguity. ast.c makes sure it's a NAME.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ IDLEfork ChangeLog
|
|||
2001-07-19 14:49 elguavas
|
||||
|
||||
* ChangeLog, EditorWindow.py, INSTALLATION, NEWS.txt, README.txt,
|
||||
TODO.txt, idlever.py:
|
||||
TODO.txt, idlever.py:
|
||||
minor tidy-ups ready for 0.8.1 alpha tarball release
|
||||
|
||||
2001-07-17 15:12 kbk
|
||||
|
|
@ -172,7 +172,7 @@ IDLEfork ChangeLog
|
|||
all this work w/ a future-stmt just looks harder and harder."
|
||||
--tim_one
|
||||
|
||||
(From Rel 1.8: "Hack to make this still work with Python 1.5.2.
|
||||
(From Rel 1.8: "Hack to make this still work with Python 1.5.2.
|
||||
;-( " --fdrake)
|
||||
|
||||
2001-07-14 14:51 kbk
|
||||
|
|
@ -193,7 +193,7 @@ IDLEfork ChangeLog
|
|||
test() to _test()." --GvR
|
||||
|
||||
This was an interesting merge. The join completely missed removing
|
||||
goodname(), which was adjacent, but outside of, a small conflict.
|
||||
goodname(), which was adjacent, but outside of, a small conflict.
|
||||
I only caught it by comparing the 1.1.3.2/1.1.3.3 diff. CVS ain't
|
||||
infallible.
|
||||
|
||||
|
|
@ -516,12 +516,12 @@ IDLEfork ChangeLog
|
|||
|
||||
2000-08-15 22:51 nowonder
|
||||
|
||||
* IDLEFORK.html:
|
||||
* IDLEFORK.html:
|
||||
corrected email address
|
||||
|
||||
2000-08-15 22:47 nowonder
|
||||
|
||||
* IDLEFORK.html:
|
||||
* IDLEFORK.html:
|
||||
added .html file for http://idlefork.sourceforge.net
|
||||
|
||||
2000-08-15 11:13 dscherer
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ What's New in IDLEfork 0.8.1?
|
|||
*Release date: 22-Jul-2001*
|
||||
|
||||
- New tarball released as a result of the 'revitalisation' of the IDLEfork
|
||||
project.
|
||||
project.
|
||||
|
||||
- This release requires python 2.1 or better. Compatibility with earlier
|
||||
versions of python (especially ancient ones like 1.5x) is no longer a
|
||||
|
|
@ -26,8 +26,8 @@ What's New in IDLEfork 0.8.1?
|
|||
not working, but I believe this was the case with the previous IDLE fork
|
||||
release (0.7.1) as well.
|
||||
|
||||
- This release is being made now to mark the point at which IDLEfork is
|
||||
launching into a new stage of development.
|
||||
- This release is being made now to mark the point at which IDLEfork is
|
||||
launching into a new stage of development.
|
||||
|
||||
- IDLEfork CVS will now be branched to enable further development and
|
||||
exploration of the two "execution in a remote process" patches submitted by
|
||||
|
|
@ -96,7 +96,7 @@ IDLEfork 0.7.1 - 29 May 2000
|
|||
instead of the IDLE help; shift-TAB is now a synonym for unindent.
|
||||
|
||||
- New modules:
|
||||
|
||||
|
||||
ExecBinding.py Executes program through loader
|
||||
loader.py Bootstraps user program
|
||||
protocol.py RPC protocol
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ code objects from a top level viewpoint without dealing with code folding.
|
|||
There is a Python Shell window which features colorizing and command recall.
|
||||
|
||||
IDLE executes Python code in a separate process, which is restarted for each
|
||||
Run (F5) initiated from an editor window. The environment can also be
|
||||
Run (F5) initiated from an editor window. The environment can also be
|
||||
restarted from the Shell window without restarting IDLE.
|
||||
|
||||
This enhancement has often been requested, and is now finally available. The
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ dictsetmaker: ( (test ':' test (comp_for | (',' test ':' test)* [','])) |
|
|||
classdef: 'class' NAME ['(' [arglist] ')'] ':' suite
|
||||
|
||||
arglist: (argument ',')* (argument [',']
|
||||
|'*' test (',' argument)* [',' '**' test]
|
||||
|'*' test (',' argument)* [',' '**' test]
|
||||
|'**' test)
|
||||
argument: test [comp_for] | test '=' test # Really [keyword '='] test
|
||||
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@ Building a Python Mac OS X distribution
|
|||
=======================================
|
||||
|
||||
The ``build-install.py`` script creates Python distributions, including
|
||||
certain third-party libraries as necessary. It builds a complete
|
||||
framework-based Python out-of-tree, installs it in a funny place with
|
||||
$DESTROOT, massages that installation to remove .pyc files and such, creates
|
||||
an Installer package from the installation plus other files in ``resources``
|
||||
certain third-party libraries as necessary. It builds a complete
|
||||
framework-based Python out-of-tree, installs it in a funny place with
|
||||
$DESTROOT, massages that installation to remove .pyc files and such, creates
|
||||
an Installer package from the installation plus other files in ``resources``
|
||||
and ``scripts`` and placed that on a ``.dmg`` disk image.
|
||||
|
||||
For Python 3.4.0, PSF practice is to build two installer variants
|
||||
|
|
@ -101,7 +101,7 @@ for each release.
|
|||
/usr/bin/python build-installer.py \
|
||||
--sdk-path=/Developer/SDKs/MacOSX10.4u.sdk \
|
||||
--universal-archs=32-bit \
|
||||
--dep-target=10.3
|
||||
--dep-target=10.3
|
||||
|
||||
- builds the following third-party libraries
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ for each release.
|
|||
- requires ActiveState ``Tcl/Tk 8.4`` (currently 8.4.20) to be installed for building
|
||||
|
||||
- recommended build environment:
|
||||
|
||||
|
||||
* Mac OS X 10.5.8 PPC or Intel
|
||||
* Xcode 3.1.4 (or later)
|
||||
* ``MacOSX10.4u`` SDK (later SDKs do not support PPC G3 processors)
|
||||
|
|
@ -174,7 +174,7 @@ Here are the steps you need to follow to build a Python installer:
|
|||
Building other universal installers
|
||||
...................................
|
||||
|
||||
It is also possible to build a 4-way universal installer that runs on
|
||||
It is also possible to build a 4-way universal installer that runs on
|
||||
OS X 10.5 Leopard or later::
|
||||
|
||||
/usr/bin/python /build-installer.py \
|
||||
|
|
@ -208,7 +208,7 @@ a PPC G4 system with OS X 10.5 and at least one Intel system running OS X
|
|||
|
||||
/usr/local/bin/pythonn.n -m test -w -u all,-largefile
|
||||
/usr/local/bin/pythonn.n-32 -m test -w -u all
|
||||
|
||||
|
||||
Certain tests will be skipped and some cause the interpreter to fail
|
||||
which will likely generate ``Python quit unexpectedly`` alert messages
|
||||
to be generated at several points during a test run. These are normal
|
||||
|
|
|
|||
14
Mac/README
14
Mac/README
|
|
@ -19,7 +19,7 @@ OS X specific arguments to configure
|
|||
|
||||
If this argument is specified the build will create a Python.framework rather
|
||||
than a traditional Unix install. See the section
|
||||
_`Building and using a framework-based Python on Mac OS X` for more
|
||||
_`Building and using a framework-based Python on Mac OS X` for more
|
||||
information on frameworks.
|
||||
|
||||
If the optional directory argument is specified the framework is installed
|
||||
|
|
@ -53,7 +53,7 @@ OS X specific arguments to configure
|
|||
|
||||
* ``--with-univeral-archs=VALUE``
|
||||
|
||||
Specify the kind of universal binary that should be created. This option is
|
||||
Specify the kind of universal binary that should be created. This option is
|
||||
only valid when ``--enable-universalsdk`` is specified. The default is
|
||||
``32-bit`` if a building with a SDK that supports PPC, otherwise defaults
|
||||
to ``intel``.
|
||||
|
|
@ -174,14 +174,14 @@ Building and using a framework-based Python on Mac OS X.
|
|||
--------------------------------------------------------------------------
|
||||
|
||||
The main reason is because you want to create GUI programs in Python. With the
|
||||
exception of X11/XDarwin-based GUI toolkits all GUI programs need to be run
|
||||
exception of X11/XDarwin-based GUI toolkits all GUI programs need to be run
|
||||
from a Mac OS X application bundle (".app").
|
||||
|
||||
While it is technically possible to create a .app without using frameworks you
|
||||
will have to do the work yourself if you really want this.
|
||||
|
||||
A second reason for using frameworks is that they put Python-related items in
|
||||
only two places: "/Library/Framework/Python.framework" and
|
||||
only two places: "/Library/Framework/Python.framework" and
|
||||
"/Applications/Python <VERSION>" where ``<VERSION>`` can be e.g. "3.4",
|
||||
"2.7", etc. This simplifies matters for users installing
|
||||
Python from a binary distribution if they want to get rid of it again. Moreover,
|
||||
|
|
@ -228,11 +228,11 @@ in the sequence
|
|||
1. ./configure --enable-framework
|
||||
|
||||
2. make
|
||||
|
||||
|
||||
3. make install
|
||||
|
||||
This sequence will put the framework in ``/Library/Framework/Python.framework``,
|
||||
the applications in ``/Applications/Python <VERSION>`` and the unix tools in
|
||||
the applications in ``/Applications/Python <VERSION>`` and the unix tools in
|
||||
``/usr/local/bin``.
|
||||
|
||||
Installing in another place, for instance ``$HOME/Library/Frameworks`` if you
|
||||
|
|
@ -300,7 +300,7 @@ All of this is normally done completely isolated in /tmp/_py, so it does not
|
|||
use your normal build directory nor does it install into /.
|
||||
|
||||
Because of the way the script locates the files it needs you have to run it
|
||||
from within the BuildScript directory. The script accepts a number of
|
||||
from within the BuildScript directory. The script accepts a number of
|
||||
command-line arguments, run it with --help for more information.
|
||||
|
||||
Configure warnings
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ And you'll need a config.c file, which lists the built-in modules you
|
|||
support. Start with Modules/config.c.in.
|
||||
|
||||
Finally, you'll run into some things that aren't supported on your
|
||||
target platform. Forget about the posix module for now -- simply take
|
||||
target platform. Forget about the posix module for now -- simply take
|
||||
it out of the config.c file.
|
||||
|
||||
Bang on it until you get a >>> prompt. (You may have to disable the
|
||||
|
|
|
|||
|
|
@ -150,10 +150,10 @@ end
|
|||
|
||||
# generally useful macro to print a Unicode string
|
||||
def pu
|
||||
set $uni = $arg0
|
||||
set $uni = $arg0
|
||||
set $i = 0
|
||||
while (*$uni && $i++<100)
|
||||
if (*$uni < 0x80)
|
||||
if (*$uni < 0x80)
|
||||
print *(char*)$uni++
|
||||
else
|
||||
print /x *(short*)$uni++
|
||||
|
|
|
|||
|
|
@ -266,7 +266,7 @@ sed -e 's/[ ]*#.*//' -e '/^[ ]*$/d' |
|
|||
*) sed -e "
|
||||
1i$NL/* Generated automatically from $config by makesetup. */
|
||||
/MARKER 1/i$NL$EXTDECLS
|
||||
|
||||
|
||||
/MARKER 2/i$NL$INITBITS
|
||||
|
||||
" $config >config.c
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Example Python extension for Windows NT
|
|||
|
||||
This directory contains everything needed (except for the Python
|
||||
distribution!) to build a Python extension module using Microsoft VC++.
|
||||
Notice that you need to use the same compiler version that was used to build
|
||||
Notice that you need to use the same compiler version that was used to build
|
||||
Python itself.
|
||||
|
||||
The simplest way to build this example is to use the distutils script
|
||||
|
|
@ -16,7 +16,7 @@ after everything builds and installs, you can test it:
|
|||
% python -c "import example; example.foo()"
|
||||
Hello, world
|
||||
|
||||
See setup.py for more details. alternatively, see below for instructions on
|
||||
See setup.py for more details. alternatively, see below for instructions on
|
||||
how to build inside the Visual Studio environment.
|
||||
|
||||
Visual Studio Build Instructions
|
||||
|
|
@ -27,8 +27,8 @@ instructions and project files have not been updated to the latest VC
|
|||
version. In general, it is recommended you use the 'setup.py' instructions
|
||||
above.
|
||||
|
||||
It has been tested with VC++ 7.1 on Python 2.4. You can also use earlier
|
||||
versions of VC to build Python extensions, but the sample VC project file
|
||||
It has been tested with VC++ 7.1 on Python 2.4. You can also use earlier
|
||||
versions of VC to build Python extensions, but the sample VC project file
|
||||
(example.dsw in this directory) is in VC 7.1 format.
|
||||
|
||||
COPY THIS DIRECTORY!
|
||||
|
|
@ -129,7 +129,7 @@ created a new project yourself, add the file spam.def to the project now.
|
|||
(This is an annoying little file with only two lines. An alternative
|
||||
approach is to forget about the .def file, and add the option
|
||||
"/export:initspam" somewhere to the Link settings, by manually editing the
|
||||
"Project -> Properties -> Linker -> Command Line -> Additional Options"
|
||||
"Project -> Properties -> Linker -> Command Line -> Additional Options"
|
||||
box).
|
||||
|
||||
You are now all set to build your extension, unless it requires other
|
||||
|
|
@ -142,13 +142,13 @@ CREATING A BRAND NEW PROJECT
|
|||
Use the
|
||||
File -> New -> Project...
|
||||
dialog to create a new Project Workspace. Select "Visual C++ Projects/Win32/
|
||||
Win32 Project", enter the name ("spam"), and make sure the "Location" is
|
||||
set to parent of the spam directory you have created (which should be a direct
|
||||
subdirectory of the Python build tree, a sibling of Include and PC).
|
||||
Win32 Project", enter the name ("spam"), and make sure the "Location" is
|
||||
set to parent of the spam directory you have created (which should be a direct
|
||||
subdirectory of the Python build tree, a sibling of Include and PC).
|
||||
In "Application Settings", select "DLL", and "Empty Project". Click OK.
|
||||
|
||||
You should now create the file spam.def as instructed in the previous
|
||||
section. Add the source files (including the .def file) to the project,
|
||||
section. Add the source files (including the .def file) to the project,
|
||||
using "Project", "Add Existing Item".
|
||||
|
||||
Now open the
|
||||
|
|
@ -174,7 +174,7 @@ list in the "Additional Dependencies" box.
|
|||
|
||||
Select "Debug" in the "Settings for:" dropdown list, and append
|
||||
"python24_d.lib" to the list in the Additional Dependencies" box. Then
|
||||
click on the C/C++ tab, select "Code Generation", and select
|
||||
click on the C/C++ tab, select "Code Generation", and select
|
||||
"Multi-threaded Debug DLL" from the "Runtime library" dropdown list.
|
||||
|
||||
Select "Release" again from the "Settings for:" dropdown list.
|
||||
|
|
|
|||
|
|
@ -100,8 +100,8 @@ to place the Tcl and Tk library files in the distributed setup, and
|
|||
then declare these directories in your frozen Python program using
|
||||
the TCL_LIBRARY, TK_LIBRARY and TIX_LIBRARY environment variables.
|
||||
|
||||
For example, assume you will ship your frozen program in the directory
|
||||
<root>/bin/windows-x86 and will place your Tcl library files
|
||||
For example, assume you will ship your frozen program in the directory
|
||||
<root>/bin/windows-x86 and will place your Tcl library files
|
||||
in <root>/lib/tcl8.2 and your Tk library files in <root>/lib/tk8.2. Then
|
||||
placing the following lines in your frozen Python script before importing
|
||||
Tkinter or Tix would set the environment correctly for Tcl/Tk/Tix:
|
||||
|
|
@ -138,8 +138,8 @@ variable PATH is consulted, and under Unix, it may be the
|
|||
environment variable LD_LIBRARY_PATH and/or the system
|
||||
shared library cache (ld.so). An additional preferred directory for
|
||||
finding the dynamic libraries is built into the .dll or .so files at
|
||||
compile time - see the LIB_RUNTIME_DIR variable in the Tcl makefile.
|
||||
The OS must find the dynamic libraries or your frozen program won't start.
|
||||
compile time - see the LIB_RUNTIME_DIR variable in the Tcl makefile.
|
||||
The OS must find the dynamic libraries or your frozen program won't start.
|
||||
Usually I make sure that the .so or .dll files are in the same directory
|
||||
as the executable, but this may not be foolproof.
|
||||
|
||||
|
|
@ -149,8 +149,8 @@ incorporated in a frozen Python module as string literals and written
|
|||
to a temporary location when the program runs; this is currently left
|
||||
as an exercise for the reader. An easier approach is to freeze the
|
||||
Tcl/Tk/Tix code into the dynamic libraries using the Tcl ET code,
|
||||
or the Tix Stand-Alone-Module code. Of course, you can also simply
|
||||
require that Tcl/Tk is required on the target installation, but be
|
||||
or the Tix Stand-Alone-Module code. Of course, you can also simply
|
||||
require that Tcl/Tk is required on the target installation, but be
|
||||
careful that the version corresponds.
|
||||
|
||||
There are some caveats using frozen Tkinter applications:
|
||||
|
|
@ -164,7 +164,7 @@ program was frozen, not where it is run from.
|
|||
A warning about shared library modules
|
||||
--------------------------------------
|
||||
|
||||
When your Python installation uses shared library modules such as
|
||||
When your Python installation uses shared library modules such as
|
||||
_tkinter.pyd, these will not be incorporated in the frozen program.
|
||||
Again, the frozen program will work when you test it, but it won't
|
||||
work when you ship it to a site without a Python installation.
|
||||
|
|
@ -275,9 +275,9 @@ Options:
|
|||
are read and the -i option replaced with the parsed
|
||||
params (note - quoting args in this file is NOT supported)
|
||||
|
||||
-s subsystem: Specify the subsystem (For Windows only.);
|
||||
-s subsystem: Specify the subsystem (For Windows only.);
|
||||
'console' (default), 'windows', 'service' or 'com_dll'
|
||||
|
||||
|
||||
-w: Toggle Windows (NT or 95) behavior.
|
||||
(For debugging only -- on a win32 platform, win32 behavior
|
||||
is automatic.)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ PYBENCH - A Python Benchmark Suite
|
|||
________________________________________________________________________
|
||||
|
||||
Extendable suite of low-level benchmarks for measuring
|
||||
the performance of the Python implementation
|
||||
the performance of the Python implementation
|
||||
(interpreter, compiler or VM).
|
||||
|
||||
pybench is a collection of tests that provides a standardized way to
|
||||
|
|
@ -34,11 +34,11 @@ to have it store the results in a file too.
|
|||
|
||||
It is usually a good idea to run pybench.py multiple times to see
|
||||
whether the environment, timers and benchmark run-times are suitable
|
||||
for doing benchmark tests.
|
||||
for doing benchmark tests.
|
||||
|
||||
You can use the comparison feature of pybench.py ('pybench.py -c
|
||||
<file>') to check how well the system behaves in comparison to a
|
||||
reference run.
|
||||
reference run.
|
||||
|
||||
If the differences are well below 10% for each test, then you have a
|
||||
system that is good for doing benchmark testings. Of you get random
|
||||
|
|
@ -232,7 +232,7 @@ class IntegerCounting(Test):
|
|||
# for comparisons of benchmark runs - tests with unequal version
|
||||
# number will not get compared.
|
||||
version = 1.0
|
||||
|
||||
|
||||
# The number of abstract operations done in each round of the
|
||||
# test. An operation is the basic unit of what you want to
|
||||
# measure. The benchmark will output the amount of run-time per
|
||||
|
|
@ -264,7 +264,7 @@ class IntegerCounting(Test):
|
|||
|
||||
# Repeat the operations per round to raise the run-time
|
||||
# per operation significantly above the noise level of the
|
||||
# for-loop overhead.
|
||||
# for-loop overhead.
|
||||
|
||||
# Execute 20 operations (a += 1):
|
||||
a += 1
|
||||
|
|
@ -358,8 +358,8 @@ Version History
|
|||
- changed the output format a bit to make it look
|
||||
nicer
|
||||
- refactored the APIs somewhat
|
||||
1.3+: Steve Holden added the NewInstances test and the filtering
|
||||
option during the NeedForSpeed sprint; this also triggered a long
|
||||
1.3+: Steve Holden added the NewInstances test and the filtering
|
||||
option during the NeedForSpeed sprint; this also triggered a long
|
||||
discussion on how to improve benchmark timing and finally
|
||||
resulted in the release of 2.0
|
||||
1.3: initial checkin into the Python SVN repository
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Running Standalone
|
|||
|
||||
--initfile file
|
||||
-i file
|
||||
Alternate location of the persistent initialization file. See
|
||||
Alternate location of the persistent initialization file. See
|
||||
the section on Persistency below.
|
||||
|
||||
--ignore
|
||||
|
|
@ -80,7 +80,7 @@ Running as a Modal Dialog
|
|||
|
||||
pyColorChooser.askcolor()
|
||||
|
||||
which will popup Pynche as a modal dialog, and return the selected
|
||||
which will popup Pynche as a modal dialog, and return the selected
|
||||
color.
|
||||
|
||||
There are some UI differences when running as a modal
|
||||
|
|
@ -106,7 +106,7 @@ Running as a Modal Dialog
|
|||
|
||||
master[*]
|
||||
the master window to use as the parent of the modal
|
||||
dialog. Without this argument, pyColorChooser will create
|
||||
dialog. Without this argument, pyColorChooser will create
|
||||
its own Tkinter.Tk instance as the master. This may not
|
||||
be what you want.
|
||||
|
||||
|
|
@ -170,7 +170,7 @@ The Proof Window
|
|||
Selected chip color exactly matches the Nearest chip color, you
|
||||
will see the color name appear below the color specification for
|
||||
the Selected chip.
|
||||
|
||||
|
||||
Clicking on the Nearest color chip selects that color. Color
|
||||
distance is calculated in the 3D space of the RGB color solid and
|
||||
if more than one color name is the same distance from the selected
|
||||
|
|
@ -361,7 +361,7 @@ Color Name Database Files
|
|||
format for both values and names
|
||||
|
||||
webcolors.txt -- The 140 color names that Tim Peters and his
|
||||
sister say NS and MSIE both understand (with some controversy over
|
||||
sister say NS and MSIE both understand (with some controversy over
|
||||
AliceBlue).
|
||||
|
||||
namedcolors.txt -- an alternative set of Netscape colors.
|
||||
|
|
@ -369,8 +369,8 @@ Color Name Database Files
|
|||
You can switch between files by choosing "Load palette..." from
|
||||
the "File" menu. This brings up a standard Tk file dialog.
|
||||
Choose the file you want and then click "Ok". If Pynche
|
||||
understands the format in this file, it will load the database and
|
||||
update the appropriate windows. If not, it will bring up an error
|
||||
understands the format in this file, it will load the database and
|
||||
update the appropriate windows. If not, it will bring up an error
|
||||
dialog.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
unittestgui.py is GUI framework and application for use with Python unit
|
||||
testing framework. It executes tests written using the framework provided
|
||||
unittestgui.py is GUI framework and application for use with Python unit
|
||||
testing framework. It executes tests written using the framework provided
|
||||
by the 'unittest' module.
|
||||
|
||||
Based on the original by Steve Purcell, from:
|
||||
|
|
|
|||
Loading…
Reference in New Issue