On 9/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz schrieb:
> > I also tested the fix (see patch below) for the abs() issue and it
> > seemed to work for 4.1.1 on 64-bit. I'll apply the patch to head and
> > 2.5 and a test after 2.5 is out.
>
> Please also add it to 2.4.
Yes
Neal Norwitz schrieb:
> I also tested the fix (see patch below) for the abs() issue and it
> seemed to work for 4.1.1 on 64-bit. I'll apply the patch to head and
> 2.5 and a test after 2.5 is out.
Please also add it to 2.4.
> Index: Objects/intobject.c
> =
I also tested the fix (see patch below) for the abs() issue and it
seemed to work for 4.1.1 on 64-bit. I'll apply the patch to head and
2.5 and a test after 2.5 is out.
I have no idea how to search for these problems. I know that xrange
can't display -sys.maxint-1 properly, but I think it works
> BTW, did anyone try compiling Python with -fwrapv on a box where it
> matters? I doubt that Python's speed is affected one way or the
> other, and if adding wrapv makes the problems go away, that would be
> an easy last-second workaround for all possible such problems (which
> of course could ge
[Armin Rigo]
>> There are more cases of signed integer overflows in the CPython source
>> code base...
>>
>> That's on a 64-bits machine:
>>
>> [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2
>> abs(-sys.maxint-1) == -sys.maxint-1
><
>> Humpf! Looks like one person or two need
Ok, time to bring down the hammer. The release25-maint branch is absolutely
frozen to everyone but the release team from 00:00UTC, Tuesday 19th September.
That's just under 20 hours from now. This is for Python 2.5 FINAL, so anyone
who breaks this release will make me very, very sad. Based on th
On Saturday 16 September 2006 21:11, Armin Rigo wrote:
> Hi all,
>
> There are more cases of signed integer overflows in the CPython source
> code base...
>
> That's on a 64-bits machine:
>
> [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2
> abs(-sys.maxint-1) == -sys.maxint-1
Ronald Oussoren schrieb:
> BTW. several sites on the interweb claim that x86-64 runs faster than
> plain x86 due to a larger register set. All my machines are 32-bit so I
> can't check if this is relevant for Python (let alone Python on OSX).
That is plausible. OTOH, the AMD64 binaries will often
Jack Jansen schrieb:
> Just wondering: is it a good idea in the first place to create a
> universal 32/64 bit Python on MacOSX?
I wonder about the same thing.
> For extension modules it's different, though: there it would be nice
> to be able to have a single module that could load into any P
On Sep 17, 2006, at 9:37 PM, Jack Howarth wrote:
Martin,
I believe if you use the Xcode project management the
Universal binary creation is automated. Currently they
support the i386/ppc binaries but once Leopard comes
out you will see i386/x86_64/ppc/ppc64 binaries for
shared libraries.
On Sep 17, 2006, at 9:29 PM, Jack Jansen wrote:
Just wondering: is it a good idea in the first place to create a
universal 32/64 bit Python on MacOSX?
On MacOS you don't pay a penalty or anything for running in 32-bit
mode on any current hardware, so the choice of whether to use 32 or
64 bits
Martin,
I believe if you use the Xcode project management the
Universal binary creation is automated. Currently they
support the i386/ppc binaries but once Leopard comes
out you will see i386/x86_64/ppc/ppc64 binaries for
shared libraries.
Jack
_
Just wondering: is it a good idea in the first place to create a
universal 32/64 bit Python on MacOSX?
On MacOS you don't pay a penalty or anything for running in 32-bit
mode on any current hardware, so the choice of whether to use 32 or
64 bits really depends on the application. A single Py
On Sep 17, 2006, at 8:56 PM, Martin v. Löwis wrote:
One of the announced features of osx 10.5 is 64-bit support
throughout
the system and I definitely want to see if we can get 4-way universal
support on such systems. As I don't have a system that is capable of
running 64-bit code I'm not
Ronald Oussoren schrieb:
> The sizes of basic types are the same on PPC32 and x86 which helps a
> lot.
Ah, right. This was the missing piece of the puzzle.
The byteorder is different, but we can use GCC feature checks
> there. The relevant bit of pyconfig.h.in:
>
> #ifdef __BIG_ENDIAN__
> #defi
On Sep 17, 2006, at 8:35 PM, Martin v. Löwis wrote:
Josiah Carlson schrieb:
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Out of curiosity: how do the current universal binaries deal with
this
issue?
If I remember correctly, usually you do two completely independant
compile runs (optionall
On 9/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson schrieb:
> > "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Out of curiosity: how do the current universal binaries deal with this
> >> issue?
> >
> > If I remember correctly, usually you do two completely independant
> >
On Sep 17, 2006, at 8:03 PM, Josiah Carlson wrote:
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Out of curiosity: how do the current universal binaries deal with
this
issue?
If I remember correctly, usually you do two completely independant
compile runs (optionally on the same machine wit
I've been playing with the new features and there's one thing about
the new relative import that I find a little strange and I'm not sure
this was intended...
When you do a from . import xxx, it will always fail if you're in a
top-level module, and when executing any module, the directory of the
m
Josiah Carlson schrieb:
> "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Out of curiosity: how do the current universal binaries deal with this
>> issue?
>
> If I remember correctly, usually you do two completely independant
> compile runs (optionally on the same machine with different configure
On Sep 17, 2006, at 6:53 PM, Martin v. Löwis wrote:
Ronald Oussoren schrieb:
One problem is that python's configure script detects the sizes of
various types and those values will be different on 32-bit and 64-bit
flavours.
FWIW, the PC build "solves" this problem by providing a hand-crafted
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Out of curiosity: how do the current universal binaries deal with this
> issue?
If I remember correctly, usually you do two completely independant
compile runs (optionally on the same machine with different configure or
macro definitions, then use a
Ronald Oussoren schrieb:
> One problem is that python's configure script detects the sizes of
> various types and those values will be different on 32-bit and 64-bit
> flavours.
FWIW, the PC build "solves" this problem by providing a hand-crafted
pyconfig.h file, instead of using an autoconf-gener
On Sep 17, 2006, at 2:51 PM, Jack Howarth wrote:
I am curious if there are any plans to support
the functionality provided by lipo on MacOS X to
create a python release that could operate at either
32-bit or 64-bit on Darwin ppc and Darwin intel?
We already support universal binaries for
I am curious if there are any plans to support
the functionality provided by lipo on MacOS X to
create a python release that could operate at either
32-bit or 64-bit on Darwin ppc and Darwin intel? My
understanding was that the linux developers are very
interested in lipo as well as an approach
Brett Cannon wrote:
> As for making the AST branch itself more of a standard, I have talked to
> Jeremy Hylton about that and he didn't like the idea, at least for now.
> The reasons for keeping it as "experimental" in terms of exposure at the
> Python level is that we do not want to lock ourse
Fabio Zadrozny wrote:
> On 9/16/06, Lawrence Oluyede <[EMAIL PROTECTED]> wrote:
>>> I think that this change should be presented at
>>> http://docs.python.org/dev/whatsnew/whatsnew25.html
>> It's already listed there:
>> http://docs.python.org/dev/whatsnew/other-lang.html
>>
>
> Thanks... also, I
Talin wrote:
> Nick Coghlan wrote:
>> As for the reason: it makes it possible to use the same style for classes
>> without bases as is used for functions without arguments. Prior to this
>> change, there was a sharp break in the class syntax, such that if you got
>> rid
>> of the last base clas
28 matches
Mail list logo
