[issue43760] The DISPATCH() macro is not as efficient as it could be (move PyThreadState.use_tracing)
John Ehresman added the comment: Is adding the field back an option at this point? It would mean that extensions compiled against the release candidates may not be binary compatible with the final release My take is that use_tracing is an implementation and version dependent field, and that binary compatibility will be maintained for a specific release (e.g. 3.10) but that there's no assurance that it will be there in the next release -- though these things tend not to change. I also regard generated cython code as only being valid for the releases that a specific cython version supports. Code and API's change slowly, but eventually they do change. -- nosy: +jpe ___ Python tracker <https://bugs.python.org/issue43760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23948] Deprecate os.kill() on Windows
John Ehresman added the comment: The original idea was to not use kill on win32 because developers often assume it will work like it does on unix-like OS's -- my claim is while kill could be improved on win32, it still won't support all the things kill can do elsewhere. I don't think this idea has much, if any support so I suggest closing this bug and opening other specific bugs to improve it on win32 for the ideas mentioned in the comments. -- ___ Python tracker <https://bugs.python.org/issue23948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42080] Disutils on windows debug build fails without -j1
John Ehresman added the comment: It is a setuptools bug and I've opened a setuptools issue at https://github.com/pypa/setuptools/issues/2442 Thanks! -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42080] Disutils on windows debug build fails without -j1
New submission from John Ehresman : Compiling pillow for a debug build fails without -j1 because distutils parallelizes the build, but there are problems with locking the .pdb file during when compiling the C files. An example of the error message from a cl.exe command is: fatal error C1041: cannot open program database 'C:\src\tmp\pillow-test\Pillow-7.2.0\vc140.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS Building works with setup.py build_ext --disable-jpeg --disable-tiff --disable-zlib --debug build -j1 My guess is the fix is not to parallelize by default in a debug build; a /FS arg to cl.exe could be used, but that doesn't seem to be recommended. I realize this might be considered a pillow bug, but my guess is that it affects other packages as well -- components: Distutils, Windows messages: 378959 nosy: dstufft, eric.araujo, jpe, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Disutils on windows debug build fails without -j1 type: compile error versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28521] _PyEval_RequestCodeExtraIndex should return a globally valid index, not a ThreadState specific one
New submission from John Ehresman: The index returned by _PyEval_RequestCodeExtraIndex is currently specific to the current thread state. This means that there will be problems if the index is used on another thread. It would be possible to set things up in my code so that _PyEval_RequestCodeExtraIndex was called once per thread state but there would be a possibility of getting different indices on the different threads and data set on one thread passed to the wrong free function registered on a different thread. -- components: Interpreter Core messages: 279314 nosy: jpe priority: normal severity: normal status: open title: _PyEval_RequestCodeExtraIndex should return a globally valid index, not a ThreadState specific one type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28521> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27286] str object got multiple values for keyword argument
John Ehresman added the comment: Should the bytecode magic number be bumped in the 3.5 branch? This breaks .pyc / .pyo binary compatibility for python 3.5. As far as I can tell this has never been done before in a release after the major.minor.0 final release. This patch has made its way into debian's python 3.5 and I've gotten a bug report because of it for an app distributed without python source. Looking at the 3.5.2 tarball, it does not look like the change was included in 3.5.2. If the magic number is bumped in 3.5, the comment should be changed to reflect that it changes in 3.5.3 and not in 3.5.2 -- nosy: +jpe ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4214] no extension debug info with msvc9compiler.py
John Ehresman added the comment: I just ran into this again when I installed 2.7.10 -- evidently I had patched my local installation and forgot about it. This is very important to anyone who tries to use the Visual Studio C debugger to debug extension modules. -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4214 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23948] Deprecate os.kill() on Windows
John Ehresman added the comment: Part of the issue here is that GenerateConsoleCtrlEvent doesn't work like kill w/ SIGINT does on unix -- it only works if the the target process id is 0 and then it generates the signal in all processes that share the console. An alternate proposal here is to expose the GenerateConsoleCtrlEvent functionality separately and only accept a signal number of 9 and maybe 0 in kill(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23948 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23948] Deprecate os.kill() on Windows
John Ehresman added the comment: GenerateConsoleCtrlEvent has different limitations for CTRL_BREAK_EVENT and CTRL_C_EVENT according to MSDN; I was referring to the CTRL_C_EVENT limitations. Which python level signal handler will CTRL_BREAK_EVENT trigger? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23948 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23948] Deprecate os.kill() on Windows
John Ehresman added the comment: Interesting -- I didn't know about removing the ignore flag in the child process. The question is whether this is close enough to the kill w/ SIGINT behavior on unix to use the same name. I think that there are enough differences to warrant a Windows specific function that calls GenerateConsoleCtrlEvent. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23948 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23948] Deprecate os.kill() on Windows
New submission from John Ehresman: os.kill() on Windows cannot act like it does on non-windows platforms because of differences in the underlying platforms. I think only kill() with a signal number of 9 (terminate process unconditionally) and a signal number of 0 (test to see if process exists) could be implemented. It isn't possibly to send the INT signal or a HUP signal to another process -- or at least it isn't possible without the use of questionable api's and code. Windows specific functions would be added for terminateprocess() and generateconsolectrlevent(). os.kill() on non-windows platforms would be left alone. -- components: Windows messages: 240905 nosy: jpe, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Deprecate os.kill() on Windows type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23948 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14484] missing return in win32_kill?
John Ehresman added the comment: I've created issue #23948 for the idea of deprecating os.kill(). Is a patch needed for adding a return in the error case? It's that way in 2.7 and I'm struggling to come up with a reason why it shouldn't be added other than strict backward compatibility. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14484 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14484] missing return in win32_kill?
John Ehresman added the comment: I think at a minimum, a return should be added in the cases that call GenerateConsoleCtrlEvent and it fails. Here's a more radical proposal, though: deprecate kill() on Windows and add a function that calls GenerateConsoleCtrlEvent and another that calls TerminateProcess. The rationale is that the two do act quite a bit differently than kill does on non-Windows systems do and it's a bad idea to try to provide cross-platform functionality when it can't be done. kill() on non-Windows systems would be left alone. -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14484 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23719] PEP 475: port test_eintr to Windows
John Ehresman added the comment: Here's the 1st draft of a test for interrupts during time.sleep(). It creates a thread to generate the ctrl-c events which seems to work well (note that kill() on win32 is quite limited in terms of sending events to other processes). The creation and use of the subthread probably could be improved. I also needed to add a way of specifying creationflags for a subprocess so a new console could be created; otherwise the parent test process is also interrupted by the ctrl-c. I have not tested the modified test on a non-win32 platform -- keywords: +patch nosy: +jpe Added file: http://bugs.python.org/file38976/win32-sleep-test.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23719 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14484] missing return in win32_kill?
John Ehresman added the comment: A problem with os.kill with CTRL_C_EVENT is that CTRL_C_EVENT == 0 and on unix kill w/ a signal number of 0 is how you test to see if a process is running. This means that code written on unix to see if a process exists will try to send a ctrl-c to the other process; it will fail because GenerateConsoleCtrlEvent is so limited but the error message is likely to be confusing. Not using the kill() name also means that developers coming from unix won't expect other signal numbers to work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14484 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
John Ehresman added the comment: I've confirmed that the test included in the 3/25/15 patch fails without the change to ffi.c. I think the 11/5/14 change fixed the bug for calling into a C function and converting the return value, but did not address the callback case. The new patch seems to fix the callback case. -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20160 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9745] MSVC .pdb files not created by python 2.7 distutils
John Ehresman added the comment: Are you saying close this as a duplicate? That would be fine with me. I still think the /pdb:None should be removed if it hasn't been already. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9745 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9745] MSVC .pdb files not created by python 2.7 distutils
Changes by John Ehresman j...@wingware.com: -- resolution: - duplicate ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9745 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21151] winreg.SetValueEx causes crash if value = None
John Ehresman added the comment: Here's a simple patch with a test. Oddly, the test doesn't fail before the fix is applied when run with rt.bat, but fails when run directly. -- keywords: +patch nosy: +jpe Added file: http://bugs.python.org/file34840/fix-none-value.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21151 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8901] Windows registry path not ignored with -E option
John Ehresman added the comment: Is still an issue with importlib? At this point, I don't think this change can be made on 2.7 or 3.2. -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8901 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17717] Set up nasm from external.bat
John Ehresman added the comment: What I'd like is for external to set up all the dependencies needed to build python and run the test suite. Yes, nasm can be downloaded and set up separately, but that's true of all of the libraries that external.bat downloads. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17717] Set up nasm from external.bat
New submission from John Ehresman: It would be nice for Tools\buildbot\external.bat to set a copy of nasm up to use. Is there a reason this is not done? -- components: Windows messages: 186752 nosy: jpe priority: normal severity: normal status: open title: Set up nasm from external.bat type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17723] Use FileRead and FileWrite in fileio.c on Windows
New submission from John Ehresman: File object's can use the win32 api FileRead and FileWrite instead of the CRT's read write function. This would eliminate the need to set the mode to binary on stdin stdout, which is the underlying cause of issue 16587. This could also possibly be the basis of adding nonblocking functionality. An initial patch is attached, but I still need to verify what this does to the CRT mode of files that are opened by python (rather than already be opened, like stdin stdout are). -- files: use_filerw.patch keywords: patch messages: 186849 nosy: jpe priority: normal severity: normal status: open title: Use FileRead and FileWrite in fileio.c on Windows type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file29829/use_filerw.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16587] Py_Initialize breaks wprintf on Windows
John Ehresman added the comment: One way to fix this is to use the FileRead FileWrite api functions directly as proposed in issue 17723 I would regard this as a change in behavior and not a simple bug fix because there is probably code written for 3.3 that assumes the C level stdout is in binary after python is initialized so would target 3.4 for the change. -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13959] Re-implement parts of imp in pure Python
John Ehresman j...@wingware.com added the comment: This may be a known problem, but imp.load_module fails when trying to load a C extension. This is with the 3.3a4 release on Windows, though I suspect the problem is cross-platform. -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13959] Re-implement parts of imp in pure Python
John Ehresman j...@wingware.com added the comment: On 6/5/12 1:08 PM, Brett Cannon wrote: Brett Cannonbr...@python.org added the comment: Does it work in Python 3.2, John? If it does then it's just an oversight thanks to the lack of tests in test_imp and it shouldn't be too difficult to support. But do realize I have deprecated the function. =) Attached is a short test file to demonstrate this. It assumes the standard win32 layout, but shouldn't be hard to modify. It does work in Python 3.2, but the else: clause in 3.3's imp.load_module function raises an ImportError. I think the fix is to add an elif C_EXTENSION: clause that loads the .so / .pyd. I've already rewritten my code to use importlib when running in Python 3.3. -- Added file: http://bugs.python.org/file25834/imptest.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13959 ___import imp import importlib import sys dirname = r'c:\Python33\dlls' name = '_bz2' assert name not in sys.modules use_imp = True if use_imp: fp, pathname, description = imp.find_module(name, [dirname]) mod = imp.load_module(name, fp, pathname, description) else: loader = importlib.machinery.PathFinder.find_module(name, [dirname]) mod = loader.load_module(name) print (mod) ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14302] Move python.exe to bin/
John Ehresman j...@wingware.com added the comment: Just a few thoughts from someone who uses Windows and who'd need to change code for this change: 1) I don't know if waiting to 3.5 is needed. I can make the change to look in the bin directory fairly quickly. 2) Is it safe to add scripts to the PATH? I'd worry about something in there that's named so it clashes with a standard program such as notepad or chkdsk or more likely something else from another 3rd party program that is installed. 3) A python3.3.exe command should be added so that if someone installs both 3.3 and an eventual 3.4, he or she can run both. 4) The uninstaller should remove the PATH entry if at all possible. Another alternative is to provide a Start menu item for a Python 3.4 Command Prompt that would set up the environment that's similar to the Visual Studio 2008 Command Prompt. -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14302] Move python.exe to bin/
John Ehresman j...@wingware.com added the comment: Does this mean that the PATH entry won't be removed on uninstall? I can't tell from reading #3561, though I may have missed something. My worries are about the developer who doesn't know what the PATH is and would find it difficult to diagnose any problems caused by the new entries on the path -- problems that may affect things other than python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9745] MSVC .pdb files not created by python 2.7 distutils
New submission from John Ehresman j...@wingware.com: .pdb files are not created because /pdb:None is set as an option on line 415 of msvc9compiler.py. Removing the /pdb:None works to write the .pdb file and allow symbols to be loaded in the VS 2008 debugger in the one extension I tried. Anyone know why /pdb:None was added? -- components: Windows messages: 115389 nosy: jpe priority: normal severity: normal status: open title: MSVC .pdb files not created by python 2.7 distutils versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1209447] os.path.join() fails if 2nd arg is a UNC path
John Ehresman j...@wingware.com added the comment: I say close it since it is a change in behavior and shouldn't go in a point release. I'm happy to see it fixed in 3.1. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1209447 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2799] Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()
John Ehresman j...@wingware.com added the comment: I'm trying to port an existing C extension to py3k and find myself wanting something like PyUnicode_AsString so I don't need to introduce other objects to do memory management. PyUnicode_AsString is equivalent to PyArg_Parse w/ a 's' format code, which I find hard to believe will be removed. Another bug proposes changing the name and passing in a default value, which may be a good idea. -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5654] Add C hook in PyDict_SetItem for debuggers
New submission from John Ehresman j...@wingware.com: I'm interested in adding support for debugger watchpoint's in the core. A watchpoint would cause the debugger to stop when a value in a namespace changes. This hook would be called when PyDict_SetItem PyDict_DelItem is invoked. I realize that this does not cover function local variables, but I'm more interested in instance attributes and globals. This is a proof of concept patch; I wanted to see if it would work and get some initial feedback. I think the performance implications are minimal in the case where nothing is watched, though the performance of sample callback in _debuggerhooks can be improved. An issue may be if this is used outside a debugger implementation to implement an observer pattern -- I'd like to discourage it, but worry that it will be used since it's there, rather like how the settrace tracer gets used. If there's interest in this, I will clean this up and add watchpoints to pdb. -- components: Interpreter Core files: dicthook.diff keywords: patch messages: 85051 nosy: jpe severity: normal status: open title: Add C hook in PyDict_SetItem for debuggers versions: Python 2.7 Added file: http://bugs.python.org/file13549/dicthook.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5654 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5654] Add C hook in PyDict_SetItem for debuggers
Changes by John Ehresman j...@wingware.com: Added file: http://bugs.python.org/file13550/testhook.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5654 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1608921] PyThread_release_lock with pthreads munges errno
John Ehresman j...@wingware.com added the comment: Any possibility of a test case? -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1608921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3551] multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
John Ehresman j...@wingware.com added the comment: Looking into this a bit more and reading the documentation (sorry, I picked this up because I know something about win32 and not because I know multiprocessing), it looks like a connection is supposed to be message oriented and not byte oriented so that a recv() should return what is sent in a single send(). This is like how Queue works in the threading case. Note that I think the method signature when using the dummy.connection differ when using pipe_connection and that the two differ in what happens when several send_bytes's occur before a recv_bytes I'm currently leaning toward essentially leaving the current behavior (and documenting it) though maybe with a better exception and documenting that large byte arrays can't be sent through the pipe. What's still an issue is if a pickle ends up being too large. -- title: multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000) - multiprocessing.Pipe terminateswith ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3551] multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
John Ehresman j...@wingware.com added the comment: New patch which raises ValueError if WriteFile fails with ERROR_NO_SYSTEM_RESOURCES. I wasn't able to reliably write a test since putting the send_bytes in a try block seems to allow the call succeed. This is probably OS, swap file size, and timing dependent. -- Added file: http://bugs.python.org/file13560/win32_pipe2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5654] Add C hook in PyDict_SetItem for debuggers
John Ehresman j...@wingware.com added the comment: Oops, the multiprocessing changes should not be in the patch -- nosy: +sdeibel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5654 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3551] multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
John Ehresman j...@wingware.com added the comment: Attached is a patch, though I have mixed feelings about it. The OS error can still occur even if a smaller amount is written in each WriteFile call; I think an internal OS buffer fills up and the error is returned if that buffer is full because the other process hasn't read yet. The patch just ignores ERROR_NO_SYSTEM_RESOURCES and writes again. I don't know though if ERROR_NO_SYSTEM_RESOURCES can mean something else is wrong and the write will never succeed. The message is also broken up into 32K parts and a recv_bytes on the other end must be called multiple times to read it all. The patch is one option. Another might be to let the application decide to continue or not and essentially treat the pipes as nonblocking. -- keywords: +patch Added file: http://bugs.python.org/file13518/win32_pipe.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3551] multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
John Ehresman j...@wingware.com added the comment: I'll try to work on a patch for this, but the reproduce.py script seems to spawn dozens of sub-interpreters right now when run with trunk (python 2.7) on win32 -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3551] multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
Changes by John Ehresman j...@wingware.com: Added file: http://bugs.python.org/file13493/reproduce.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3551] multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
John Ehresman j...@wingware.com added the comment: Latest version works -- question is why prior versions spawned many subprocesses. It's really another bug because prior version wasn't hitting the write length limit. -- title: multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000) - multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3551] multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
John Ehresman j...@wingware.com added the comment: It turns out that the original reproduce.py deadlocks if the pipe buffer is smaller than message size -- even with a fix to the bug. Patch to fix is coming soon. -- Added file: http://bugs.python.org/file13498/reproduce.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706256] Give Partial the ability to skip positionals
John Ehresman j...@wingware.com added the comment: Commenting because this was brought up on python-dev -- I'd like this, primarily for the string method itertools optimization. It's ugly, but it would be better than writing C code. The alternative might be to somehow optimize trivial functions to execute without bytecode, but that would be considerably harder. -- nosy: +jpe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4018] for me installer problem on x64 Vista
New submission from John Ehresman [EMAIL PROTECTED]: After installing the 32 bit .msi or the 64 bit .msi for me on a fairly clean Vista x64 machine, the socket module won't import because of a side-by-side configuration error. The output below is from the 32 bit build. Microsoft Windows [Version 6.0.6000] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\maint\python26\python Python 2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win 32 Type help, copyright, credits or license for more information. import socket Traceback (most recent call last): File stdin, line 1, in module File C:\python26\lib\socket.py, line 46, in module import _socket ImportError: DLL load failed: The application has failed to start because its si de-by-side configuration is incorrect. Please see the application event log for more detail. The event log entry for this is: Activation context generation failed for C:\python26\DLLs\_socket.pyd.Error in manifest or policy file C:\python26\DLLs\Microsoft.VC90.CRT.MANIFEST on line 12. The value ../msvcr90.dll of attribute name in element urn:schemas-microsoft-com:asm.v1^file is invalid. Changing ../msvcr90.dll to ..\msvcr90.dll does not fix the problem Importing socket does work when the msi is installed for everyone. -- components: Windows messages: 74168 nosy: jpe severity: normal status: open title: for me installer problem on x64 Vista type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4018 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4018] for me installer problem on x64 Vista
John Ehresman [EMAIL PROTECTED] added the comment: Neither ..\\msvcr90.dll or a full path work (with \ or \\) seem to work. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4018 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4018] for me installer problem on x64 Vista
John Ehresman [EMAIL PROTECTED] added the comment: I think one of the tested machines is Vista RTM, though it's been updated. I also tried of Vista x32 SP1 and it fails there. If non-admin installs can't be made to work, I agree that the for me option be dropped and the installer changed to invoke UAC. I looked for a solution to this, but so far can't find any -- and this would also mean that .pyd files in site-packages and elsewhere would need .manifest files that contain the path to where msvcr90.dll is located. I think requiring an admin install might cause problems for py2exe though. This is rather important because it means that python is unusable using the default installation options and I suspect that many users won't know how to install for everyone. I'd still like to see the need to depend on a C runtime dll dropped at some point in the future, but I know that it's not an easy thing to do. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4018 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4018] for me installer problem on x64 Vista
John Ehresman [EMAIL PROTECTED] added the comment: I don't think this could even work: apparently, Vista disallows putting a path into the name field. So extension modules will have to ship with their own copy of the CRT (or link statically). I agree that this is the case. The closest thing I found to documentation of this is http://msdn.microsoft.com/en-us/library/ms235291.aspx under Deploying Visual C++ library DLLs as private assemblies. It specifies that the assembly be copied twice, once into the folder with the .exe and again into the folder with the .dll. I think the best option is to always install for everyone as administrator on Vista. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4018 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3887] Python 2.6 doesn't run after installation on amd64
John Ehresman [EMAIL PROTECTED] added the comment: The new installer works for both for everyone and for me installs. Thanks, John ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3887 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3887] Python 2.6 doesn't run after installation on amd64
John Ehresman [EMAIL PROTECTED] added the comment: This is on a fresh Vista Ultimate install. There is no msvcr90.dll anywhere on the system, if windows file search according to windows file search (I did check the hidden / system file box). The first report is from a for me install. After installing for all users, there's no dll in \python26 and the error log error message of: Activation context generation failed for C:\Python26\python.exe. Dependent Assembly Microsoft.VC90.CRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8 could not be found. Please use sxstrace.exe for detailed diagnosis. I tried using changing the .manifest and got a null pointer access error: Faulting application python.exe, version 0.0.0.0, time stamp 0x48cb6bcf, faulting module ntdll.dll, version 6.0.6001.18000, time stamp 0x4791adec, exception code 0xc07b, fault offset 0x000b1188, process id 0xa28, application start time 0x01c919c8f9746f89. I wonder if the x86 dll is being installed rather than the amd64 one. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3887 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3887] Python 2.6 doesn't run after installation on amd64
New submission from John Ehresman [EMAIL PROTECTED]: The amd64 python 2.6rc1 won't run after installation on Vista. It fails with the error (from the event log) of Activation context generation failed for C:\Python26\python.exe.Error in manifest or policy file C:\Python26\Microsoft.VC90.CRT.MANIFEST on line 11. Component identity found in manifest does not match the identity of the component requested. Reference is Microsoft.VC90.CRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8. Definition is Microsoft.VC90.CRT,processorArchitecture=x86,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8. Please use sxstrace.exe for detailed diagnosis. Looking at the C:\Python26\Microsoft.VC90.CRT.MANIFEST file, the processorArchitecture is set to x86 -- components: Windows messages: 73322 nosy: jpe severity: normal status: open title: Python 2.6 doesn't run after installation on amd64 type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3887 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
