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 <rep...@bugs.python.org>
<http://bugs.python.org/i
Nose 1.3.3 fixes a simple issue with the reported version number.
Sorry for the back-to-back releases. Enjoy!
-John
--
https://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations/
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 backtracing
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 rep...@bugs.python.org
http://bugs.python.org/issue21311
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 ('gcc
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 correctly if I
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 more
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
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, which
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 rep...@bugs.python.org
http
John Szakmeister j...@szakmeister.net 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
___
Python tracker
New submission from John Szakmeister j...@szakmeister.net:
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
John Szakmeister j...@szakmeister.net 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 handled already
John Szakmeister j...@szakmeister.net 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 rep...@bugs.python.org
http://bugs.python.org/issue11222
John Szakmeister j...@szakmeister.net added the comment:
Attached the output.
--
Added file: http://bugs.python.org/file20775/make-install-output.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11222
John Szakmeister j...@szakmeister.net 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 a different
New submission from John Szakmeister j...@szakmeister.net:
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
John Szakmeister j...@szakmeister.net added the comment:
Here is the top-level Makefile.
--
Added file: http://bugs.python.org/file20768/Makefile
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11222
John Szakmeister j...@szakmeister.net added the comment:
Interesting. I don't see a Mac/Makefile. Perhaps it's only pulled in with the
framework build?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11222
John Szakmeister j...@szakmeister.net 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 j...@szakmeister.net 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 stdin, line 1, in module
ImportError: No module named time
So I think
John Szakmeister j...@szakmeister.net 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
John Szakmeister j...@szakmeister.net 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
John Szakmeister j...@szakmeister.net 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 picking off the fact
John Szakmeister j...@szakmeister.net 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 rep...@bugs.python.org
http
John Szakmeister j...@szakmeister.net added the comment:
That'll teach me to pay more attention before submitting a patch.
Thanks Ezio!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6220
John Szakmeister j...@szakmeister.net 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 not sure what that comment really means
John Szakmeister j...@szakmeister.net 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, credits or license for more
Changes by John Szakmeister j...@szakmeister.net:
--
nosy: +jszakmeister
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3329
___
___
Python-bugs
Changes by John Szakmeister j...@szakmeister.net:
--
nosy: +jszakmeister
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4618
___
___
Python-bugs
John Szakmeister j...@szakmeister.net 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
31 matches
Mail list logo
