4th October 2007
Firstly, if you're looking for heat-resistant materials to use in the viewing ports of your summer station in the Venusian highlands, you have come to the wrong place. This article doesn't deal with glass kitchenware of any kind, but with the extension language for Python written by Greg Ewing and friends, called Pyrex, and the problem of using it in a Windows environment.
Also, a disclaimer aimed at linux sorcerers, python conjurers, windog necromancers and any other enchanters reading this: I am merely a good-willed apprentice, dabbling at minor cantrips and learning from counsel and experience. Expect no deep mysteries unveiled, no great spells explained here; this is but a simple account of some of my experiments. If you feel you can comment on them and thus add to their significance, please contact this humble writer.
Regarding the origins of this whole experience, suffice it to say that while working on an open-source artificial life project, I ran into the need of optimising a cellular automaton engine written in Python. While an obvious course of action was to rewrite the library in C++ (and this was eventually done), I preferred to use Pyrex instead, in order to maintain the high-level syntax of the original code and simultaneously gain access to more efficient use of memory and processor. More information about this yet unfinished story may be found in the website of Project Ouroborus.
You may possibly wonder as to the motivation lying behind this attempt at combining the Pyrex extension language with the MinGW library for Windows. A Windows installer can be readily downloaded from the official Pyrex website, and after running it Pyrex will work fine, whithout further ado, compiling extensions for Python in C using any local installation of Microsoft Visual Studio. I tend to feel reticent, however, to pursue development of open-source code in an environment so dependent on Microsoft's official compiler. I full well realise that hacking on the Empire's platform will never reach the high levels of freedom and interoperability which one may find in entirely free systems such as Debian, yet it does not logically ensue from this that there's no point in even trying. There is evident merit in joining the ranks of freedom fighters who exclusively use open-source platforms like Linux or BSD for development, and these enclaves may well be the idealistic seeds from which a New Repulblic will one day spring forth in a flourish of self-righteous greenery. Yet, I maintain it is equally valid, and perhaps even bolder in some ways, to do battle from within - facing the continuous menace of DLL hell, the ominous shadow of zero backwards compatibility looming overhead every time a new minor sub-version of Visual Studio sees the light of day, and the general derision from the legions of microserfs and hordes of bounty hunter code-peddlers - constantly fighting to bring the actual experience of free software, not only as passive users but even as active developers, closer to the general public living under the tyrannical grip of the dark lords of proprietary programming.
When faced with the issue of setting up that paragon of free compilers, gcc, in a windog box, there are, to the best of my knowledge, two courses of action which one may follow. That well-trodden path which respectable folk tend to use, cygwin, and that oddest of oddities close to many a wierdo's heart, MinGW (you may pronounce it as you please, but I suggest 'mingwee' both for compactness and for zest). While the advantages of cygwin are numerous, I still fail to see why someone would want to emulate a full UNIX environment within Windows rather than simply run a true Linux system. More importantly for my particular purposes, the overhead of the full cygwin environment is considerable, compared to the much slimmer MinGW library, and thus it does not lend itself so well to the purposes of code optimisation.
So far in my experimentation I have used the standard Python installation for Windows - version 2.5 at this date. Everything has proceeded well until now, even though I've heard dark rumours that a conflict between MinGW's C Runtime Library and the CRT linked by the Python binaries will eventually arise. If this is indeed the case, I will have to deal with it in the future. It appears that Python may now be built from source using MinGW, and this may be the obvious next step; however I will stick to the standard windog distribution as long as I can get away with it.
4th October 2007
MinGW stands for "Minimalist GNU for Windows" and is exactly that, a minimal subset of the GNU range of applications, magicked to run in a windog environment.
MinGW comes with a Windows installer, with an infamous history, and a claim to having redeemed itself in recent times. I still opted to go for a manual installation of piecemeal packages, choosing the latest, experimental versions of each. All packages may be downloaded from MinGW's Sourceforge donwload site.
The process is extremely simple. I started by creating an appropriately named directory in my file system:
C:\MinGW
I downloaded the following packages from the Sourceforege site:
gcc-core-4.2.1-sjlj-2.tar.gzgcc-g++-4.2.1-sjlj-2.tar.gzbinutils-2.17.50-20060824-1.tar.gzmingw-runtime-3.13-20070825-1.tar.gzw32api-3.10.tar.gzmingw32-make-3.81-2.tar.gzmingw-utils-0.3.tar.gzgdb-6.6.tar.bz2mingw-gdb-6.6.patch.tar.bz2I then unpacked these straight into the C:\MinGW directory.
Almost there: I went into the C:\MinGW\bin subdirectory just created, and
removed the -sjlj suffix from the gcc.exe and
g++.exe filenames, for ease of
use.
Finally I added C:\MinGW\bin to the path environment variable.
It is not the case in my system, but I understand that if cygwin is also
installed and in the path environment variable, this may create a conflict
over which version of gcc to use.
To test whether the installation worked, open a Windows shell and invoke the compiler:
gcc --help
If Windows doesn't recognise gcc as a valid command, something has gone wrong!
After successfully installing MinGW, I still had to link gcc to my Python
installation as extension compiler. In order to do this, I created a file
distutils.cfg in directory C:\Python25\Lib\distutils
with the following code:
[build]
compiler = mingw32
4th October 2007
MSYS provides minimal POSIX functionality for MINGW, including a little, neat Bourne shell.
It is not necessary to install MSYS in order to run gcc, as Pyrex invokes it directly, but I find it is a nice add-on. The Windows executables work fine for installation and may be obtained, once again, from MinGW's Sourceforge donwload site.
Installation is completely straight forward; first download the relevant executable files, currently:
MSYS-1.0.10.exemsysDTK-1.0.1.exeMake sure you run the MSYS .exe first, and when the wizard asks for the
directory in which MinGW is installed, answer appropriately... in my case,
C:\MinGW
Then run the MSYS DTK installer, and if everything went fine you should be able to start the MSYS shell from the Windows Start menu.
4th October 2007
Pyrex is a compiled language with a Pythonic syntax, which allows you to use C data types, allowing for easy optimisation of Python code; thus it is well suited for writing compiled binary libraries easily linked from Python modules.
There is a finely crafted Pyrex installer for Windows crafted by Giovanni
Bajo, which can be found at the Pyrex website. The installer
for the current version is called Pyrex-0.9.3.1.win32.exe, and
running it is all you need to do in order to get Pyrex running on Windows.
4th October 2007
Instructions for compiling a test Pyrex library can be found elsewhere, but for completeness' sake, here we go again:
This is a sample of trivial Pyrex code, identical to Python in all respects,
except that I saved it in a source file called ding.pyx:
def dong():
print "O brave new world, that hath such people on't!"
return
Now, to compile this Pyrex code I need to save the following Python script
in the same directory, as setup.py:
from distutils.core import setup
from distutils.extension import Extension
from Pyrex.Distutils import build_ext
setup(
name = "ding",
ext_modules=[
Extension("ding", ["ding.pyx"])
],
cmdclass = {'build_ext': build_ext}
)
Now, to work a small spark of magic, I can open a Windows shell and move to the same directory where I saved the Pyrex source, and run the Python script with the following flags:
python setup.py build_ext --inplace
This will result in a whole lot of warnings which can be safely ignored, plus
a new source file in C, translated by Pyrex and not human-readable, called
ding.c, a build subdirectory with funny stuff which
Pyrex needed along the way and which may now be deleted, plus a binary .pyd
library which is now callable from Python. To test it, I would invoke Python
in the same Windows shell as before, and once the interpreter is running
enter the following:
import ding
ding.dong()
This should result in a pretty quote from Shakespeare's final play (unless you count the unfinished Henry VIII.
A final trinket. Say I want to place the .pyd library directly in the
site-packages subdirectory of my Python installation, rather
than in a working directory as before. Then I would have to slightly modify
my Pyrex call as follows:
python setup.py build_ext install
Now I should be able to import the ding module no matter where
I happen to be running Python from - the Python IDLE GUI for instance. The
.c source and build subdirectory will still be created in my
working directory, but ding.pyd will manifest right snugly in
the site-packages subdirectory.
4th October 2007
Some related material: