17-DEC-2024

1042 - srailimaf

This is idle thoughts about how to break up what’s in hazel rn. I don’t think I want to keep everything in the same codebase longterm, since large parts of it will become quite static (e.g,. the PGN parser, the UCI parser, etc); and other parts are really not particularly chess related (the Log type, in particular, and the UI to some extent may be worth separating, if only for namespace friendliness).

This would leave the core chess functionality in the main hazel crate.

Right now my compile times are fine, couple seconds, maybe a minute or two for a fresh build, but I can see the writing on the wall. It’s also just getting cluttered in the project, so I’m itching to organize.

I think the Log type is going to be the first out, especially because I expect it will see re-use outside of this project, and because I have some ideas on how to extend it to be more useful in terms of how it manages the data it stores. In particular, I want to extend it to dynamically load segments into and out of the log, so that I can store logs bounded by disk space and not memory. To do this, I’ll need to have the Cursor types be responsible for holding the Log data in memory, and the main Log type will instead use a WriteHead to write to an abstract log which is stored in segments on disk. Finally making it all async would be nice, but I’m not sure if this design’ll scale to that. Probably a single-writer multi-reader would be ‘fine’, or some kind of segment-based locking, IDK.

It’s not a new idea but it’s a very nice one, and it seems like it’d be fun to build.