[issue14574] SocketServer doesn't handle client disconnects properly
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/issue14574> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21311] Fix compiler detection when brew's ccache is installed on Mac OS X
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', for instance) doesn't mean that the compiler is actually installed. It could be a symlink to the ccache binary and running it could fail. I hope that makes a little more sense. Thanks again for applying the patch! -- ___ Python tracker <http://bugs.python.org/issue21311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21311] Fix compiler detection when brew's ccache is installed on Mac OS X
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/issue21311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21311] Fix compiler detection when brew's ccache is installed on Mac OS X
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. This issue is present in 2.7 and onwards. I'm attaching two possible fixes for the problem, both created against 2.7. The issue is that the symlink in detected, but _read_output() returns None, which then fails when the output is examined (if 'str' in None...). The first patch does a simple non-empty check. The alternate version makes _read_output() return an empty string instead of None. -- components: Distutils files: fix-osx-llvm-detection-with-ccache.patch keywords: patch messages: 216856 nosy: dstufft, eric.araujo, jszakmeister priority: normal severity: normal status: open title: Fix compiler detection when brew's ccache is installed on Mac OS X versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34972/fix-osx-llvm-detection-with-ccache.patch ___ Python tracker <http://bugs.python.org/issue21311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17444] multiprocessing.cpu_count() should use hw.availcpu on Mac OS X
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 disable some of the processors. -- ___ Python tracker <http://bugs.python.org/issue17444> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17444] multiprocessing.cpu_count() should use hw.availcpu on Mac OS X
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 like a report about how many processors are active, versus targetting your SMP aware application to that number. But since you've turned some information in sysctl.h, I think we should follow that advice and use hw.activecpu. I've attached a new patch with the change. -- Added file: http://bugs.python.org/file29442/use-activecpu.patch ___ Python tracker <http://bugs.python.org/issue17444> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17444] multiprocessing.cpu_count() should use hw.availcpu on Mac OS X
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 that are available for processing. The processor pane let's you adjust the available CPUs, which is handy for testing and troubleshooting. -- components: Library (Lib) files: use-availcpu.patch keywords: patch messages: 184367 nosy: jszakmeister priority: normal severity: normal status: open type: behavior Added file: http://bugs.python.org/file29430/use-availcpu.patch ___ Python tracker <http://bugs.python.org/issue17444> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17367] subprocess deadlock when read() is interrupted
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/issue17367> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17367] subprocess deadlock when read() is interrupted
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 ultimately means the subprocess is blocked. Since the thread was exiting, and the read was never retried, we were left in deadlock. The attached patch fixes the issue. It wraps the read call with _eintr_retry_call() around the read operation in _readerthread(). -- components: Library (Lib) files: fix-subprocess-deadlock.patch keywords: patch messages: 183584 nosy: jszakmeister priority: normal severity: normal status: open title: subprocess deadlock when read() is interrupted type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file29323/fix-subprocess-deadlock.patch ___ Python tracker <http://bugs.python.org/issue17367> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11370] Fix distutils to carry configure's LIBS through to extension modules.
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 ___ Python tracker <http://bugs.python.org/issue11370> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11370] Fix distutils to carry configure's LIBS through to extension modules.
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 handled already? -- ___ Python tracker <http://bugs.python.org/issue11370> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11370] Fix distutils to carry configure's LIBS through to extension modules.
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 ignore anything that didn't start with a "-l" or end with a ".a". Not sure if that's the best answer, or if we should allow -framework and friends to pass through. I put this under distutils, but it's really targeted towards the py3k-jit branch... which hasn't been updated since June. :-( -- assignee: tarek components: Distutils files: libs-to-extension.patch keywords: patch messages: 129863 nosy: eric.araujo, jszakmeister, tarek priority: normal severity: normal status: open title: Fix distutils to carry configure's LIBS through to extension modules. type: feature request Added file: http://bugs.python.org/file20971/libs-to-extension.patch ___ Python tracker <http://bugs.python.org/issue11370> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build
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 a different problem. :-) -- ___ Python tracker <http://bugs.python.org/issue11222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build
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/issue11222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build
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/issue11222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build
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 tracker <http://bugs.python.org/issue11222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build
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 there's probably still something not quite right. -- ___ Python tracker <http://bugs.python.org/issue11222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build
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. :-) -- ___ Python tracker <http://bugs.python.org/issue11222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build
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.org/issue11222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build
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/issue11222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build
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 `python.exe'. Stop. make: *** Waiting for unfinished jobs It seems there might be a $(VERSION)/$(LDVERSION) problem somewhere in the Makefile, but I'm uncertain where the issue is exactly. Looks like using --enable-framework instead of --enable-shared works, but I'd rather not have the framework right now. -- components: Build messages: 128647 nosy: jszakmeister priority: normal severity: normal status: open title: Python3.2rc3 fails to build on Mac OS X with a non-framework build versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6245] Add "intel" universal architecture on OSX
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. I don't think he's trying to claim that fat binaries won't run if there is 64-bit PPC code in them. FWIW, it's the --with-universal-archs option that he said wasn't 100% usable, not the binaries. -- nosy: +jszakmeister ___ Python tracker <http://bugs.python.org/issue6245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4829] confusing error for file("foo", "w++")
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 picking off the fact that there is repeated mode characters. Leaving that off allows io.open() to behave exactly like the built-in open() call. OTOH, someone obviously wanted to make sure that repeat mode characters were not allowed. So I guess someone needs to rule on whether we want io.open() and io.FileIO() to behave like the built-in, or to keep things more strict. -- ___ Python tracker <http://bugs.python.org/issue4829> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6220] typo: opne in "doanddont"
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 not sure what that comment really means? -- ___ Python tracker <http://bugs.python.org/issue6220> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6220] typo: opne in "doanddont"
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/issue6220> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6220] typo: opne in "doanddont"
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/issue6220> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4618] print_function and unicode_literals don't work together
Changes by John Szakmeister : -- nosy: +jszakmeister ___ Python tracker <http://bugs.python.org/issue4618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3329] API for setting the memory allocator used by Python
Changes by John Szakmeister : -- nosy: +jszakmeister ___ Python tracker <http://bugs.python.org/issue3329> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4829] confusing error for file("foo", "w++")
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", "credits" or "license" for more information. >>> open('foo.txt', 'w++') Is this still really an issue then? The current trunk also allows multiple mode letters too, so it seems like a decision has been made. -- nosy: +jszakmeister ___ Python tracker <http://bugs.python.org/issue4829> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3425] posixmodule.c always using res = utime(path, NULL)
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 system. However this patch introduced no additional failures (test_posix passes). BTW, the patch is against trunk. -- keywords: +patch nosy: +jszakmeister Added file: http://bugs.python.org/file14104/issue-3425-utimes.patch ___ Python tracker <http://bugs.python.org/issue3425> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com