3-JUL-2024

0941

I think the UI is in a good spot to leave for a minute while I bring in some of the components that need the UI. The first round is a simple UCI REPL; I should be able to type raw UCI into the UI and have it respond (probably with dummy info for now). It should expose an option “current engine” that points to the relevant backend by name.

I also managed to re-introduce an en passant bug, I’m going to leave it for now; I started on a refactored movegen module before I put the project down last time, I think that’s probably the ‘right’ way to chase out these bugs, and I think having a better debugging tool will help a lot in figuring out what the issue is.

1145

I’ve roughed in the UCI repl a bit, just the parsing stuff. I’m going to get a basic parse-to-an-enum, then refactor to use Hazel types for Moves/etc. Those are generic enough that it should help with forwarding UCI around but also being ergonomic enough to use directly in the UI and for Hazel.

1320

Fully roughed in, no type fanciness yes, but I’ll enrich the parsing as I need it. I think the next step is to get the OCI connection started up, and then work on a backend which proxies the OCI connection to the backend engine.

1335

I think I need to learn tokio. I keep hemming and hawing about just writing my own threadpool thing, but I should probably learn the ‘real’ tool instead of rolling my own here. Time for more tutorial reading, I guess.

Or not, this article suggests that maybe threads are just fine. I don’t know that this needs to be such a giant thing, I’m comfortable having lots of otherwise idle threads with connections open. I suppose maybe a better approach would be to have a thread-per-engine, and then keep them in a pool. I suppose I could have Grid be abstract across any Engine, and then have Engine be a trait which, e.g., HazelEngine might implement.

The trait would just expect a way to send it UCI messages and recieve them in return. Eventually I can place another variant which supports, e.g., a protobuf-defined API or something. The API would have a raw_uci message so you could always fall back to just parsing UCI, but for richer queries I could extend it.

I think I’ll skip tokio for now and stick with threads until it starts hurting.

2143

Definitely a pass on tokio, the docs say that I’m probably not the right case for it right now, and if I can go with a threaded approach, go with a threaded approach, so that sounds like a good reason to me.

I’m going to work on getting the ‘Driver’ part of Hazel working, that’s going to be the thing that actually takes UCI messages and plays the game. My goal is going to be to integrate the UCI parser I just wrote with the Game struct, and implement whichever commands feel easy and bail on the rest. That should be enough for me to hook hazel up to an OTS GUI, and then I can get something relatively bug free working on a known-good GUI before working to implement my own. I can also hopefully hook up my UI and the OTS one at the same time, so I can compare when debugging.