***nckx is now known as nckx-
***nckx- is now known as nckx
<PurpleSym>re maneage: Discounting Guix because it requires root and then proposing to use VMs (temporary relocation) is a weird argument. If you can use a VM, you’ll have root too. <zimoun`>PurpleSym: it should be an aposteriori argument because discounting Guix is hard. ;-) <bonz060>I want to try to force build python-24 and see if 2 ** 64 returns the correct thing. <bonz060>Someone from #lisp-cafe pointed that his python2.4 version lying around works just well... but on 64-bit systems, there appears to be overflow problems... <bonz060>I'm thinking force-building python2.4 for 32 bits... still haven't figured out how to do that yet. <efraim>add a '--system=i686-linux' to the build command <bonz060>Thanks. Also I've found the actual bug... It's in Objects/intobject.c L626 <elflng>shalom, bonz060 asked me to join as im going through the python2.4 code and have a working (32 bit) python2.4 executable in an ancient backup. <bonz060>efraim: I'm getting a `command "make" "test" "-j" "4" failed with status 2`. I saw some where that you commented that python-2.4 does not support '-j' <elflng>i wouldnt try that for code that predates multicore chips :) <elflng>bonz060: can you repost here what you posted about the integer tests i asked? <bonz060>2 ** 63 = -9223372036854775808 ; 2L ** 64 = 18446744073709551616L ; 2 ** 64L = 18446744073709551616L ; 2 ** 33 = 8589934592 ; <-- That's from the x86_64 build. I've got some build errors on the 32 bit build, so I'm troubleshooting that hehe. <elflng>so its clear that the problem is in intobject and not in longobject <elflng>which means the problem is one in double conversio <elflng>which youll also see when doing mults <elflng>if you do (2 ** 31) * (2 ** 31) ... <elflng>theres a lot in the python2.4 that subtly (or not so subtly) relies on it being a 32 bit machine. <elflng>so basic question about the project - are you allowed to modify the python source itself? <elflng>if so, the easiest solution would be to replace the intobject with longobject, as theyre going to be the same for all intents and purposes on a 64 bit machine <bonz060>(2 ** 31) * (2 ** 31) = 4611686018427387904 and (2 ** 32) * (2 ** 32) = 18446744073709551616L <elflng>im trying to see where the longs are triggered correctly and where they arent. <bonz060>(2 ** 31) * (2 ** 33) = 18446744073709551616L ; (2 ** 2) * (2 ** 62) = 18446744073709551616L <elflng>notice the difference on the 32 bit machine and the 64 bit? <elflng>these are all _correctly_ switching to longs, because the double conversion is working correctly. <elflng>but a double conversion will not work correctly for a 64 bit int :) <elflng>so ... again, are you allowed to modify the python source directly? <elflng>if so, this is possible to fix, if not, im not sure if it will be without a lot of extra unpleasantness. <bonz060>elflng: Yeah you can. You could create a patch for that and then apply it when building. <elflng>wonderful. so the easiest patch is, as stated, to make everything longs to start with. <elflng>the second is to totally change around how ints do exponentiation. more on that later as there are a huge number of pitfalls, some of which have been commented already in the code and the history, and some of which they missed entirely. <elflng>but ill try to return after teaching. :) <bonz060>Cool! I'll try to work something out in the meantime \m/\m/ <elflng>fwiw, the original bug report is incorrect - theres no way that 64 bit python 2.4 on x86_64 will ever give the correct results. as an interesting sidenote - the 32 bit one i have was compiled for 64 bit systems <elflng>so apparently these bugs were known. (the rest of the libraries on this backup are 64bit) <elflng>one more thing before i go: it may pay to look at the 2.6 exponentiation for integers and copy that in as the patch, as 2.6 is 64bit compiled and gives correct results, i think. <elflng>theres a few other functions that will give weird results too. look at anything in intobject that does a double conversion implicitly for the result <bonz060>I've managed to have a successful 32bit build by running: ./pre-inst-env guix build -L ~/projects/guix-past/modules python2@2.4.6 --system=i686-linux. Had to tweak the package definition to disable parallel-tests. Getting weird results too: 2 ** 63 = 0 ; 2 ** 33 = 0 ; 2 ** 32 = 0 ; 2 ** 31 = -2147483648 <bonz060>elflng: I don't think the problem's with how the package is defined... I'm thinking that there's something up with the build flags. I'm wondering if providing libm would have any effect? Thoughts? <elflng>the problem has to do with how its doing the integer->double conversions for certain ops <elflng>its assuming that sizeof(int) < sizeof(long) and sizeof(long) <= sizeof(double) <elflng>i dont know what the env you have is ... when you do 'file python2.4', is it showing up as a 64 bit or a 32 bit executable? <elflng>you probably need a whole 32-bit toolchain to pull this off correctly, if you want to compile it as 32 bit - just changing system wont help. im not sure it respects the system flag, regardless.