Closed tissatussa closed 1 month ago
Thanks for the report! I could be to do with the SPSA tuning support I added recently. It provides a bunch of parameters OpenBench can use to tune the engine. I'll try and reproduce, and see what's going on. The fact that it's temperamental is strange indeed.
..to do with the SPSA tuning support I added recently. It provides a bunch of parameters OpenBench can use to tune the engine..
i'm not familiar with OpenBench, i only know this is used by many engine programmers .. isn't this technique (only) used to develop the engine, tuning weights or parameters ? Does OpenBench also run when the engine runs / starts ? That's not what i imagined. Indeed, also in CuteChess it takes a few seconds before the timer starts counting and Sapling is making its first move, while most engines start immediately .. you should address this, whatever the cause .. programs like SCID expect an engine to 'react' with a short time when starting.
I'll try and reproduce, and see what's going on.
you could provide (an UCI option to) log for debugging : you can add timestamps to actions.
The fact that it's temperamental is strange indeed.
yeah, you're lucky i tried and succeeded to add Sapling to the SCID engine list the way i described .. probably some initialisation is just within a certain time margin ..
isn't this technique (only) used to develop the engine,
You're absolutely right! I should add a compilation flag to disable the options from non dev builds.
in CuteChess it takes a few seconds before the timer starts counting
Tomorrow i'll work on the startup issues. I've not optimised it but I know i can make it much much quicker to startup with a little effort.
I'm going to close this and open a new issue for the startup performance
Using SCID v5.0.2 on Linux, i encounter Sapling v1.1.3 can hardly be added to the engine list. I managed, but it's a story.
To me SCID has always been dubious software, i feel its code contains flaws and probably bugs, although the program works fine overall. I use SCID mainly to let an engine evaluate a position, also by using MultiPV, if an engine has that feature. Like CuteChess, when adding an engine to the list, SCID detects UCI or XBoard and tries to communicate by these protocols, but only UCI options can be set, while CuteChess can also set XBoard options. Some engines, mostly simple ones, are not accepted by SCID : its communication fails and the engine is rejected. Upto v1.1.2 i could add Sapling to SCID, but v1.1.3 suddenly gave trouble : it took a few seconds for SCID to communicate and then a message box came : "Not an UCI engine". But Sapling IS UCI, so there's another cause .. we should always interpret messages, never fully trust them .. here i guess SCID decided so, because initialisation / communication took too long and/or the protocol failed .. i tried to add Sapling v1.1.3 a second time to SCID after closing and again opening this program : it was a success !? But i feel there's something wrong with that Sapling version : it brings SCID to a limit. Maybe whenever i use v1.1.3 to evaluate a position, SCID can suffer the same issue and then Sapling won't run !? This scenario happens with other engines ..
i hope you can imagine what's happening and how to solve this, v1.1.2 has no problems with SCID. btw. could this be related to Issue #11 ?
[ i'm on Xubuntu 22.04 ]