Scorpio bitbases question

[Daniel Shawul]

Weird. Apparently FireFox is not able to download .7z files; it tries to display them in stead (giving gibberish, of course). In fact it crashed my network to the point where I could only recover by disconnecting the power to my router, as even the WiFi had disappeared from the air.

Isn't there another source? (Preferably with just the DLLs. I already have all the data files installed.)

Unfortunately the format has changed for 6 men, so the old data files do not work with the new dlls. That is why I want to have the dlls and data files together all the time. There is no 'load_egbb_xmen' in the old dlls so your code would crash with those, but not with the new ones. Here is a link for 4 men with the dlls inside. It doesn't have a 32 bit linux binary, but it has the rest. https://dl.dropboxusercontent.com/u/552 ... bb4men.zip

[hgm]

OK, thanks. I just want this for testing, so 4-men should be good enough. And indeed it works now: I get valid pointers from the GetProcAddress calls, and can do probing without crashing.

Unfortunately the probe returns a _NOTFOUND code (99999). From the winboard.debug file:

Code: Select all

move to book user: 3
EGT formats: scorpio:C:\cygwin\home\egbb4
library path: C:\cygwin\home\egbb4\egbbdll.dll
procs: 100043a0 10004800
loaded C:\cygwin\home\egbb4
   piece    square
0.      1    24
1.      6    34
2.      7    44
3.      0     0
4. 3605962 12174334
5. 4561527 21315016
6. 2684632     0
7.    512 12173330
probe, res=99999

This prints the contents of the piece and square arrays (the latter in octal), and the idea was to try a position from KPK. 1 and 7 should be Kings, 6 a white Pawn.

Is there anything obviously wrong with this?

[Daniel Shawul]

If your system is 64 bit you should load egbbdll64.dll instead of egbbdll.dll.

[hgm]

No, that doesn't help. It just produces an error popup "Could not load EGBB library".

(I put in error messages now:

Code: Select all

fprintf(debugFP, "library path: %s\n", buf);
	lib = LoadLibrary(buf);
	if(!lib) { DisplayError("could not load EGBB library", errno); return 13; }
	loadBB = (PLOAD_EGBB) GetProcAddress(lib, "load_egbb_xmen");
	probeBB = (PPROBE_EGBB) GetProcAddress(lib, "probe_egbb_xmen");
fprintf(debugFP, "procs: %x %x\n", loadBB, probeBB);
	*p = NULLCHAR; loadBB(buf, 64*1028, 2); // 2 = SMART_LOAD
fprintf(debugFP, "loaded %s\n", buf);
	loaded = 1; // success!

The path seemed OK

Code: Select all

EGT formats: scorpio:C:\cygwin\home\egbb4
library path: C:\cygwin\home\egbb4\egbbdll64.dll

,
so I guess it is just not possible to call a 64-bit DLL from a 32-bit exe.)

Btw, how can I get the 32-bit .so file? There is no source code in the 4-men zip.

[Daniel Shawul]

My system is 64-bit and it works for me after I load egbbdll64.dll. Also compiling a 32-bit binary and loading egbbdll.dll works as well. All the necessary dlls will be available with in the package, but you have to make sure you load the right one. For 32-bit exes, load either egbbdll.dll or egbbso.so and for 64-bit exe load either egbbdll64.dll and egbbso64.so. The dll basically becomes part of the engine at startup, so there can't not be a mismatch in any way.

Did you get the egbb 4.0 loaded message as shown below? This message is printed by the dll once it is mapped to the engine binary.


For the position you are trying to probe I get the following
[D] 8/8/4k3/2P5/K7/8/8/8 w - - 0 1

Code: Select all

feature done=0
ht 4194304 X 16 = 64.0 MB
eht 1048576 X 8 = 8.0 MB
pht 32768 X 24 = 0.8 MB
processors [1]
EgbbProbe 4.0 by Daniel Shawul
Egbbs loaded !
loading_time = 1s
setboard 8/8/4k3/2P5/K7/8/8/8 w - - 0 1
d

        ________
        ________
        ____k___
        __P_____
        K_______
        ________
        ________
        ________
8/8/4k3/2P5/K7/8/8/8 w - - 0 1
score
bitbase_score = 5488
go
[st = 11114ms, mt = 29250ms , hply = 0 , moves_left 10]
2 5374 0 13  Ka4-b5 Ke6-d5
3 5368 0 55  Ka4-b5 Ke6-d5 c5-c6
4 5304 0 124  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-e6
5 5305 0 208  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-e6 c5-c6
6 5258 0 271  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8
7 5251 1 330  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-d6
8 5167 1 380  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-b8 Kc6-d7 Kb8-b7
9 5138 1 500  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6
10 5138 1 564  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6
11 5138 2 648  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6
12 5138 2 739  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6
13 5138 2 907  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6
14 5138 3 1076  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6
15 5138 3 1277  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6
16 5138 3 1491  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6
17 5138 4 1774  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6
18 5138 4 2110  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6
19 5138 4 2504  Ka4-b5 Ke6-d7 Kb5-b6 Kd7-c8 Kb6-c6 Kc8-d8 Kc6-b7 Kd8-d7 c5-c6

