Steve Dower added the comment:
That's a possibility. I won't have a chance to check for a few days, but it
should get another bug if it's wrong.
--
___
Python tracker
<http://bugs.pyt
Steve Dower added the comment:
> What needs to still be done in order that a user with a fresh Python install
> in Windows (and no compiler installed) can do "pip install
> an_extension_that_needs_compiling" and it _just works_?
The package developer takes the time to build
Steve Dower added the comment:
As an occasional Linux user, I notice a huge difference between pure Python and
extension packages there, but basically always have a compiler handy on my
Windows machines. It's all about context and what you're used to :)
The advice has always be
Steve Dower added the comment:
Does rebooting allow you to keep going?
--
___
Python tracker
<http://bugs.python.org/issue25922>
___
___
Python-bugs-list mailin
Steve Dower added the comment:
We are working on the Fortran issue in a few different ways, one of which is
your work on MinGW compatibility so that gfortran can be used. But that isn't
the only solution to this whole problem, and it's not even preferable for a lot
of Python users,
Steve Dower added the comment:
"We" is a lot of different companies and individuals. Anyone distributing
prebuilt binaries is helping here, a few people are working on the licensing
concerns for some components, other people are working on C BLAS libraries.
I see the issue approx
Steve Dower added the comment:
And FTR, there are plenty of major Python-using companies that insist on
compiling from scratch and also refuse to touch GPL at all, no matter how many
exemptions are in the licenses. GFortran is not the ideal solution for these
users
Steve Dower added the comment:
Did we want a deprecation warning too? I don't see it in the patch.
Otherwise, LGTM.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Joakim, your operating system is corrupted somehow. I'd suggest getting in
touch with Microsoft support, as you should be able to install that update. (Or
maybe you've done something to block Wind
Steve Dower added the comment:
Looks good to me.
Is it worth dropping psexec.exe into the test suite so we can add a test for
this (or maybe into tools so we can run it from a build without redistributing
the exe)? It'll probably be helpful elsewhere too (symlink tests, for ex
Steve Dower added the comment:
Is that Windows Server 2003? It's also not supported for Python 3.5, as
Microsoft is no longer supporting it. You'll need to stick with Python 3.4 or
get Server 2008 or later.
--
___
Python trac
Steve Dower added the comment:
Might require R2 then, I haven't looked too closely at the Server requirements.
When I get a chance to check, I'll see if there's a bypass for the version
test. The test is there because of a Windows package we need to install though,
and I don&
Steve Dower added the comment:
Do you have the log files from your %TEMP% directory still? I'll need to see
the ones from the original install, not the repair, but you can just bundle
them all up.
Create a new issue too - this one is res
Steve Dower added the comment:
Can we use ctypes in the test suite? That would probably be simpler here, as
the C code is straightforward. (Question is for the other core devs, not Chi,
as I know we're not supposed to use ctypes in the s
Steve Dower added the comment:
Since you're on Python 3.5, you'll need Visual Studio 2015 to build extensions.
However, since the extension in question is numpy, you'll need to find prebuilt
binaries since you won't be able to compile it yourself just yet. I believe
Cont
Steve Dower added the comment:
I can't read those error messages, but I suspect this is because some of the
bundled files are omitted from the embeddable package.
Using it to run venv isn't really part of the intended use cases - it's
expected you'll manually install p
Steve Dower added the comment:
Looks good to me. Feel free to check it in, Mark, or one of us will get to it
if you're not set up for committing right now.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
I don't think Vinay does much wrt the launcher in core anymore, it's mostly
been me recently.
I don't see any harm in this change, though I'll admit I also don't see the
point. When is the launcher ever going to f
Steve Dower added the comment:
In this case, it needs to load vcruntime for the python##.dll, so linking isn't
going to make any difference. We need to statically link the loader, since it
will be run independently and can't have any dependencies, but when it finds a
Python install
Steve Dower added the comment:
Ultimately, launching python.exe is better than loading python##.dll here
because it avoids DLL planting vulnerabilities, but I'm honestly a little
surprised still that LoadLibrary won't resolve vcruntime in this case. Been a
while since I looked, and
Steve Dower added the comment:
> I've had a heavy consulting load for the past year or so which means I can't
> always deal with issues as quickly as before.
That explains it :) With so little visibility into what we're doing outside of
Python it's hard to kno
Steve Dower added the comment:
> The directory of the DLL can be added to the search path if you use
> LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an absolute
> path.
That sounds like the better fix then. I thought there was something along those
lines avail
Steve Dower added the comment:
The downside of the preprocessor - no errors when you spell an ifdef wrong ;)
It looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue26
Steve Dower added the comment:
Good catch! Once I'm at a PC I'll merge this in unless someone else gets there
first. (I believe it also applies to 2.7 since the project files were updated.)
--
versions: +Python 2.7, Python 3.6
___
Pyth
Steve Dower added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue25348>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Steve Dower added the comment:
It's better than using the Visual Studio version, which isn't necessarily tied
to any VC version. To support another compiler will require more code like this
anyway.
An alternative may be to patch Tcl et al. to not put the VC version into the
o
Steve Dower added the comment:
Strictly there's nothing incorrect about the docs, and `cdll.msvcrt` is no more
incorrect than it has been since Python 2.4 or so (whenever we stopped using
VC6). It will find the DLL and you can call the functions, but it isn't the
same DLL as the
Steve Dower added the comment:
Do you have any evidence of it failing for those reasons? The command used is
specifically crafted to prevent those issues.
I'm not saying there aren't potentially other issues that would be nice to
surface (though fairly difficult without modifying
Steve Dower added the comment:
The msvcrt module? I don't think so.
--
___
Python tracker
<http://bugs.python.org/issue23606>
___
___
Python-bugs-list m
Steve Dower added the comment:
The log files will be sufficient. You'll find them in your %TEMP% directory -
there'll be around 20 text files, so put them in a zip and upload them here.
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
I'm a little surprised this is the first we've heard of this issue, but the
analysis seems sound.
It's probably a misconfiguration on my build machine, or possibly something to
do with the project file backport. I'll look into it.
Steve Dower added the comment:
I've added a brief doc section on modifying and removing the install, so
hopefully that suffices for this issue. If the original issue occurs again,
feel free to reopen, but I think it'll be okay.
I have a few ideas about changing the installer
Steve Dower added the comment:
Terry, have you had a chance to try this with 2.7.11 final? (We didn't change
anything, so I have no reason to expect anything difference.)
Without broader confirmation that this is an issue, I don't see how we can keep
it as a release blocker. I al
Changes by Steve Dower :
--
assignee: -> steve.dower
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> behavior
versions: +Python 3.6
___
Python tracker
<http://bugs.pyt
Steve Dower added the comment:
For anyone interested, there's no issue with using the cross compilers even on
a 64-bit system. The same code will be generated, the only difference is that
the native 64-bit compilers can keep more in memory than the 32-bit cross
compilers. For most P
Steve Dower added the comment:
I made a new patch to replace all of the existing ones here with the two-line
version of the change.
I also suppressed warning 4232 about dllimport addresses (essentially, you may
get different values when taking the address of an imported function because of
Steve Dower added the comment:
IMHO enabling the eol extension is the right way to deal with this. Especially
once the GitHub migration happens - it really doesn't handle CRLF endings (or
anything Windows) as well as Mercurial does.
--
___
P
Steve Dower added the comment:
Sorry for letting this slide for a while...
Can you check (in Programs and Features, View Installed Updates) whether you
have KB2999226 installed? If not, you can get it from
https://support.microsoft.com/en-us/kb/2999226
In the first install, this component
Steve Dower added the comment:
I'm good with the patch, except we can't use ctypes in the standard library.
NeedCurrentDirectoryForExePathW will need to be wrapped in Modules/_winapi.c.
Should be fairly simple to do, though it probably requires learning argument
clinic (which ad
Steve Dower added the comment:
Zach - you still got this or do you want me to commit it?
--
___
Python tracker
<http://bugs.python.org/issue25778>
___
___
Pytho
Steve Dower added the comment:
This is something that you need to fix in the code using MMX. I don't recall
the details, but there is an instruction that needs to be executed between
using MMX and using the FPU.
Python can't make this judgement every time it calls into native co
Changes by Steve Dower :
--
assignee: -> steve.dower
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Steve Dower added the comment:
I'm declaring using venv from the embeddable distro as unsupported, and it will
be removed completely from the next release.
To create virtual environments, use a regular install of Python.
--
assignee: -> steve.dower
resolution: ->
Steve Dower added the comment:
Thanks!
--
assignee: -> steve.dower
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Changes by Steve Dower :
--
assignee: -> mhammond
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Steve Dower added the comment:
Applied the patch and rebuilt the stubs, so this will show up in 3.5.2 and 3.6.
--
assignee: -> steve.dower
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://
Changes by Steve Dower :
--
resolution: -> not a bug
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue26108>
___
___
Python-bugs-list
Steve Dower added the comment:
Closing as norepro, but happy to reopen if it's still an issue with the
official release.
--
resolution: -> works for me
status: open -> closed
___
Python tracker
<http://bugs.python.
Steve Dower added the comment:
@Victor - is there anything else to be done for this issue or can we close it?
--
___
Python tracker
<http://bugs.python.org/issue25
Steve Dower added the comment:
Checked PCBuild/readme.txt and it's pretty clear that you can only use VS 2010+
with the SDK and the old compiler. So I'm closing this as wontfix as we will
not be merging support to build Python 2 with VC10 or later.
--
resolution: -> w
Steve Dower added the comment:
Closing as third-party, but happy to reopen if this turns out to be something
specific to our installer and not the configuration of the target system.
--
resolution: -> third party
status: open -> closed
___
Steve Dower added the comment:
libmpdec/memory.c keeps pointers to customisable memory functions (malloc/free)
and initialises them to &malloc and &free. These functions are dllimport'd from
the CRT, and so they trigger a warning letting you know that "&malloc ==
&
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25694>
___
Steve Dower added the comment:
I don't think the C standard necessarily applies or defines what happens when
you call/link a __declspec'd function, but it's certainly not going to be the
same as static linking.
That said, maybe the subtle nature of this means we should suppr
Steve Dower added the comment:
I actually have a prototype of this already, though I haven't benchmarked the
impact yet.
Brett and I were concerned that the applicability wasn't apparent enough given
the cost involved, so we've been (slowly) preparing a PEP, mainly to have that
Steve Dower added the comment:
Is your installation working okay then? You seemed to imply that in an earlier
message, but I just want to confirm before closing the issue.
--
___
Python tracker
<http://bugs.python.org/issue25
Steve Dower added the comment:
Preferably just one group of them (created around the same time) for a failed
installation.
--
___
Python tracker
<http://bugs.python.org/issue26
Steve Dower added the comment:
You should have some log files in your %TEMP% directory, all starting with
"python". Could you post those here? They'll help us see what happened.
--
___
Python tracker
<http://bugs.pyt
Steve Dower added the comment:
I'm -0 on changing the universal default (and want to call out that it's a
relevant porting note for 3.6, not appropriate for 3.5), but we can presumably
fix those in case someone wants to use strict for their
Steve Dower added the comment:
MSVC has had Link-Time Code Generation for many releases, and it should have
been used for all 2.7 releases (definitely used in 3.5+) to optimize references
between object files. I assume this is equivalent to LTO.
We currently don't use PGO in the off
Steve Dower added the comment:
I read the issue as "running an embedded Python interpreter without a reachable
standard library fails", which is by design. But for 2.7 it's also apparently
the design to rely on an installed copy of Python for this. (This second part
is no lon
Steve Dower added the comment:
This is trying to remove 2.7.10, so I guess it's not as clean as you think.
You'll need to repair the 2.7.10 install (not just reinstall it - it has to be
the right version so you can choose repair) and then
Steve Dower added the comment:
That'd suggest a change in the link options since 2.7.10, probably SUBSYSTEM.
Or possibly there's a config option that prevents allocating a console
correctly on startup.
FWIW, I don't think WinXP 64-bit was ever considered trustworthy, so it m
Steve Dower added the comment:
So the more interesting error message is higher up:
xxmodule.c
xxmodule.obj : warning LNK4197: export 'PyInit_xx' specified multiple times;
using first specification
Creating library
d:\temp\tmptzty591d\Debug\temp\tmptzty591d\xx_d.cp36-win_amd
Steve Dower added the comment:
Yep, that's what I meant. So many cross compilers these days...
--
___
Python tracker
<http://bugs.python.org/issue26207>
___
___
Steve Dower added the comment:
That's true, though if you use the embeddable distribution of Python 3.5 you
automatically get the equivalent behavior because of a new option (the
"applocal" option in pyvenv.cfg, which is enabled in that di
Steve Dower added the comment:
VS 2015 won't cause this (I also work on that product as my day job, so I know
exactly what it does and doesn't do), but the registry corruption probably did.
The pip support that's in the 2.7 installer is not the most robust code, and it
can
Steve Dower added the comment:
Might be nice to switch the socket APIs to the Unicode ones universally. That
would also clear up a range of deprecation warnings on build.
--
___
Python tracker
<http://bugs.python.org/issue26
Steve Dower added the comment:
I couldn't remember the names of the alternate functions Windows provides to do
the encoding for you, but yes. There are socket APIs there that do encoding and
handle memory allocation more safely.
Apart from bugs like this, it's not really urg
Steve Dower added the comment:
This has been confirmed as a bug in VS 2015 RTM that was fixed in Update 1.
It only affects debug builds, which are not common and I expect most people
using them to be keeping VS up to date.
I'd rather not add extra logic to distutils just to detect this
Steve Dower added the comment:
For this particular issue, the way to detect it is to read
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\DevDiv\vc\Servicing\14.0\Tools.X86.X64@UpdateVersion
and see if it is at least "14.0.23506".
This doesn't extend to other VS versions, b
Steve Dower added the comment:
Looks like the log files were attached just fine.
>From a first glance, the logs don't show anything being installed into your
>documents folder.
Could you list the files you are seeing, where they are and where you believe
the
Changes by Steve Dower :
--
title: test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot -> distutils
msvccompiler fails due to mspdb140.dll error on debug builds
___
Python tracker
<http://bugs.pytho
Steve Dower added the comment:
Sorry, not happening.
There's a very prominent checkbox on the first page of the installer, which was
added under protest.
I'd suggest learning the py.exe launcher instead, which does not suffer from
any of the issues that are caused by modifying
Steve Dower added the comment:
It's not clear which version of Python you are having trouble with, but it
apparently isn't 3.5.
The PYTHONHOME variable is never set or modified by our installers, but some
earlier versions may be affected by it. We recommend never setting e
Steve Dower added the comment:
Go ahead. Feel free to add toolsets to cover ICC if you need them.
At one point I was passing through those directories for the build and it was
not really trivial. A few too many places where it needed to be handled, but
with patches against Tix it's pro
Steve Dower added the comment:
Paths prefixed with "\\?\" also need to be normalized, not just absolute. AFAIK
there are no official docs on what normalization is required, but it includes
at least trimming trailing dots on directory names, removing "." and ".."
Steve Dower added the comment:
It shouldn't make any difference as the lib file is not needed at runtime.
While developing your app, you should use a regular installation to make sure
you have all the header files you need. The embeddable distro is for ru
Changes by Steve Dower :
--
resolution: -> not a bug
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue26349>
___
___
Python-bugs-list
Changes by Steve Dower :
--
resolution: not a bug -> rejected
___
Python tracker
<http://bugs.python.org/issue26349>
___
___
Python-bugs-list mailing list
Un
Steve Dower added the comment:
It was fixed in 2.7 - https://hg.python.org/cpython/rev/3cddcf471c70
The issue number wasn't in the commit, so it didn't appear here.
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
Agreed. The PCBuild/readme.txt file should clear up a few of those points, but
the docs aren't exactly beginner friendly (and by that I mean beginning Windows
users, not beginning C developers).
We probably need someone to write a dedicated document for bui
Steve Dower added the comment:
It's unfortunately not so clear from the "minimum Vista" statement that WS2K3
is excluded, but if you follow the official statement ("supported by
Microsoft") then you'll see that WS2K3 is no longer covered.
Vista and Windo
Steve Dower added the comment:
Doesn't really matter, since we get to do it all again with #26465.
--
resolution: fixed -> out of date
stage: commit review -> resolved
status: pending -> closed
superseder: -> Upgrade OpenSSL shipped with
Changes by Steve Dower :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
I didn't have nasm on the path when preparing, so it made empty asm files.
I've committed the correctly build ASM files, and I'll trigger the buildbots to
clean and patch the prepare script to fail if nasm i
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue26465>
___
Steve Dower added the comment:
Nothing has changed here as far as I'm aware.
The part of platform.py in use here has potentially different behavior if you
have pywin32 installed. Is that the case? Maybe you updated that as well or
haven't installed it for
Steve Dower added the comment:
Do you have any more details about this? A log file perhaps?
With the current information there's nothing we can do to help you.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
That's what I initially assumed, but when I looked in my 2.7 repo those changes
weren't there. But according to the bug I checked them in, so I guess it is my
fault.
Looking at the diff (e.g. 2f57270374f7), it seems I got sucked in by following
th
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue26513>
___
Steve Dower added the comment:
Assigning to Benjamin to make the call for 2.7. Either close or assign it back
if you want the update.
--
assignee: steve.dower -> benjamin.peterson
versions: -Python 3.5, Python 3.6
___
Python tracker
&l
Steve Dower added the comment:
That's a bit too much of a tangent for me to note in-place in the docs, but
it'd be good content for a "Best practices" section (I seem to recall we had
one somewhere, that basically started with "avoid ctypes if possible"...)
Given
Steve Dower added the comment:
Python 2.7 has a different section in its tcltk.props file and doesn't need
this fix (yet).
Thanks for the patch, Bjoern!
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python
Steve Dower added the comment:
Done. The test_sqlite tests were fine, but that's all I checked.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
Steve Dower added the comment:
Thanks! Fixed for 3.6, 3.5 and 2.7.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
I can't reproduce this - I used almost exactly your code and it worked fine.
The one change I made was to use either L"python35.zip" alone (as my exe was
alongside the zip) or a full path to the zip file. Both of these worked.
If the zip fi
Steve Dower added the comment:
I used the python35.dll in the embeddable install, along with the python35.zip
included in there. I linked against python.h and python35.lib from a full
install, but put the resulting exe in the directory with the embeddable install
so it uses that instead of
Steve Dower added the comment:
Are you making a debug build? It might be looking for _ctypes_d.pyd in that
case. You'll need a release build for the embeddable distro, as well as
including the pyds from the zip in sys.path - they need to be standalone files.
The embeddable release is
Steve Dower added the comment:
Unless you're working on CPython itself, I'd suggest just installing the debug
binaries through the installer.
I've made a note to write a blog post on how to use the embeddable distro, so
when that comes out (in a few weeks, probably) hopeful
5201 - 5300 of 5794 matches
Mail list logo
