25-MAR-2025

0012 - atm

I’ve been babysitting a file upload most of the night, good time to kick on the playlist and hack.

I got perft fixed up by finding a silly bug in how I reported length from the tape. It’s a little ambiguous, but at least it works.

I can now fail perft_4 in ~35s, wall-time for the unoptimized test binary, anyway. That’s down from ‘well over 3 minutes’ by a factor of 6 or so, not bad for a HashMap backed cache it only took me a full month to hack together. :)

Next, spring cleaning. I’m going to live with the lack of tests because I’m going to move to rs-test, and start building some fixtures for more efficient testing.

1122 - spring-cleaning-1

Started spring cleaning, this is phase 1, which is just getting the workspace going and starting to split out crates and cleanup dependencies. I’ve done the easiest split so far, into -core and -ui crates; and ran cargo-udeps to clear out unused dependencies. So far, I’ve brought a clean compile (measured by cargo clean ; time cargo build) from ~37s -> ~25s, about a 40% reduction.

I’m going to continue splitting, but the overall workspace is going to look something like:

hazel/
    hazel-core/
        src/
            lib.rs
            some-module/
                mod.rs      # Quickcheck properties in an embedded module "properties"
                test.rs     # Unit tests for the module, driven by rstest fixtures
        test/
            # core-specific integration tests, driven by rstest
    hazel-ui/
        # similar layout to the above, but backed also by `insta`
    hazel-*/            # other crates as needed
    hooks/              # Profile hook programs
    quals/              # Qualification tests, comparing to other engines, establishing Elo, etc.
    benchmarks/         # Performance tests/data gathering
    tests/              # Integration tests

I’m debating following rust-gpu’s example and putting the crates south of a crates/ folder, but for the moment I don’t mind just having them toplevel.

Part of the work so far moved over some ratatui stuff to the ui crate, which changed some apis around, but so far it’s mostly been mechanical.

1150 - spring-cleaning-1

I tried to extract the constants module, but it tangles pretty tightly with other chunks of the system, and extracting them will be a little tricky. It’s actually a little tricky to extract anything right now because it all cross-references pretty freely. I think the way out of that is to push more of the code to rely on the interfaces in src/interface, and have that become hazel-core, and then the other hazel crates rely on the interface, and we have a delightfully decoupled thing. Ultimately this will mean there is a hazel-representation crate which implements the interfaces, and then that should be replacable when I come up with better representations.

He said, full of dumb hope.

1727 - spring-cleaning-1

Okay, two more crates split out, hazel-bitboard has all the pretty static bitboard related stuff, hazel-basic has all the piece/color/square/etc types.

Next I think I’m going to start scaffolding the integration test crate, which can hold the last item in -core’s constants module. I’ll then turn that module into a re-export module maybe, idk.

I want to split the parser stuff as well, as that should reduce more of -core’s dependencies, but getting -basic and -bitboard extracted will make that process easier I think.

The end of all this should be a hazel::toolbox module that I can import and get all the basic constants and types for doing ‘normal’ stuff in hazel the eventual engine crate will have the bits for running the game using the representation provided by that toolbox module.

Separating the parser should eliminate the nom and similar deps. Separating the engine will probably involve separating out the witch thing to it’s own crate as well, and hopefully that’ll leave the types module pretty thin and maybe removable.

So far so good, phase 2 will be rstest and maybe some preliminary benchmarking work.

2227 - spring-cleaning-1

I’m settling in on the split, I’m favoring lots of little crates, perhaps to the point of overkill, but at the moment I prefer to overdo it and pare it back later, it has already paid dividends in terms of clarifying responsibility barriers, and in service to that I’m going to make a little diagram.

It’s in assets/hazel-crates.png if that isn’t rendering for whatever reason.