IRC channel logs


back to list of logs

***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>anyone has a 32 bit system?
<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
<bonz060>efraim: thanks
<civodul>bonz060: oh, well done!
<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>Welcome elflng!
<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>-j is a parallel build, yes?
<efraim>It is
<elflng>i wouldnt try that for code that predates multicore chips :)
<elflng>2004 is python2.4
<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>and (2 ** 31) * (2 ** 33) ?
<elflng>and (2 ** 2) * (2 ** 62) ?
<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>>>> (2 ** 31) * (2 ** 31)
<elflng>notice the difference on the 32 bit machine and the 64 bit?
<elflng>(that was from the 32 bit)
<elflng>>>> (2 ** 31) * (2 ** 31)
<elflng>>>> 2 ** 64
<elflng>>>> 2 ** 63
<elflng>>>> 2 ** 65
<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.
<elflng>(afk a bit, teaching)
<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.
<bonz060>elflng: thanks for all the help!
<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>its the same problem.
<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.