PyPy 3 for Windows 64-bit systems - no download link available
Hello support-team, it is a computerchess-related topic e.g. running Python 0.99.3 https://github.com/pychess/pychess/releases/download/0.99.3/pychess-engine-2... outsite its own graphical user interface https://github.com/pychess/pychess/releases/download/0.99.3/pychess-0.99.3-w... on an external front-end like WinBoard Interface http://www.open-aurec.com/wbforum/viewtopic.php?f=19&t=51528 http://www.open-aurec.com/wbforum/viewtopic.php?f=19&t=51528 with protocol CECP http://hgm.nubati.net/CECP.html A detailed description (with all necessary configurations) how to accomplish this problem is hosted on my Google Drive chess collection https://drive.google.com/drive/folders/0B5Ao6h_yMCl6ay04RjVtUDVTUG8 > folder Pychess_20180928 Günther Simon from Germany http://www.rwbc-chess.de/ http://www.rwbc-chess.de/ reported that PyPy for Windows caused problems to run PyChess engine in contrast to WinPython or Python for Windows 3. Best wishes, Norbert PyChess 0.99.3 - WinBoard GUI * Download WinPython 3.6.30Qt5 x64 (390 MB) https://github.com/winpython/winpython/releases/download/1.9.20171031/WinPyt... https://github.com/winpython/winpython/releases/download/1.9.20171031/WinPyt... and install it on a drive e.g. C:\ This procedure can take more than 30 minutes. * Create a directory on C:\Engines\WB\PyChess_20180928 with the following working components:
InBetween (configuration settings)
PyChess_20180928 Editor (text document)
PyChess_20180928 = renamed InBetween http://web.archive.org/web/20100922051419/http://home.online.no/~malin/sjakk... http://web.archive.org/web/20100922051419/http://home.online.no/~malin/sjakk...
PyChess Zip application
* Run WinBoard GUI > Load first engine > PyChess_20180928.exe (without any commandline-parameters) under protocol WB-2 It will not run with PyPy https://pypy.org/download.html https://pypy.org/download.html on Windows, because there are only 32-bit PyPy installs for Windows available, while at least latest pychess.pyz seems to rely on some 64-bit Python stuff, which throws some known exceptions (according to Günther´s Google research) in this case.
Hi, On Fri, 19 Oct 2018 at 12:23, <norbert.raimund.leisner@arcor.de> wrote:
It will not run with PyPy https://pypy.org/download.html on Windows, because there are only 32-bit PyPy installs for Windows available
PyPy is not available for 64-bit Windows. See http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit... for technical information. It's not high priority for us, which means we won't do it unless we're getting a sizeable grant or contract. A bientôt, Armin.
Probably because 32-bit is still supported by Windows, whereas Fedora discontinued supporting 32 bit in 2016, and OSX stopped supporting 32 bit recently as well. Easier to have just one version of Windows rather than supporting two versions, and 32-bit is compatible with all Windows, whereas 64-bit is not. Not sure if that’s the actual reason, but it seems to be the most likely one to me. If you’re asking why Windows still supports 32-bit, I can’t really help you there. ----------------- Aidan
On 23/10/18 12:13 am, Barry wrote:
As Armin said previously, PyPy supporting win64 is work, since sizeof(long) != sizeof(void*) Seehttp://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit... for technical information. It's not high priority for us, which means we won't do it unless we're getting a sizeable grant or contract.
On 10/22/2018 17:13, Barry wrote:
From what I understand the underlying cause is because 64bit windows (or more specifically the visual studio C compiler) uses an LLP64 (IL32P64) data model* while most 64bit unix based systems use LP64 (I32LP64). The previously linked article on getting a 64bit windows pypy talks about the size difference for long but doesn't spell out the data model explicitly. Hopefully that helps clear up where the underlying issue comes from. Brian Haskin * https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
Hi, On Mon, 22 Oct 2018, Barry wrote:
as I'm struggling with Windows at the moment, I may have an answer ... I find that for CPython3, sys.maxsize is (2**31)-1 on 32-bits Python and (2**63)-1 for 64-bits Python builds. With sys.maxint being a Python2 thing, it may be different there, but it seems 3 at least is perfectly consistent. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
On +2018-10-27 11:55:11 -0700, wlavrijsen@lbl.gov wrote:
Does (2**63)-1 work because size is unsigned (presumably?) and (2**63) is then valid as an intermediate value before subtracting 1, whereas for a signed maxint, the intermediate value would have to be specialcased or the value written maybe like (2**62-1)+(2**62) ? Or does it involve a bigint representation somewhere? Regards, Bengt Richter
The sys.maxint vs sys.maxsize difference is the first thing that appears at http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit... There is a nice plan there to transition to a win64 python2 (which we need since rpython is written in python2) where sys.maxint == sys.maxsize == 2**63-1, and to continue from there to a pypy2 that can translate rpython. Matti
Hi, On Fri, 19 Oct 2018 at 12:23, <norbert.raimund.leisner@arcor.de> wrote:
It will not run with PyPy https://pypy.org/download.html on Windows, because there are only 32-bit PyPy installs for Windows available
PyPy is not available for 64-bit Windows. See http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit... for technical information. It's not high priority for us, which means we won't do it unless we're getting a sizeable grant or contract. A bientôt, Armin.
Probably because 32-bit is still supported by Windows, whereas Fedora discontinued supporting 32 bit in 2016, and OSX stopped supporting 32 bit recently as well. Easier to have just one version of Windows rather than supporting two versions, and 32-bit is compatible with all Windows, whereas 64-bit is not. Not sure if that’s the actual reason, but it seems to be the most likely one to me. If you’re asking why Windows still supports 32-bit, I can’t really help you there. ----------------- Aidan
On 23/10/18 12:13 am, Barry wrote:
As Armin said previously, PyPy supporting win64 is work, since sizeof(long) != sizeof(void*) Seehttp://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit... for technical information. It's not high priority for us, which means we won't do it unless we're getting a sizeable grant or contract.
On 10/22/2018 17:13, Barry wrote:
From what I understand the underlying cause is because 64bit windows (or more specifically the visual studio C compiler) uses an LLP64 (IL32P64) data model* while most 64bit unix based systems use LP64 (I32LP64). The previously linked article on getting a 64bit windows pypy talks about the size difference for long but doesn't spell out the data model explicitly. Hopefully that helps clear up where the underlying issue comes from. Brian Haskin * https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
Hi, On Mon, 22 Oct 2018, Barry wrote:
as I'm struggling with Windows at the moment, I may have an answer ... I find that for CPython3, sys.maxsize is (2**31)-1 on 32-bits Python and (2**63)-1 for 64-bits Python builds. With sys.maxint being a Python2 thing, it may be different there, but it seems 3 at least is perfectly consistent. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
On +2018-10-27 11:55:11 -0700, wlavrijsen@lbl.gov wrote:
Does (2**63)-1 work because size is unsigned (presumably?) and (2**63) is then valid as an intermediate value before subtracting 1, whereas for a signed maxint, the intermediate value would have to be specialcased or the value written maybe like (2**62-1)+(2**62) ? Or does it involve a bigint representation somewhere? Regards, Bengt Richter
The sys.maxint vs sys.maxsize difference is the first thing that appears at http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit... There is a nice plan there to transition to a win64 python2 (which we need since rpython is written in python2) where sys.maxint == sys.maxsize == 2**63-1, and to continue from there to a pypy2 that can translate rpython. Matti
participants (9)
-
aidanlakshman＠gmail.com -
Armin Rigo -
Barry -
Barry Scott
-
Bengt Richter -
Janzert -
Matti Picus -
norbert.raimund.leisner＠arcor.de -
wlavrijsen＠lbl.gov