I've been trying to install PIL 1.1.6 for several days now under Cygwin.
I have tried the Cygwin, Image and distutils lists with nary a pointer,
so I wondered whether python-dev might lead me to an answer (other than
"Stop using Cygwin" ;-)
Here's the output from a failed setup run with a couple of debug prints
inserted which should report how sub-process termination occurred - it
hangs after this output.
$ python setup.py build
building '_imaging' extension
SPAWN: ['gcc', '-fno-strict-aliasing', '-DNDEBUG', '-g', '-O3', '-Wall',
'-Wstrict-prototypes', '-DHAVE_LIBZ', '-IlibImaging', '-I/usr/include',
'-I/usr/include/python2.5', '-c', 'libImaging/Chops.c', '-o',
'build/temp.cygwin-1.5.24-i686-2.5/libImaging/Chops.o'] PATH? 1 V: 0 D:0
gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-DHAVE_LIBZ -IlibImaging -I/usr/include -I/usr/include/python2.5 -c
libImaging/Chops.c -o build/temp.cygwin-1.5.24-i686-2.5/libImaging/Chops.o
Are we done yet? Waiting on pid 3280
I have to kill a python.exe process that's left running in the
background if I CTRL/C the build. Otherwise it will spend all night in a
tight loop. The compilation is finished when I kill the process, and the
next compile will begin if I repeat the command.
I extracted the _spawn_all function from distutils/spawn.py, hacked some
exceptions and ran it under command line control.
That worked fine with other subtasks, so I wondered whether this was a
failure specific to gcc, which would seem kind of unlikely. I ran the
same compile using my test function standing alone, seeing success:
$ python ~/Projects/Python/spawntest.py gcc -fno-strict-aliasing
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -IlibImaging
-I/usr/include -I/usr/include/python2.5 -c libImaging/Chops.c -o
Are we done yet? Waiting on pid 3244
Got pid, status 3244 0
Got WIFEXITED 0
So it appears unlikely to be gcc-specific, leaving me wondering what
exactly is the difference between the build environment and my tests.
It would be really nice if test_distutils showed any failures, but it
doesn't so any assistance would be welcome. At this point I can't even
replicate the failure in a simpler test :-(
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------
Folklore that I remember so unreliably I avoid trying to repeat it here
held that Python threading had problems on BSD and allied Unixes. What's
the status of this? I suspect the answer is, "Everything works, and the
only real problem ever was that *signals* have different semantics under
Linux and *BSD." Anyone who can answer explicitly, though, would repre-
sent a help to me.
The Python Packaging Index (the software formerly known
as Cheeseshop) is now available at
The old addresses (www.python.org/pypi, and
cheeseshop.python.org/pypi) will continue to work,
either as aliases or using HTTP redirections.
The software was renamed to its old name
(PyPI - Python Package Index), as the Cheeseshop
name was ever confusing people unfamiliar with
British television comedy sketch (and puzzling
even to people familiar with the sketch, as
you *can* get packages from the package index).
If you would like to discuss PyPI and its future,
please join catalog-sig(a)python.org.
I am using python v2.5 and I am an amateur working on python. I am extending
python for my research work and would like some help and guidance w.r.t this
matter from you experienced python developers.
II want to add some more KEYWORDS and DATATYPES into the python script apart
from the existing ones.
It would be really great if anybody could guide me as which files and
modules I need to look to make these additions and enhancements to the
existing python version. Thanks a lot in advance and your help is really
PhD Grad Student.
We are what we repeatedly do. Excellence, then, is not an act but a habit. -
In PEP 9 there's a requirement that PEPs must follow the "emacs
convention" of 2 spaces after a period. (I didn't know this was an emacs
convention, I thought it was a convention of people who used typewriters.)
I've tried hard to maintain this textual convention in my own PEPs, even
though it's very unnatural to me. But I see from looking at the other
PEPs that that this convention is very inconsistently enforced - some
have it and some don't. Worse, I've had one person (who apparently
wasn't aware of the rule) flag my use of extra space after a period as a
bug in my PEP.
(When I first learned to type, I used one space after a period. Then
years later, someone convinced me that two spaces was the proper style
and so I switched to that for a few years. But later I switched back
because I realized that most modern typographical layout engines seem to
calculate inter-sentence spacing properly when the number of space
characters after a period is one. And in HTML [which is how most people
view PEPs anyway] it doesn't matter since the browser is going to filter
out the extra space anyway.)
So if we're not going to enforce the rule consistently (and it seems as
if we're not), can we then just remove it from PEP 9? I'm not saying
that we should change the rule to one space, I'm suggesting that we just
drop the requirement and let people use whatever they prefer.