John Szakmeister added the comment:
FWIW, I'm seeing the same issue as Jason too, and his solution seems reasonable
to me.
--
nosy: +jszakmeister
___
Python tracker
<http://bugs.python.org/is
John Szakmeister added the comment:
Thank you Ned! The issue is that you can create symlinks to ccache to and put
them on your path. Distros do this for you now, but most create symlinks for a
bunch of compilers... including ones that may not be installed. So the
presence of the name (
John Szakmeister added the comment:
Here's the alternate fix.
--
Added file:
http://bugs.python.org/file34973/alt-fix-osx-llvm-detection-with-ccache.patch
___
Python tracker
<http://bugs.python.org/is
New submission from John Szakmeister:
It's pretty typical for ccache packages to install symlinks for compilers that
may not be present on the system, such as Homebrew's ccache package.
Unfortunately, the _osx_support.py file is mislead by the presence of the
symlink and ends up b
John Szakmeister added the comment:
Actually, Trent's version looks at hw.logicalcpu and then falls back to
hw.ncpu, if there was an error. Given the state of the documentation on these
parameters, it's hard to say whether it's right or wrong, but at least
hw.logicalcpu scales
John Szakmeister added the comment:
Ronald: it is mentioned in some books (a Google search can turn them up), but
they don't really offer much description behind the intent. When I looked into
this several years ago, it was very unclear what `hw.activecpu` was intended
for. It sounded
New submission from John Szakmeister:
While trying to test a fix for Nose, I discovered that multiprocessing is
picking up the CPU count incorrectly. It should be using hw.availcpu instead
of hw.ncpu. The latter is the number of cpus installed in the system, but the
former is the number
John Szakmeister added the comment:
Good grief... how did I miss that. The problem has been flaky for me to
induce. I'll take a closer look at the correct section. Thank you Richard.
--
___
Python tracker
<http://bugs.python.org/is
New submission from John Szakmeister:
I discovered this issue while trying to track down why our upcoming release for
Nose 1.3.0 was deadlocking under Ubuntu 12.04 with Python 3.3. It turns out
that the read() was being interrupted leaving data in the subprocess's output
buffers,
John Szakmeister added the comment:
I'm gonna close this. It was meant to help port some of the Unladen Swallow
stuff... but I see that's effectively dead. :-(
--
resolution: -> invalid
status: open -> closed
___
Pytho
John Szakmeister added the comment:
Looks like this should've been done against the py3k branch instead. Looking
at py3k, it's changed quite a bit since the last merge into py3k-jit.
Perhaps there is a better way to do this under py3k? Or it's
New submission from John Szakmeister :
This is a port of r301 from unladen swallow to the py3k-jit branch.
On the Mac, there was an extra '-framework CoreFoundation' that was being
passed in python3 (maybe it wasn't there in Python 2.x?). At any rate, I
changed the logic to
John Szakmeister added the comment:
This one is my fault. I have a .pydistutils.cfg that was causing them to be
installed somewhere else or not at all. :-( Moving my custom config out of the
way, I'm good. I'm not sure what's happening there, but that's
John Szakmeister added the comment:
Attached the output.
--
Added file: http://bugs.python.org/file20775/make-install-output.txt
___
Python tracker
<http://bugs.python.org/issue11
John Szakmeister added the comment:
I'm installing into an area that I own ($HOME/.local/python3), so no need for
sudo. I just ran make install.
--
___
Python tracker
<http://bugs.python.org/is
John Szakmeister added the comment:
Looks like the time module is being built:
./build/lib.macosx-10.4-x86_64-3.2/time.so
But none of the shared modules are being installed, as
lib/python3.2/lib-dynload is completely empty.
--
___
Python
John Szakmeister added the comment:
The patch definitely helps. However, once I get it installed, there seems to
be no time module:
>>> import time
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named time
So I think the
John Szakmeister added the comment:
MACOSX_DEPLOYMENT_TARGET=10.5 made no bit of difference for me. Steffen, I
take it that it didn't help you either? You said "did well", but the rest of
your text indicates otherwise. :-)
--
___
John Szakmeister added the comment:
Interesting. I don't see a Mac/Makefile. Perhaps it's only pulled in with the
framework build?
--
___
Python tracker
<http://bugs.python.o
John Szakmeister added the comment:
Here is the top-level Makefile.
--
Added file: http://bugs.python.org/file20768/Makefile
___
Python tracker
<http://bugs.python.org/issue11
New submission from John Szakmeister :
I configured the build:
./configure --with-system-ffi --enable-shared --with-computed-gotos
--prefix=$HOME/.local/python3
Ran make with 4 jobs (make -j4), and got:
make: *** No rule to make target `libpython3.2m.dylib', needed by
`pytho
John Szakmeister added the comment:
I think Ronald is trying to say that a 10.6 SDK is likely not to support
building 64-bit binaries at all for the PPC (since there won't be 64-bit
versions of the supporting libraries). So you need this patch, if
you're going to build against it
John Szakmeister added the comment:
The offending lines in io.py are:
modes = set(mode)
if modes - set("arwb+tU") or len(mode) > len(modes):
raise ValueError("invalid mode: %r" % mode)
In particular, the "or len(mode) > len(modes)" is
John Szakmeister added the comment:
Actually, what's the second example trying to show:
try:
foo = opne("file") # will be changed to "open" as soon as we run it
except IOError:
sys.exit("could not open file")
I'm
John Szakmeister added the comment:
That'll teach me to pay more attention before submitting a patch.
Thanks Ezio!
--
___
Python tracker
<http://bugs.python.org/i
John Szakmeister added the comment:
Here's a patch for trunk.
--
keywords: +patch
nosy: +jszakmeister
Added file: http://bugs.python.org/file14203/issue-6220-doanddont.patch
___
Python tracker
<http://bugs.python.org/i
Changes by John Szakmeister :
--
nosy: +jszakmeister
___
Python tracker
<http://bugs.python.org/issue4618>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John Szakmeister :
--
nosy: +jszakmeister
___
Python tracker
<http://bugs.python.org/issue3329>
___
___
Python-bugs-list mailing list
Unsubscribe:
John Szakmeister added the comment:
On trunk, it seems that it's perfectly happy if you specify more than
one '+':
Python 2.7a0 (trunk, May 29 2009, 05:57:26)
[GCC 4.0.1 (Apple Inc. build 5470) (Aspen 5470.3)] on darwin
Type "help", "copyright", "cr
John Szakmeister added the comment:
It seems reasonable to prefer utimes() over utime() in all cases, when
utimes() is available, since utime() is considered obsolete. I've
attached a patch with the required change and ran all the tests. There
are some tests failing on trunk with my s
30 matches
Mail list logo
