1.7.0b1 - Unittest errors building on Debian powerpc #411
Comments
|
With beta2 some more ResourceWarning but less failure have arrived: Full build log at: https://buildd.debian.org/status/fetch.php?pkg=python-numpy&arch=powerpc&ver=1%3A1.7.0~b2-1&stamp=1348947690 |
|
The last abort was fixed by 5ae12ea, but the @sandrotosi, is there any chance for me to get access to this machine and debug it? Any ideas what could cause those errors? |
|
Agree that this last remaining failure is not release critical. |
|
Ok, I am clearing the milestone. |
|
just to confirm the same failures happen with RC1 |
|
I've asked the installation of the needed depends on this achitecture Debian porterbox; after that, I can try to debug the problem, but I don't know if I can get to something useful; @certik if you prefer, you can ask for access to Debian machine following the steps at http://dsa.debian.org/doc/guest-account/ (of course I'll happily sponsor you). |
|
Ok, so I did some tests: on my machine (amd64) I have this output: but running the same code on the powerpc machine I got: which are, well, quite different :) and the tests confirms it. I don't know how to debug it further: do you have something in mind that I can run on this machine to understand why it's happening? |
|
@sandrotosi but both are just nonsense. It seems like the printing for the imaginary part got mumbled up somewhere badly (its ok in 1.6.) and maybe it reads all a byte shifted or so for this printing. If you can maybe check this for the powerpc too (though I doubt its necessary to be honest), in your example if you check Edit: ah, for the powerpc, also the real printing is messed up, but maybe there its also just the printing, and it just happens to not effect the other for these small numbers. |
|
@seberg indeed (I was just reporting what I had found until then), but it could still mean there's some other thing going fishing; just re-attaching printing a.imag: amd64: powerpc: |
|
Thanks @sandrotosi for debugging it. Typically these things happen when there is some improper handling of the byteorder (swap) inside numpy, we had a similar problem in unicode + python 3.3. However, I would need access to powerpc to debug it. @rgommers, @charris, @njsmith --- do you think we should fix this before the final release, or let it be? I put the 1.7 milestone on it so that we don't forget it. |
|
I'd say it's nice to get fixed but not a blocker. |
|
I don't know if this is a blocker, since it only affects a rare and non native byteorder datatype, but my guess is, that the non-powerpc failures are likely directly related and it is not quite limited to printing, so its possible to start debuggin without powerpc: I wanted to bisect it since it seems to work OK in my numpy 1.6.2, but had problems with the bisecting... |
|
Ok.... I have tracked it down I think, however I have no clue whatsoever what those commits actually changed that have anything to do with it (unless for some reason that code never got executed before?!) and I will leave that for someone else to figure out (and best write tests :-)) --- a/numpy/core/src/multiarray/arraytypes.c.src
+++ b/numpy/core/src/multiarray/arraytypes.c.src
@@ -1825,7 +1825,7 @@ static void
*a++ = *b;
*b-- = c;
}
- a += nn / 2;
+ a += nn;
b = a + (NPY_SIZEOF_@fsize@ - 1);
nn = NPY_SIZEOF_@fsize@ / 2;
for (i = 0; i < nn; i++) {The division by two is wrong here. @sandrotosi maybe you can check if this also fixes all of the powerpc failures? Though I am only half confident, since on first sight that change probably only effects scalars and the failing test seems likely not only scalars. |
|
Man, there really was a pony under there ;) |
|
@seberg thanks for bisect it! I've tried it on the powerpc machine, but sadly it didn't fix it: @certik I do agree with @rgommers that it would be nice to have it fixed, but it should not diverge too much energy from the actual release; I can live with it failing or I'll just skip() it using the platform.machine() or similar. About having access to the machine, please have a look at #411 (comment) |
|
Thanks @seberg! Great job. @sandrotosi, yes I should renew my NM process. In fact I am almost done, but I got really busy and didn't have time to finish it yet. |
|
Sandro, could you print out as strings the results of newbyteorder and byteswap applied separately? Maybe we can see what's going on with the bytes. You could also cheat by defining a special complex by and making arrays of that to make the results easier to understand. |
|
@charris if I understand correctly what you asked (I simply defined first and arange() than called on it the newbyteorder() and then on the result the byteswap() ) here's the output |
|
On Wed, Jan 9, 2013 at 4:14 PM, Sandro Tosi notifications@github.comwrote:
In [5]: s = arange(16, dtype=int8).tostring() In [6]: c = fromstring(s, dtype=complex128) In [7]: c.newbyteorder().tostring() In [8]: c.newbyteorder().byteswap().tostring() You should be able to do that up to a range of 256, so 16 different complex #convert string to hexdef toHex(s): Chuck |
|
So I hadn't understood :) I've modified the code I use to test to: and it's output is now: I split the hex number with a '|' to have the numbers clearly separated. |
|
On Wed, Jan 9, 2013 at 4:52 PM, Sandro Tosi notifications@github.comwrote:
In [4]: c = fromstring(arange(256, dtype=int8).tostring(), dtype=complex256) In [5]: c.shape Note that the complex numbers will look weird as complex numbers, but we Chuck |
|
Ok, I've just used your code, without trying to adapt it to the failing test: |
|
I am putting this to milestone 1.8, or if somebody sends a patch, we can release 1.7.1. |
|
No progress since then, and not a blocker for 1.8, so I'm removing the milestone. |
|
@sandrotosi What is the status of this? |
|
seems to be fixed in 1.8 |
Hello,
when building 1.7.0b1 on Debian unstable powerpc the tests suite returns some error:
Full build log is available at: https://buildd.debian.org/status/fetch.php?pkg=python-numpy&arch=powerpc&ver=1%3A1.7.0~b1-1&stamp=1346419716
Regards,
Sandro
The text was updated successfully, but these errors were encountered: