Donald Stufft don...@stufft.io writes:
What version of OpenSSL is it using.
I'm using the pre-built Windows Mercurial installer, but if I unpack
the included library.zip, the SSLEAY32.DLL shows version 0.9.8r.
This is from the 3.1.2 install I just did a few hours ago. It appears
that hg 2.5.2
Do you mean your local repo? If so, I don't have a local repo at this
point - the failure is during the first clone.
-- David
On Sat, Oct 25, 2014 at 1:19 AM, Steve Dower steve.do...@microsoft.com
wrote:
I was seeing this recently and had to run recover on my repo (not sure
what the
I was seeing this recently and had to run recover on my repo (not sure what the
command line is for that - TortoiseHg had a menu). YMMV, but the symptoms sound
the same.
Cheers,
Steve
Top-posted from my Windows Phone
From: David Bolenmailto:db3l@gmail.com
I have an idea, can you run https://bpaste.net/show/c5d7cd102f5b and
tell me what it outputs? Both on a machine that works and one that
doesn’t.
On Oct 25, 2014, at 2:14 AM, David Bolen db3l@gmail.com wrote:
Donald Stufft don...@stufft.io writes:
What version of OpenSSL is it using.
I'm several weeks late to this discussion, but I'm glad to see that it
happened. I'm not a Python developer, and barely a user, but I have several
years of daily experience compiling complicated scientific software cross-
platform, particularly with MinGW-w64 for Windows. The Python community,
(Apologies for the short reply, posting from my phone.)
MSVC can continue
to be the default compiler used for Python on Windows, none of Roumen's
patches change that. They would merely open up the choice for packagers and
users to build CPython (and extension modules, thanks to separate patches)
On Sat, 25 Oct 2014 05:45:24 -0700, Tony Kelman kel...@berkeley.edu wrote:
As a developer of a (compiled) open-source library or application, wouldn't
you love to be able to build binaries on Linux for Windows? With some work
and build system patches, you can. For many projects it's a simple
Donald Stufft don...@stufft.io writes:
I have an idea, can you run https://bpaste.net/show/c5d7cd102f5b and
tell me what it outputs? Both on a machine that works and one that
doesn’t.
All but Linux (so XP/7 buildbots, XP standalone, OSX) return:
('DHE-RSA-AES128-SHA', 'TLSv1/SSLv3', 128)
As another data point, I've tried cloning randomly selected other
repositories from hg.python.org, and smaller repositories (distutils2,
peps, jython to name a few) are all working fine under XP, even though
with jython for example, the clone takes longer in terms of wall time
than I'll often see
Ray Donnelly wrote:
What is it that you
are afraid of if CPython can be compiled out of the box using
mingw/MinGW-w64? Why are you fighting so hard against having option.
I'm afraid of users having numpy crash because they're using an MSVC CPython
instead of a mingw CPython. I'm afraid of
On Sat, Oct 25, 2014 at 6:13 PM, Steve Dower steve.do...@microsoft.com wrote:
(Apologies for the short reply, posting from my phone.)
MSVC can continue
to be the default compiler used for Python on Windows, none of Roumen's
patches change that. They would merely open up the choice for
On Sun, Oct 26, 2014 at 7:50 AM, Steve Dower steve.do...@microsoft.com wrote:
Ray Donnelly wrote:
What is it that you
are afraid of if CPython can be compiled out of the box using
mingw/MinGW-w64? Why are you fighting so hard against having option.
I'm afraid of users having numpy crash
On Sun, 26 Oct 2014 08:11:39 +1100
Chris Angelico ros...@gmail.com wrote:
It might fragment the community to have multiple different binary
distributions. But it ought to be possible for any person/organization
to say We're going to make our own build of Python, with these
extension modules,
On Sun, Oct 26, 2014 at 8:47 AM, Antoine Pitrou solip...@pitrou.net wrote:
And how do you know that it would have worked with MSVC if you only use
MinGW?
If you want to ensure compatibility with MSVC, you must build with MSVC.
There's no working around that.
Precisely. If you build with
On Sat, 25 Oct 2014 21:10:23 +0100
Ray Donnelly mingw.andr...@gmail.com wrote:
This is the second time you've used the vacuous culture on Windows
argument, now with an added appeal to (vague) authority.
[...]
Why are you fighting so hard against having option.
If CPython wants to truly call
On Sun, 26 Oct 2014 08:53:29 +1100
Chris Angelico ros...@gmail.com wrote:
On Sun, Oct 26, 2014 at 8:47 AM, Antoine Pitrou solip...@pitrou.net wrote:
And how do you know that it would have worked with MSVC if you only use
MinGW?
If you want to ensure compatibility with MSVC, you must build
On Sat, Oct 25, 2014 at 10:52 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 25 Oct 2014 21:10:23 +0100
Ray Donnelly mingw.andr...@gmail.com wrote:
This is the second time you've used the vacuous culture on Windows
argument, now with an added appeal to (vague) authority.
[...]
Why
On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou solip...@pitrou.net wrote:
How do you know this isn't a problem, since you haven't *tested* with
MSVC?
Why on Earth would you want to test your PEP work with an unsupported
Windows compiler and runtime, rather than with the officially supported
In article m28uk4wxod@valheru.db3l.homeip.net,
David Bolen db3l@gmail.com wrote:
David Bolen db3l@gmail.com writes:
which appears to die mid-stream while receiving the manifests.
So I'm sort of hoping there might be some record server-side as to why
things are falling
On Sun, 26 Oct 2014 09:06:36 +1100
Chris Angelico ros...@gmail.com wrote:
On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou solip...@pitrou.net wrote:
How do you know this isn't a problem, since you haven't *tested* with
MSVC?
Why on Earth would you want to test your PEP work with an
On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou solip...@pitrou.net wrote:
My point is that your Windows build would not have the same behaviour
as a MSVC-produced Windows build, and so testing it with it would not
certify that your code would actually be compatible with genuine
MSVC builds of
On Sat, 25 Oct 2014 21:10:23 +0100, Ray Donnelly mingw.andr...@gmail.com
wrote:
On Sat, Oct 25, 2014 at 6:13 PM, Steve Dower steve.do...@microsoft.com
wrote:
(Apologies for the short reply, posting from my phone.)
MSVC can continue
to be the default compiler used for Python on Windows,
On 10/25/2014 5:11 PM, Chris Angelico wrote:
It might fragment the community to have multiple different binary
distributions. But it ought to be possible for any person/organization
to say We're going to make our own build of Python, with these
extension modules, built with this compiler,
On 25 October 2014 21:50, Steve Dower steve.do...@microsoft.com wrote:
Ray Donnelly wrote:
What is it that you
are afraid of if CPython can be compiled out of the box using
mingw/MinGW-w64? Why are you fighting so hard against having option.
I'm afraid of users having numpy crash because
In article nad-95699a.15140225102...@news.gmane.org,
Ned Deily n...@acm.org wrote:
In article m28uk4wxod@valheru.db3l.homeip.net,
David Bolen db3l@gmail.com wrote:
So that's sort of strange.
Very interesting! I had been doing some housekeeping on some of my
older OS X build
On Sun, 26 Oct 2014 09:22:18 +1100
Chris Angelico ros...@gmail.com wrote:
On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou solip...@pitrou.net wrote:
My point is that your Windows build would not have the same behaviour
as a MSVC-produced Windows build, and so testing it with it would not
On 25 October 2014 23:22, Chris Angelico ros...@gmail.com wrote:
On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou solip...@pitrou.net wrote:
My point is that your Windows build would not have the same behaviour
as a MSVC-produced Windows build, and so testing it with it would not
certify that
Hello developers,
I observed strange behaviour in CPython (tested in 2.7.5 and 3.3.3)
regarding object resurrection.
Yes, resurrection is evil, but it is a valid scenario. If an object is
resurrected via its finalizer __del__, sometimes its unique id value as
returned from id() changes.
Hello Stefan,
On Sun, 26 Oct 2014 00:20:47 +0200
Stefan Richthofer stefan.richtho...@gmx.de wrote:
Hello developers,
I observed strange behaviour in CPython (tested in 2.7.5 and 3.3.3)
regarding object resurrection.
Your runGC() function is buggy, it does not run the GC under CPython.
Fix
On Sun, 26 Oct 2014 00:19:44 +0200, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 26 Oct 2014 09:06:36 +1100
Chris Angelico ros...@gmail.com wrote:
On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou solip...@pitrou.net wrote:
How do you know this isn't a problem, since you haven't *tested*
On Sat, 25 Oct 2014 19:24:38 -0400
R. David Murray rdmur...@bitdance.com wrote:
I know I for one do not generally test patches on Windows because I
haven't taken the time to learn how to build CPython on it. Sure, I
could test pure python changes by applying patches to an installed
Python,
On Sat, Oct 25, 2014 at 1:10 PM, Ray Donnelly mingw.andr...@gmail.com
wrote:
On Sat, Oct 25, 2014 at 6:13 PM, Steve Dower steve.do...@microsoft.com
wrote:
Building CPython for Windows is not something that needs solving. The
culture on Windows is to redistribute binaries, not source, and
On 26/10/2014 00:24, R. David Murray wrote:
On Sun, 26 Oct 2014 00:19:44 +0200, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 26 Oct 2014 09:06:36 +1100
Chris Angelico ros...@gmail.com wrote:
On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou solip...@pitrou.net wrote:
How do you know this
On Sun, Oct 26, 2014 at 12:30 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 25 Oct 2014 19:24:38 -0400
R. David Murray rdmur...@bitdance.com wrote:
I know I for one do not generally test patches on Windows because I
haven't taken the time to learn how to build CPython on it. Sure, I
On Sat, Oct 25, 2014 at 11:44 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 25 October 2014 23:22, Chris Angelico ros...@gmail.com wrote:
On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou solip...@pitrou.net wrote:
My point is that your Windows build would not have the same behaviour
as a
Okay, sorry, I was thinking too Jython-like. I fixed runGC() just to
see now that it does not even trigger resurrection, since under
CPython there are no finalizers executed in ref cycles (i.e. I find my
objects in gc.garbage).
So I realize, my xy_cyclic tests are pointless anyway since in cyclic
On Sun, 26 Oct 2014 02:50:39 +0200
Stefan Richthofer stefan.richtho...@gmx.de wrote:
Okay, sorry, I was thinking too Jython-like. I fixed runGC() just to
see now that it does not even trigger resurrection, since under
CPython there are no finalizers executed in ref cycles (i.e. I find my
On Sun, Oct 26, 2014 at 1:45 AM, Steve Dower steve.do...@microsoft.com wrote:
Ray Donnelly wrote:
On Sat, Oct 25, 2014 at 11:44 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 25 October 2014 23:22, Chris Angelico ros...@gmail.com wrote:
On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou
Ray Donnelly wrote:
On Sun, Oct 26, 2014 at 1:45 AM, Steve Dower steve.do...@microsoft.com
wrote:
Ray Donnelly wrote:
Also, where are the publicly accessible specifications and other technical
descriptions that MinGW-w64 would need to implement strong binary
compatibility with MSVC? As a
On Sat, Oct 25, 2014 at 7:05 PM, Ray Donnelly mingw.andr...@gmail.com wrote:
On Sun, Oct 26, 2014 at 12:30 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 25 Oct 2014 19:24:38 -0400
R. David Murray rdmur...@bitdance.com wrote:
I know I for one do not generally test patches on Windows
On Sat, Oct 25, 2014 at 6:24 PM, R. David Murray rdmur...@bitdance.com wrote:
Note: it can be made even less compelling by making it a lot easier to
build CPython on Windows without having an MSVC license (which I think
means not using the GUI, for which I say *yay* :). I think Zach Ware
has
On Saturday, October 25, 2014, Stefan Richthofer stefan.richtho...@gmx.de
wrote:
Okay, sorry, I was thinking too Jython-like. I fixed runGC() just to
see now that it does not even trigger resurrection, since under
CPython there are no finalizers executed in ref cycles (i.e. I find my
objects
42 matches
Mail list logo
