Steve Dower added the comment:
Pushed some changes based on Zach's feedback and added a new complete patch
(minus the deletion of the PC/VS9.0 and PC/VS10.0 folders).
--
Added file: http://bugs.python.org/file37251/cpython_93607_to_93616
Steve Dower added the comment:
Added some fixes to the python3.dll build (and xxlimited test project) which I
noticed thanks to Antoine's feedback.
--
Added file: http://bugs.python.org/file37265/python3.diff
___
Python tracker
Steve Dower added the comment:
> After a debug build with VS2015, my biggest concern is this:
>
> ..\PC\bdist_wininst\install.rc(19): fatal error RC1015: cannot open
> include file 'afxres.h'. [P:\ath\to\cpython\PCbuild\bdist_wininst.vcxproj]
I thought I had a workaro
Steve Dower added the comment:
Added changes from Zach's last review.
Highlight: I deleted the make_versioninfo project and build step :)
--
Added file: http://bugs.python.org/file37270/round4.diff
___
Python tracker
<http://bugs.py
Steve Dower added the comment:
I've inadvertently picked this up with my changes for #22919, so it'll get into
3.5 that way.
Do we need to apply this to 3.4 as well? What about 2.7?
--
assignee: -> steve.dower
nosy: +steve.dower
___
P
Steve Dower added the comment:
This is by design. I'm sure if you email python-list then someone there will be
able to explain how the difference can help you write clearer code than if they
both behaved exactly the same.
--
___
Python tr
Steve Dower added the comment:
Info about python-list is at
https://mail.python.org/mailman/listinfo/python-list
--
___
Python tracker
<http://bugs.python.org/issue22
Changes by Steve Dower :
--
resolution: -> not a bug
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22938>
___
___
Python-bugs-list
Steve Dower added the comment:
The "just for me" option isn't actually a per-user install, it actually just
restricts use of the core Python DLL to Python itself and not any other
applications that may want to use it (by putting the DLL in the Python folder
instead of th
Steve Dower added the comment:
The patch looks safe enough to me, if Benjamin is willing to consider it for
2.7.9?
Seems fine for 3.4 and 3.5 too, if nobody is opposed (or wants to argue over
the wording of the message).
--
nosy: +benjamin.peterson
Steve Dower added the comment:
AFAICT, cabinet.lib has been around since at least VS 2008, so 3.4 will be
fine. But since it builds currently there's no point changing it. I'll just let
my changes handle it for 3.5 and leave the older vers
Steve Dower added the comment:
That patch looks good to me (better than my fix would have been :) )
--
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
>> After a debug build with VS2015, my biggest concern is this:
>>
>> ..\PC\bdist_wininst\install.rc(19): fatal error RC1015: cannot open
>> include file 'afxres.h'. [P:\ath\to\cpython\PCbuild\bdist_wininst.vcxproj]
>
> I
Steve Dower added the comment:
I'm very much in favor of adding this for .pyds on Windows.
I assume the hard part will be getting the details for Linux (doesn't bitness
have to be compiled in there? For Windows it can be determined at
compile-time...), but preferring an extension wi
Steve Dower added the comment:
I was more interested in source file resolution than bytecode caching. If
Python 3.5 would prefer "spam.cpython-35.py" or "spam.cpython-3.py" over
"spam.py" and Python 2 preferred "spam.py", then I can more easily se
Steve Dower added the comment:
But since you pointed out cache-tag, should that distinguish for bitness as
well? It seems to be 'cpython-34' for both 32-bit and 64-bit interpreters on
Windows, which isn't really a problem now, but may become one if we start
allowing/enco
Steve Dower added the comment:
@Antoine: You're right. I hereby withdraw all contributions to this thread
after my first statement of support :)
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Does anyone else want to provide any feedback? Or should I go ahead and get it
in (after rebasing/retesting/etc.)? The feedback so far has been really helpful.
--
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
Rebased everything onto default and pushed it to my sandbox.
--
hgrepos: +283
___
Python tracker
<http://bugs.python.org/issue22
Changes by Steve Dower :
--
hgrepos: -283
___
Python tracker
<http://bugs.python.org/issue22919>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
Having trouble getting the patch uploaded... next attempt.
--
Added file: http://bugs.python.org/file37374/round5complete.patch
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
What can I do to help move this along?
It sounds like for Windows builds we could change _imp.extension_suffixes()
from ['.pyd'] to ['.{}.pyd'.format(distutils.util.get_platform()), '.pyd'] and
update distutils to produce the mor
Steve Dower added the comment:
The attached patch adds platform tags for .pyd files for "win32", "win-arm",
"win-amd64" and "win-ia64", which are the known compilers in pyconfig.h and the
potential return values from distutils.util.get_platform(). It als
Steve Dower added the comment:
> Why not using on Windows the same naming scheme than Unix.
> It may be useful to also add the debug flag (d) in the name for example.
Windows already puts the debug flag in the name, the fact that it's CPython is
in the .pyd extension, and the versio
Steve Dower added the comment:
> The version number would be useful for in-place builds (i.e. when developping)
Ah, I see now how that would be useful (I haven't tried to deal with that
before). I'll revise the patch to use/allow the v
Steve Dower added the comment:
Added "cp35" (and later "cp36", etc.) to the tag, so now it looks similar to
PEP 425 without the ABI tag (ironically, since there's fundamentally no
difference between the Python version and the ABI). "cp3" is also accepted fo
Steve Dower added the comment:
Small incremental patch from Zach's feedback and a few sysconfig changes I
missed.
--
Added file: http://bugs.python.org/file37392/round6incremental.patch
___
Python tracker
<http://bugs.python.org/is
New submission from Steve Dower:
We should include the version resource in python[w].exe as well as python35.dll
so that it can be properly identified. (If possible, we should do .pyd files
too, though I don't think the version info will be displayed, so it's probably
no
Steve Dower added the comment:
Patch for the version info, and also for half of #19143 since I was there.
--
components: +Windows
keywords: +patch
nosy: +tim.golden, zach.ware
Added file: http://bugs.python.org/file37393/23018.patch
___
Python
Steve Dower added the comment:
Rebased and updated NEWS, so here's a complete patch (and it's all in the
latest change in https://hg.python.org/sandbox/steve.dower#Projects)
--
Added file: http://bugs.python.org/file37405/round7com
Steve Dower added the comment:
I'll be closely tracking any issues that arise out of this throughout the next
couple of days, but it should be fairly smooth (especially for people who don't
upgrade VS immediately). There are certainly a few things that are broken, but
I'l
New submission from Steve Dower:
Currently, the implementation of __setstate__ at Lib/multiprocessing/heap.py:54
looks like this:
def __setstate__(self, state):
self.size, self.name = self._state = state
self.buffer = mmap.mmap(-1, self.size, tagname=self.name)
assert
Steve Dower added the comment:
A buildbot failure due to this can be seen here:
http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/183/steps/test/logs/stdio
--
___
Python tracker
<http://bugs.python.org/issue23
Steve Dower added the comment:
This patch also resolves this test issue:
[ 68/390/2] test_ttk_textonly
test test_ttk_textonly crashed -- Traceback (most recent call last):
File "D:\...\lib\test\regrtest.py", line 1280, in runtest_inner
test_runner()
File "
Steve Dower added the comment:
Nobody seemed too bothered by it, so I committed a slightly simpler change that
only includes the most specific tag (that is, ".cp35-win32.pyd" or ".pyd"). We
can always add another tag easily enough if it seems useful, or roll this
cha
Steve Dower added the comment:
I justified leaving out the ABI tag in an earlier post as well as in an email
to distutils-sig, where two of the PEPs you mention were developed, and nobody
had any comment. Cache tags don't include platform information and are
worthless here.
distutils
Steve Dower added the comment:
That was actually my first hack and it also works. The fundamental problem here
is that GetLastError() is not actually meant to indicate *whether* an error has
occurred, but when one has occurred it describes what it was.
Indeed, in this case no error has
Steve Dower added the comment:
> get_platform() will be difficult to reuse, for bootstrapping reasons
ISTM that if you can't determine the value at compile time, then it doesn't
matter to compilation enough to need to appear in the tag.
As far as matching PEP 425 for the sake o
Changes by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
I've commented out the assertion for now with a comment pointing to this issue,
so that'll keep the buildbots running while we figure out how to deal with this
properly.
--
___
Python tracker
<http://bu
Steve Dower added the comment:
When you say "2.7.X", which version are you installing and which version did
you have installed?
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
I think Matthias is referring to #20160, but as far as I could tell libffi is
multiple versions ahead of the version in Python and already has the fixes. I
was told to wait for it to be submitted/accepted upstream, so I've been wa
Steve Dower added the comment:
This was fixed with #22919.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
As I mentioned on the other post, libffi's current version bears no relation to
what we have in CPython, so the patches don't apply. I'm not planning on
rewriting CPython patches so that they will apply to libffi, nor do I intend to
replace our
Steve Dower added the comment:
I'm not entirely familiar with our layout of libffi, but I don't think your
patch will affect Windows at all. If your intent was to update the version used
in Windows builds, then you may as well abandon it. I'm not the one to ask
about
Steve Dower added the comment:
That's strange, and it isn't what normally happens, so I suspect it's a
configuration or corruption issue on your machine (possibly Kapersky Pure is to
blame?). The 2.7.7, 2.7.8 and 2.7.9 installers all have the correct version
information
Steve Dower added the comment:
I'm already quite keen to rename the registry key for 32-bit on Windows, since
there are some places where that will cause conflicts. This won't be done for
3.4 though, as we don't have an active maintainer for the old installer (Martin
is stil
Steve Dower added the comment:
I've previously reported this issue against setuptools (which generates the
executable) and apparently they consider it a "feature". I don't have the link
handy from my phone, but if you find the issue on bitbucket you can help
attract so
Steve Dower added the comment:
I thought that USERPROFILE was the preferred environment variable and should be
checked before HOME, but I could be wrong. Consistency with the existing
expanduser function is more important probably.
There's almost certainly an API to find an arbitrary
Steve Dower added the comment:
Add for Windows 10
(source:
http://blogs.msdn.com/b/chuckw/archive/2013/09/10/manifest-madness.aspx)
--
___
Python tracker
<http://bugs.python.org/issue23
Steve Dower added the comment:
I've attached a replacement for the win32_ver function in platform.py that will
get the actual version number from kernel32.dll's resources. Originally I was
just writing a helper function, but it seemed easy enough to replace the entire
function.
Th
Changes by Steve Dower :
--
resolution: -> duplicate
status: open -> closed
superseder: -> Update PCBuild for VS 2015
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
It shouldn't be necessary for VS 2010 and later, and the
`extra_link_args=['/MANIFEST']` workaround should be sufficient for cases where
it is necessary (specific dependencies other than MSVCRT that req
Steve Dower added the comment:
And I suspect Matthew Brett's issue is that link_executable() does not expect
an extension ('.exe') to be provided.
--
___
Python tracker
<http://bugs.py
Changes by Steve Dower :
Removed file: http://bugs.python.org/file37578/win32_ver.py
___
Python tracker
<http://bugs.python.org/issue19143>
___
___
Python-bugs-list mailin
Steve Dower added the comment:
Thanks for the feedback. Updated the attachment with some other tidying too.
--
Added file: http://bugs.python.org/file37586/win32_ver.py
___
Python tracker
<http://bugs.python.org/issue19
New submission from Steve Dower:
Currently test_largefile is failing on the Windows buildbots because an fstat()
call in Modules/_io/fileio.c is failing. fstat() returns a 32-bit size, but the
file being opened is larger than 2GB.
This appears to be a change in the CRT where it would
Steve Dower added the comment:
Sorry, I was focused on the fact that you don't need a manifest with VS 2010
and not that distutils was forcing you to have one when building an executable.
Either adding '/MANIFEST' as in paxan's patch (according to
http://msdn.microso
Steve Dower added the comment:
Okay, I'll try and find a way to redefine it only under Windows. Unfortunately,
the CRT defines fstat() as a function, which makes it hard to redefine without
eagerly including sys/stat.h.
--
___
Python tracker
Steve Dower added the comment:
/MANIFEST is probably assumed on VC9 since the CRT required it, but that was
probably changed for VC10 without updating the documentation fully. Frankly I'd
rather remove the MANIFESTFILE property added by distutils, since it doesn't
add anything of va
Steve Dower added the comment:
Looks like the easiest fix here is to remove the HAVE_SYS_STAT_H definition and
replace it with the include directly:
/* Define to 1 if you have the header file. */
/* #define HAVE_SYS_STAT_H 1 */
#ifndef MS_WINCE
/* Rather than define HAVE_SYS_STAT_H, we
Steve Dower added the comment:
This is because the hg id result has changed and we embed that into
python35.dll. You'll see the same thing after an edit too (when the revision
has + added).
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
I'll reassign this to me, as I'm looking into making Program Files the default
location for 3.5.
I'd like to release at least some of the alphas with the change active by
default (i.e. it's easy to select the old directory) to get broader
Steve Dower added the comment:
Ah, I forgot to put Configuration in there. That patch is fine.
If it's only the OpenSSL projects doing this, that shouldn't cause 31 projects
to rebuild (4 at most I'd have though), but it probably will cause more
rebuilds
Steve Dower added the comment:
Don't have time to apply them right now, but the patches look fine. I guess
it'll null-merge into default, since 3.5 is unaffected?
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
You will need Windows 7 *SP1*, as I don't think VS will run without the
updates. There is also a service pack for VS 2010 that may enable opening the
newer solution - it certainly worked for me.
We decided not to keep the old project files as they weren&#x
Steve Dower added the comment:
I prefer your patch too. (I've posted on the other thread about the build
problems, and I'll test this when I get a chance.)
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
Just emailed Jeremy about the buildbot. It looks like the last time tests were
run something didn't clean up properly and left the build output locked.
There's nothing wrong with the project files.
--
Steve Dower added the comment:
This change only has an effect of you're building with Visual Studio and our
fork of libffi. You seem to have an unrelated issue.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Yeah, unfortunately the only correct way to do this is to use a debug build of
Python. It isn't that difficult to build, but it is extra work and may not be
an option at all depending on context (for example, some businesses won't let
employees acc
Steve Dower added the comment:
Right, so when using python34_d.dll you need the _d.pyd versions (and if you're
building your own .pyd you need to add the _d suffix too). There's nothing
wrong with this difference, since the debug and release builds are subtly
incompatible with each
Steve Dower added the comment:
> Could you explain what replacing the _d suffix with a "d" ABI flag
> would break ?
It breaks consistency with python_d.exe and python35_d.dll, mainly, and those
are not going to change (specifically, python.exe and python35.dll are not
going t
Steve Dower added the comment:
distutils will (now, after some changes in 3.5) build debug versions of
packages on installation when running with python_d.exe. I haven't tested
exactly how pip behaves here, but it should work fine if you run with a command
line like this:
python_d.exe -
Steve Dower added the comment:
Anyone have any opinions on this? My only hesitation is adding the Windows 10
UUID, which will fix GetVersion but may cause other API problems, and we're
certainly not testing against Windows 10 yet. (On the other hand, it's easy
enough to remove t
Steve Dower added the comment:
Thanks for the notice. I'll try and get that fixed up for the next 2.7 release.
--
assignee: -> steve.dower
___
Python tracker
<http://bugs.python.org
Steve Dower added the comment:
Is the libpython27.a file actually a 32-bit version or is it just corrupted? It
seems to be considerably smaller than the version in the 32-bit installer, but
it is certainly not being generated from the 32-bit version.
I didn't write this code originally,
Steve Dower added the comment:
It sounds like the script should handle the case where someone has already
changed stdout better. We wrap the streams in PTVS so we can forward the output
into the IDE where Unicode will display properly anyway.
Our wrapper missing fileno is a bug in our side
Steve Dower added the comment:
> I do have Windows 7 SP1.
I expected so, but didn't want to assume.
> I have VS 2010 *Express* and I'm now able to open the project after
> installing the Service Pack 1 of VS 2010.
Glad to hear it. You made me a little nervous there :)
Steve Dower added the comment:
Sure :)
If you view Properties in Windows for Python 3.4's python[w].exe and look at
the Details tab, it's very blank (for me it shows 'Application', the size and
the modification date). However, if you look at python34.dll or py.exe i
Steve Dower added the comment:
You're running on Fedora, not Windows, so this is not the right issue. You
should open a new one and probably post on python-dev to get some attention
(since there's no useful nosy lists right now and ctypes has no
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> patch review
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue23018>
___
___
Steve Dower added the comment:
Victor, I've been testing your patch and it's mostly good (a few obscure errors
you'd never find without a compiler), but I think we also need to update the
win32_xstat functions in posixmodule.c, since they all try and use the same
struct.
I
Steve Dower added the comment:
Setuptools has the code to find the compiler package. We deliberately put it
there instead of in distutils to make sure more people would get it.
I should probably port the extra check into 2.7.10, but the immediate fix is to
import setuptools
Steve Dower added the comment:
FWIW, at some point I will need to do some serious work on this code for Python
3.5, so I'll certainly take your suggestions into account there. But I won't be
doing the same for old versions of Python - at most 2.7 may get a check for the
extra re
New submission from Steve Dower:
Currently, pythonXY.dll has a dependency on shell32.dll solely for the
os.startfile (Modules/posixmodule.c) function. This is quite a heavy dependency
that many would rather not have to load (e.g. lightweight server
configurations).
It would be nice to delay
New submission from Steve Dower:
This seems like the best (only?) way to get a devguide patch reviewed... I
don't have any concerns, but other people may have some more suggestions for
this section that I'm happy to add.
--
assignee: steve.dower
components: Devguide, Win
Steve Dower added the comment:
Thanks! Haven't updated the patch, but I've fixed them.
--
___
Python tracker
<http://bugs.python.org/issue23257>
___
___
Changes by Steve Dower :
--
assignee: -> steve.dower
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue23253>
___
___
Python-bugs-
Steve Dower added the comment:
Attached a patch.
Comparing the time for "python.exe -c '0'" with Powershell's Measure-Command
tool, it looks like there's a 3-4ms (~8-10%) improvement in startup time too.
That's not at all robust, but it's certainly no
Steve Dower added the comment:
So I've grabbed gendef and dlltool from the latest mingw-w64 and will look at
using those in the future for both 2.7 and 3.5.
According to objdump, I can use these to create file format pe-i386 and
pe-x86-64 with the same tools. Are these the correct format
Steve Dower added the comment:
You can close those applications, or ignore the message and continue, just like
the dialog says (if you ignore it, you may need to reboot for installation to
complete). You could also try doing a Just for Me installation.
Python is not trying to update those
Steve Dower added the comment:
Yeah, I hate touching posixmodule.c for the same reason. It'd be nice to split
it up into separate platform files, but nobody is volunteering for that.
If you focus on the performance, then yeah, this change probably isn't worth
it. OTOH, the number
Steve Dower added the comment:
Closing again, as Victor's issue was resolved (VS 2010 SP1 is needed, and I'm
updating the devguide to specify that on #23257).
--
resolution: -> fixed
status: open -> closed
___
Pytho
New submission from Steve Dower:
Updating the installer for better security and robustness. Large patch coming
soon (just getting an issue number to put in NEWS).
--
assignee: steve.dower
components: Windows
messages: 234203
nosy: steve.dower, tim.golden, zach.ware
priority: release
Changes by Steve Dower :
Added file: http://bugs.python.org/file37752/README.txt
___
Python tracker
<http://bugs.python.org/issue23260>
___
___
Python-bugs-list mailin
Steve Dower added the comment:
Patch. I'm also revising Doc/using/windows.rst, but I don't want to delay the
initial reviews.
I don't think this is perfect, but it works well enough for the first alpha
(scheduled for 8 Feb), so I want to get it in and stabilised now rather th
Steve Dower added the comment:
As I expected, shortly after posting this I find a significant issue with the
way the installer will work.
Expect a revised patch soon :)
--
___
Python tracker
<http://bugs.python.org/issue23
Steve Dower added the comment:
New patch with some changes to how optional debug symbols and binaries are
handled. (I misunderstood how a particular WiX feature worked...)
--
Added file: http://bugs.python.org/file37754/23260_2.diff
___
Python
Steve Dower added the comment:
Just came across this advice on
https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows:
> Do not use MinGW-w64. As you will notice, the MinGW import library for
> Python (e.g. libpython27.a) is omitted from the AMD64 version of
> Python
Steve Dower added the comment:
That change modified pythoncore, so I'd expect to see most projects rebuild.
Especially under Release, where we don't have some of the build optimizations
enabled (because they hurt runtime performance).
--
4601 - 4700 of 5794 matches
Mail list logo
