Life In 19x19

PS: This is still a Cygwin version. Though I got this version to compile without errors under MSYS2/MinGW (which could make the engine faster, due to removal of the Cygwin layer), that version just froze up as soon as it was its turn to move.

Did you try just from the command line? There's some ...

Pull request with DOUBLE fix for pachi: https://github.com/pasky/pachi/pull/41

Checks are failing due to misconfigured Travis CI job, it seems.

Sure, my low-end Celeron doesn't support all the instructions your CPU does.

cpuz.png

Well, if nobody else complains, you don't need to recompile the whole thing -- my own Windows-native version works fine for me (except max_tree_size cannot be bigger than 4095, but that I'll fix in the code ...

native mingw does the same thing as Visual C++: unsigned long is 4 bytes even in 64-bit version (and that is perfectly standards-compliant...) I'll [eventually] do the patch for pachi and will submit it upstream; I think the proper type for max_tree_size is size_t but it opens some kind of Pandora ...

Oh-oh, max_tree_size in the code is unsigned long, which is 4 bytes in Windows: https://msdn.microsoft.com/en-us/library/s3f49ktz.aspx. So my setting of 4096 effectively turns into 0. I'll patch the code to unsigned long long, and will report the results

Aha, uncommenting "DOUBLE=1" in Makefile (which I didn't) breaks random.c compilation for me; it works otherwise. And it can be explanation why my version does not handle tree size as big as 4Gb; need to check the code.

Looks like "DOUBLE" is an unfortunate naming choice; it clashes with some ...

Aha, uncommenting "DOUBLE=1" in Makefile (which I didn't) breaks random.c compilation for me; it works otherwise. And it can be explanation why my version does not handle tree size as big as 4Gb; need to check the code.

Looks like "DOUBLE" is an unfortunate naming choice; it clashes with some ...

Aha, uncommenting "DOUBLE=1" in Makefile (which I didn't) breaks random.c compilation for me; it works otherwise. And it can be explanation why my version does not handle tree size as big as 4Gb; need to check the code.

Babelardus wrote:Note: Pachi has been downloaded 31 times as of today, and I have received no problem reports as of yet. Fuego, especially version r2029, of which no official binary exists (let alone a 64-bit version) outside of mine, is just as popular though.

Your fuego 64-bit build works for me, no crashes.

Do you have your own version of Cygwin installed and included in your path? If you are just starting Pachi, without the DLL's in the folder, it'll start searching for them in your path. If you have a different version of Cygwin installed than I have, it will crash. It is indeed complaining about ...

I've tried your version, and it crashes for me immediately, here's .stackdump

Exception: STATUS_ILLEGAL_INSTRUCTION at rip=00100421EB5
rax=0000000000000000 rbx=00000001006059C0 rcx=0000000100451D9D
rdx=0000000000000002 rsi=000000010044C870 rdi=00000000FFFFBA70
r8 =0000000000000000 r9 ...

Yes, my version is a 64-bit one, I happen to know a thing or two about compilers and file command -- since year 1995 or so

I guess there's some incompatibility in some data type size between Windows and Cygwin; something in windows is probably limited in bit width, that's why tree_size of 4096 ...

This is strange -- I've compiled 64-bit version too (wrote down my steps here: http://www.lifein19x19.com/forum/viewtopic.php?p=205172#p205172), but it loads books / patterns happily with '-d 0'. On the contrary, without "-d 0" it spits out some noise about found book positions, and Drago cannot ...

I've compiled my own 64-bit version on Windows 10 in a very easy way. The steps are below.

1. Install msys2: m (when you'll follow the instructions, at some moment you will see the message that you need to change shortcuts for running msys; pay attention and comply!). Do follow instructions to the ...