30-JUN-2024

0102

Been working on the EP_CAPTURE issue, I ended up just deleting the implementation, walking away for a bit, then reimplementing. I ended up doing it a slightly different way than the inital bit mangling trick I was trying, and I think I’m just going to leave it as is for now. I think the bit mangling will be faster and I was probably just doing it wrong, but I can leave the optimization for another day.

I added some better error output for the unrecoverable error branch, and managed to get the perft test running (but getting a different count of positions than it should).

I need to set up some kind of integration test w/ a known-good engine. I think I might try switching off the movegen for a bit and work on the UCI implementation and maybe a little TUI for debugging. I could then ostensibly get it and stockfish talking to each other, and it could then start perfting and having SF verify the results, so I can start to see the game state that led to it overcounting.

In any case, for now, EP_CAPTURE I think is working, and I won’t really be able to track down the bug until I build up some better tools for debugging.

1838

A rough design:

Hazel: The main thread, spawns: - Grid: A list of engine instances, defaulting to Hazel, but allowing arbitrary UCI connections to other engines. - UI: The UI thread - Race Control: Which sends commands between engines / the UI, may be part of the main Hazel thread instead of it’s own thing, not really sure.

The idea is to let Hazel have a sort of ‘tournament management’ feature, where it can run multiple different engines and manage games between them, and also allow for deep integration tests as above.

The Engine Instance is a UCI Socket for communicating to the engine, which Hazel manages and the UI allows selection between, messages are proxied down to the actual engine instance, which is just running it’s own UCI client reading from the same socket.