This makes Speed compile and pass all tests on Windows.
The following chances were made:
Use mmap-go instead of syscall in memorymappedwriter.go.
Import path/filepath instead of path in multiple files to make path-related functionality OS-independent.
And this is something I discovered while working on this. On Unix, you can call remove on a file that is still opened and have everything go smoothly; the file gets deleted when all it's handles are closed. But on Windows, trying to remove a file that's still open results in a The process cannot access the file because it is being used by another process error. Hence, file handles need to be closed at two places in the code.
I also added the printing of an err message in a t.Errorf call which helped me while debugging the third issue.
Coverage remained the same at 78.037% when pulling bad22e79569cea94816709c6b1c7ecfb02fe36d9 on saurvs:master into 91b42e56e578351f7aa848382c59efde30e4bf7a on performancecopilot:master.
Coverage remained the same at 78.037% when pulling bad22e79569cea94816709c6b1c7ecfb02fe36d9 on saurvs:master into 91b42e56e578351f7aa848382c59efde30e4bf7a on performancecopilot:master.
Coverage remained the same at 78.037% when pulling bad22e79569cea94816709c6b1c7ecfb02fe36d9 on saurvs:master into 91b42e56e578351f7aa848382c59efde30e4bf7a on performancecopilot:master.
Coverage remained the same at 78.037% when pulling c777a98b61be361a195d91615636bb1e9b8013e2 on saurvs:master into 91b42e56e578351f7aa848382c59efde30e4bf7a on performancecopilot:master.
Coverage remained the same at 78.037% when pulling 80aaf44e10b1e0cf2f3272dbf06715cc4cbbb666 on saurvs:master into 91b42e56e578351f7aa848382c59efde30e4bf7a on performancecopilot:master.
Coverage remained the same at 78.037% when pulling 19ac04353241e3a6a500962686aa728e3e1f02b3 on saurvs:master into 91b42e56e578351f7aa848382c59efde30e4bf7a on performancecopilot:master.
This makes Speed compile and pass all tests on Windows.
The following chances were made:
mmap-go
instead ofsyscall
inmemorymappedwriter.go
.path/filepath
instead ofpath
in multiple files to make path-related functionality OS-independent.remove
on a file that is still opened and have everything go smoothly; the file gets deleted when all it's handles are closed. But on Windows, trying to remove a file that's still open results in aThe process cannot access the file because it is being used by another process
error. Hence, file handles need to be closed at two places in the code.I also added the printing of an
err
message in at.Errorf
call which helped me while debugging the third issue.