Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-22 Thread Tim Peters
[Neal Norwitz] It looks like %zd of a negative number is treated as an unsigned number on OS X, even though the man page says it should be signed. The z modifier, when applied to a d or i conversion, indicates that the argument is of a signed type equivalent in size to a size_t. It's not

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-22 Thread Neal Norwitz
On 9/21/06, Tim Peters [EMAIL PROTECTED] wrote: Well, to be strictly anal, while the result of (size_t)-123 is defined, the result of casting /that/ back to a signed type of the same width is not defined. Maybe your compiler was doing you a favor ;-) I also tried with a cast to an

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-22 Thread Ronald Oussoren
On Friday, September 22, 2006, at 08:38AM, Neal Norwitz [EMAIL PROTECTED] wrote: On 9/21/06, Tim Peters [EMAIL PROTECTED] wrote: Well, to be strictly anal, while the result of (size_t)-123 is defined, the result of casting /that/ back to a signed type of the same width is not

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-21 Thread Jack Diederich
The python binary is out of step with the test_itertools.py version. You can generate this same error on your own box by reverting the change to itertoolsmodule.c but leaving the new test in test_itertools.py I don't know why this only happened on that OSX buildslave On Thu, Sep 21, 2006 at

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-21 Thread Grig Gheorghiu
On 9/21/06, Jack Diederich [EMAIL PROTECTED] wrote: The python binary is out of step with the test_itertools.py version. You can generate this same error on your own box by reverting the change to itertoolsmodule.c but leaving the new test in test_itertools.py I don't know why this only

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-21 Thread Jack Diederich
On Thu, Sep 21, 2006 at 03:28:04PM -0700, Grig Gheorghiu wrote: On 9/21/06, Jack Diederich [EMAIL PROTECTED] wrote: The python binary is out of step with the test_itertools.py version. You can generate this same error on your own box by reverting the change to itertoolsmodule.c but leaving

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-21 Thread Grig Gheorghiu
On 9/21/06, Jack Diederich [EMAIL PROTECTED] wrote: On Thu, Sep 21, 2006 at 03:28:04PM -0700, Grig Gheorghiu wrote: On 9/21/06, Jack Diederich [EMAIL PROTECTED] wrote: The python binary is out of step with the test_itertools.py version. You can generate this same error on your own box by

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-21 Thread Grig Gheorghiu
On 9/21/06, Grig Gheorghiu [EMAIL PROTECTED] wrote: On 9/21/06, Jack Diederich [EMAIL PROTECTED] wrote: On Thu, Sep 21, 2006 at 03:28:04PM -0700, Grig Gheorghiu wrote: On 9/21/06, Jack Diederich [EMAIL PROTECTED] wrote: The python binary is out of step with the test_itertools.py version.

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-21 Thread Martin v. Löwis
Jack Diederich schrieb: Faced with the choice of believing in a really strange platform specific bug in a commonly used routine that resulted in exactly the failure caused by one of the two files being updated or believing a failure occurred in the long chain of networks, disks, file

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-21 Thread Jack Diederich
On Fri, Sep 22, 2006 at 06:09:41AM +0200, Martin v. L?wis wrote: Jack Diederich schrieb: Faced with the choice of believing in a really strange platform specific bug in a commonly used routine that resulted in exactly the failure caused by one of the two files being updated or believing a

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

2006-09-21 Thread Neal Norwitz
On 9/21/06, Jack Diederich [EMAIL PROTECTED] wrote: I should leave the tounge-in-cheek bombast to Tim and Frederik, especially when dealing with what might be an OS machine specific bug. The next checkin and re-test will or won't highlight a failure and certainly someone with a g4 will try