Finished the first iteration of the Rust backend, passed some tests, and linked it to the UI. It definitely works, for the signature GoL patterns (blocks, loaves, gliders, etc.) are emerging, but the system is still quite unable to handle the 1000x1000 grid I had hoped for. The bottleneck may simply be the PyO3 interface, or (very likely) there may be much room for optimization in my Rust code.
Wrote most of the Python frontend using Pygame (graphics are neither my forte nor my passion, and I wanted to focus on the internal logic). Also began working on a Rust struct accessible via PyO3 which encapsulates and mutates the GoL grid. This is really my first go at PyO3 and Maturin (or any cross-language project, for that matter), but it seems Python and Rust have been communicating nicely so far.
Finally published to crates.io.
Serious refactor - DFS + pruning was actually not an efficient solution to the problem; simple character counting using HashMaps much faster.
Finished first iteration of solver; working on optimizations.
Successfully implemented depth-first search to generate all possible anagrams of the scrambled input. Used a pre-computed HashSet of valid prefixes to quickly prune any branches that wouldn’t lead to valid English words.
Implemented CLI interface using Clap. Added –verbose flag for logging and –include-partial for words that do not use all available letters.
Initial optimizations include removing words that could never be made using the available letters- that is, words that are too long or contain invalid letters.
Further optimizations include using concurrency when reading the file and using smart pointers to avoid excessive cloning. Also considering the possibility of iterating over candidate WORDS and determining whether they are a valid solutions instead of using combinatorics.
