vdbergh
vdbergh
I guess it is a windows problem. Windows cannot handle UTF-8 path names (the most common encoding on the planet). So one has to convert first to UTF-16. First result...
The worker could send the short path name to SF: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getshortpathnamew if non-asci characters are detected in a path name (is it only the NNUE path?).
Ok. Not allowing non asci characters in filenames probably excludes a sizable part of the world's population though. Nowadays people expect unicode to "just work". EDIT. Fixed typo.
I really think this is fixable on the worker's side. This is the cuplrit ``` option.EvalFile=/home/fishtest/fishtest/worker/testing/nn-13406b1dcbe0.nnue ``` The current directory is `/home/fishtest/fishtest/worker/testing`. So there doesn't seem to be any need...
Where is the code in SF that searches for the net?
``` vector dirs = { "" , "" , CommandLine::binaryDirectory , stringify(DEFAULT_NNUE_DIRECTORY) }; ``` If I interpret this correctly it will first search in the current directory. Which is what...
No, the empty string "" is in the second place. That should be the current directory.
If it doesn't work we can also embed the net (first copy the downloaded/cached net to the build directory).
It is fixed on the worker’s side now. However it might still be a good idea to trace the cause of the crash in SF and print an error message...
I guess SF doesn't actually crash but just doesn't find the net and then exits. That would be perfectly fine of course.