R. David Murray writes:
> On Sun, 26 Oct 2014 00:19:44 +0200, Antoine Pitrou
> 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
>I think 'resuscitation' might be a better metaphor.
The term 'resurrection' is not my invention, but well established:
http://en.wikipedia.org/wiki/Object_resurrection
I well understand why Antoine objects to calling it "resurrection" in CPython
due to
implementation specific reasons. But in th
On Sun, Oct 26, 2014 at 3:41 PM, Paul Moore wrote:
> Not really, to be honest. I still don't understand why anyone not
> directly involved in CPython development would need to build their own
> Python executable on Windows.
Late Python bugfix releases are source-only, so if you suffer from a
bug
On 27 October 2014 21:19, Steve Dower wrote:
>> No, we've been trying to establish whether the patches to build with mingw
>> were
>> intended to produce such a compatible build. It's not clear, but so far it
>> seems
>> that apparently that is *not* the intent (and worse, mingw-w64 may not even
On 10/27/2014 12:23 PM, Stefan Richthofer wrote:
You mean Jython deletes instance attributes before calling __del__ ?
No. I think the term of "object resurrection" usually does not mean
bringing
back a deleted object in the sense that memory was already freed.
I think it rather means that not
On Mon, Oct 27, 2014 at 8:54 PM, Steve Dower wrote:
> Greg Ewing wrote:
>> Nick Coghlan wrote:
>>> That assumption will allow MinGW-w64 to link with the appropriate
>>> MSVCRT versions for extention building without anything breaking.
>>
>> If that works, then the same technique should allow CPyth
> Paul Moore wrote:
> On 27 October 2014 20:45, Greg Ewing wrote:
>> Nick Coghlan wrote:
>>>
>>> That assumption will allow MinGW-w64 to link with the appropriate
>>> MSVCRT versions for extention building without anything breaking.
>>
>>
>> If that works, then the same technique should allow CPyt
Greg Ewing wrote:
> Nick Coghlan wrote:
>> That assumption will allow MinGW-w64 to link with the appropriate
>> MSVCRT versions for extention building without anything breaking.
>
> If that works, then the same technique should allow CPython itself to be built
> in a VS-compatible way with mingw, s
On 27 October 2014 20:45, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> That assumption will allow MinGW-w64 to link with the appropriate
>> MSVCRT versions for extention building without anything breaking.
>
>
> If that works, then the same technique should allow CPython
> itself to be built in a
Nick Coghlan wrote:
That assumption will allow MinGW-w64 to link with the appropriate
MSVCRT versions for extention building without anything breaking.
If that works, then the same technique should allow CPython
itself to be built in a VS-compatible way with mingw,
shouldn't it?
Those objectin
On Mon, Oct 27, 2014 at 5:48 PM, Paul Moore wrote:
> On 26 October 2014 23:44, Paul Moore wrote:
>> On 26 October 2014 23:11, Ray Donnelly wrote:
>>> I don't know where this "ABI compatible" thing came into being;
>>
>> Simple. If a mingw-built CPython doesn't work with the same extensions
>> as
On Sun, Oct 26, 2014 at 11:52 PM, wrote:
>
> Zitat von Tony Kelman :
>
>> A maintainer has volunteered. Others will help. Can any core developers
>> please begin reviewing some of his patches?
>
>
> Unfortunately, every attempt to review these patches has failed for me,
> every time. In the last
On 27 October 2014 18:47, Case Van Horsen wrote:
> I've managed to build gmpy2 (which requires GMP, MPFR, and MPC
> libraries) using msys2. I've detailed the steps (hacking) at:
>
> https://code.google.com/p/gmpy/source/browse/trunk/msys2_build.txt
Thanks for this. I don't have the time to read y
On Mon, Oct 27, 2014 at 10:48 AM, Paul Moore wrote:
> The bad news is that the support added to the old 32-bit mingw to
> support linking to alternative C runtime libraries (specifically
> -lmsvcr100) has bitrotted, and no longer functions correctly in
> mingw-w64. As a result, not only can mingw-
Ned Deily writes:
> Update: after consulting with Donald on IRC, it appears that the problem
> was on the python.org end and is now fixed. David, is it now working
> again for you?
Sorry for the delay - yes, it appears to be working again for me as
well. And it looks like clones during the b
On Mon, 27 Oct 2014 18:40:24 +0100
Stefan Richthofer wrote:
> >If Jython does things differently, then certainly its behaviour is
> >incompatible with the common expectations of Python developers.
>
> Guido recently pointed out that it is allowed for different Python
> implementations to alter de
On 26 October 2014 23:44, Paul Moore wrote:
> On 26 October 2014 23:11, Ray Donnelly wrote:
>> I don't know where this "ABI compatible" thing came into being;
>
> Simple. If a mingw-built CPython doesn't work with the same extensions
> as a MSVC-built CPython, then the community gets fragmented (
I already admitted that it is implementation specific whether one would
talk of resurrection, even in one and the same scenario. (Although
I would prefer to agree on an abstract notion of the resurrection term.)
If Jython does things differently, then certainly its behaviour is
incompatible with
On Mon, 27 Oct 2014 17:23:23 +0100
Stefan Richthofer wrote:
>
> >You mean Jython deletes instance attributes before calling __del__ ?
>
> No. I think the term of "object resurrection" usually does not mean bringing
> back a deleted object in the sense that memory was already freed.
> I think it
You mean Jython deletes instance attributes before calling __del__ ?
No. I think the term of "object resurrection" usually does not mean bringing
back a deleted object in the sense that memory was already freed.
I think it rather means that nothing referred to an object, so it was on the
"kill
On Mon, 27 Oct 2014 16:20:06 +0100
Stefan Richthofer wrote:
>
> I already pointed out
> "One can surely argue x2 has never been dead, or see it as
> "it was killed along with x and then resurrected by x"."
>
> In Java and thus in Jython, it is treated as the second one.
You mean Jython deletes
>It's not that resurrection occurs indirectly, it's that the object
>pointed to by "x2" always remains alive
Yes, this is right for CPython, more precisely this is about the definition
of the word "resurrection" (in language-independent sense),
which seems not to be unique.
I already pointed out
Please ignore this. I hit the wrong button.
On 27 October 2014 14:18, Paul Moore wrote:
> On 26 October 2014 01:05, Ray Donnelly wrote:
>> Download and run:
>> http://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-x86_64-20141003.exe/download
>
> Sending this offline because I really don
On 26 October 2014 01:05, Ray Donnelly wrote:
> Download and run:
> http://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-x86_64-20141003.exe/download
Sending this offline because I really don't want to start up another
extended debate, but is there a version of this that I can use that
_
On Mon, 27 Oct 2014 14:36:31 +0100
Stefan Richthofer wrote:
> Your test program performs no resurrection of x.
>
> Interestingly, it does not change behavior if you write
>
> class X(object):
> def __del__(self):
> X.x = self
> print ref()
>
> (Thanks for making me aware
Your test program performs no resurrection of x.
Interestingly, it does not change behavior if you write
class X(object):
def __del__(self):
X.x = self
print ref()
(Thanks for making me aware of this! My test-case was already
initially the more complex one given below)
But
On 27 October 2014 12:30, Nick Coghlan wrote:
>> OK, I'm willing to accept that statement. But I don't understand it,
>> and I don't think you've explained why you *need* your CPython
>> interpreter to be compiled with mingw (as opposed to a number of other
>> things you might need around building
On 27 October 2014 09:37, Paul Moore wrote:
> On 26 October 2014 23:24, Tony Kelman wrote:
>> I want, and in many places *need*, an all-MinGW stack.
>
> OK, I'm willing to accept that statement. But I don't understand it,
> and I don't think you've explained why you *need* your CPython
> interpre
On 27 October 2014 09:44, Paul Moore wrote:
> I view it as critical (because availability of binaries is *already*
> enough of a problem in the Windows world, without making it worse)
> that we avoid this sort of fragmentation. I'm not seeing an
> acknowledgement from the mingw side that they agre
29 matches
Mail list logo