[hgm]

My system is 64-bit and it works for me after I load egbbdll64.dll. Also compiling a 32-bit binary and loading egbbdll.dll works as well. All the necessary dlls will be available with in the package, but you have to make sure you load the right one. For 32-bit exes, load either egbbdll.dll or egbbso.so and for 64-bit exe load either egbbdll64.dll and egbbso64.so. The dll basically becomes part of the engine at startup, so there can't not be a mismatch in any way.

OK, my system is 64 bit, but the WinBoard binary is 32-bit, so I was using the 32-bit DLL, and that did not give me any loading problems. The probe gives 99999, however.

Did you get the egbb 4.0 loaded message as shown below? This message is printed by the dll once it is mapped to the engine binary.

Well, I suppose the DLL prints that on the standard output, but in WinBoard the standard output is not open, so there is no way I could ever see that. In XBoard I would be able to see it (when started from a terminal), but I haven't found a way to make the 32-bit .so file yet. (Only from the zip file on your website, but you say that is obsolete.)


For the position you are trying to probe I get the following
[D] 8/8/4k3/2P5/K7/8/8/8 w - - 0 1

Well, the position was actually a different one. (The square numbers were octal, so that the digits immediately correspond to rank and file, so they were all in the e-file (=4).) But that should matter very little (unless it happened to be a broken position, which I am pretty sure it wasn't).

[Daniel Shawul]

You can download the coad at github https://github.com/dshawul/egbbdll
Once you compile the 32-bit linux binary, please send it to me so that I can add it to the package. I don't want anyone compiling the dlls themselves ever . It just complicates matters for me because of changed formats etc. The idea was that people will download the whole package and use it, so if it doesn't work on any system the blame lies on the engine.

[hgm]

OK, the zip file I downloaded from github compiled without problems. I uploaded the .so file to http://hgm.nubati.net/egbbso.so .

I can load it with the 4-men set, and it does actually print the two lines

Code: Select all

EgbbProbe 4.0 by Daniel Shawul
Egbbs loaded!

But the result is the same; the probe, called with {1,6,7,0} and {20,28,36,0} returns 99999.

(Going to bed now, 1:15 am here...)

[Daniel Shawul]

OK, the zip file I downloaded from github compiled without problems. I uploaded the .so file to http://hgm.nubati.net/egbbso.so .

I can load it with the 4-men set, and it does actually print the two lines

Code: Select all

EgbbProbe 4.0 by Daniel Shawul
Egbbs loaded!

But the result is the same; the probe, called with {1,6,7,0} and {20,28,36,0} returns 99999.

(Going to bed now, 1:15 am here...)

Thanks for the linux 32 bit linux binary. In return I have found your bug. The egbbprobe is loaded alright, but your loadBB function passes 'buf' which has the name of the dll attached to it. If the dll's name is D:\egbb\egbbdll.dll, you should pass the directory name D:\egbb\ with a slash attached to it. So it was not loading any bitbases, even though the dll was attached to Winboard exe successfully. I guess I should have let it print, this number of bitbases are loaded so that such problems would be obvious from the get go.

Btw you can try to use probe_egbb_fen(char*) but your current implementation is fine as it is. Also if you are sharing code between xboard/winboard you might want to have the defines as below, so that you won't forget to change names. Winboard is always 32-bit so I removed the 64 bit names

Code: Select all

#ifdef _MSC_VER
#		define EGBB_NAME "egbbdll.dll"
#else
#		define EGBB_NAME "egbbso.so"
#endif

#ifndef _MSC_VER
#    define HMODULE void*
#    define LoadLibrary(x) dlopen(x,RTLD_LAZY)
#    define GetProcAddress dlsym
#endif

[hgm]

In return I have found your bug. The egbbprobe is loaded alright, but your loadBB function passes 'buf' which has the name of the dll attached to it. If the dll's name is D:\egbb\egbbdll.dll, you should pass the directory name D:\egbb\ with a slash attached to it.

Ah thanks, that did it! I was stripping of the DLL name with *p = NULLCHAR;, but I was also stripping the slash. I now changed that to p[1] = NULLCHAR;, and then it worked perfectly.

So it was not loading any bitbases, even though the dll was attached to Winboard exe successfully. I guess I should have let it print, this number of bitbases are loaded so that such problems would be obvious from the get go.

Indeed, that would be very helpful.

Anyway, now that it works I can take care of the details of where to put the #defines to make it work on all platforms. Thanks again!