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
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
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
___
Pytho
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Changes by John Ehresman j...@wingware.com:
--
resolution: - duplicate
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9745
___
___
Python-bugs
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
50 matches
Mail list logo
