John Ehresman 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
<http://bugs.python.
New submission from John Ehresman :
.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
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 "
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
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.pytho
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
buil
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://
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
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 th
John Ehresman 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'
John Ehresman 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 functi
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 d
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
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
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
___
John Ehresman 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
John Ehresman 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
diagno
John Ehresman 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
John Ehresman added the comment:
On 6/5/12 1:08 PM, Brett Cannon wrote:
>
> Brett Cannon 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 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-
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
<http://bugs.python.org/i
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
<http://bugs.python.org/i
Changes by John Ehresman :
--
resolution: -> duplicate
___
Python tracker
<http://bugs.python.org/issue9745>
___
___
Python-bugs-list mailing list
Unsubscrib
John Ehresman 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
Changes by John Ehresman :
Added file: http://bugs.python.org/file13493/reproduce.py
___
Python tracker
<http://bugs.python.org/issue3551>
___
___
Python-bugs-list mailin
John Ehresman 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_RESOURCE
John Ehresman 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 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
New submission from John Ehresman :
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 :
Added file: http://bugs.python.org/file13550/testhook.py
___
Python tracker
<http://bugs.python.org/issue5654>
___
___
Python-bugs-list mailin
John Ehresman added the comment:
Any possibility of a test case?
--
nosy: +jpe
___
Python tracker
<http://bugs.python.org/issue1608921>
___
___
Python-bugs-list m
John Ehresman 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
John Ehresman 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 depe
John Ehresman added the comment:
Oops, the multiprocessing changes should not be in the patch
--
nosy: +sdeibel
___
Python tracker
<http://bugs.python.org/issue5
John Ehresman added the comment:
My hope is that the runtime performance cost will be negligible but if
it isn't, it probably shouldn't go in. The issue with not putting it in
another build is that many python debugger users won't want to
recompile, so I see it as being of
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
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
al
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 i
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
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:
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
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
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:
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 u
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 ba
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 Wi
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
51 matches
Mail list logo
