More build options would be appreciated

[laeuter]

I like the speed of your dawg/gaddag builder very much and I would like to use it for my own formats, too. If you like them to be contributed, I'd certainly would like to do so. My formats include

• non-tree formats,
• 2-byte arc formats,
• nodes with headers,
• letter lists external to the arcs,
• letter masks to fast-check which letters are present in a node,
• non-contiguous nodes (arcs are present at offsets according to letter),
• another dawg type for fast-checking orthogonal words,
• node order to improve cache usage further.

Some of the formats stem from my experiments with small dawgs sub-64kb wordlists (the wordlists are unpacked by JS code, and the format is described in the sources), others from my own fast Scrabble move finder (not really public).

Your code in src/build.rs isn't optimally suited for these use cases, but it would certainly be the correct home for my additions. If incorporatable, some changes would be necessary that would change the appearance of the code, and I wanted to ask, what amount is acceptable/appreciated.

[andy-k]

Thanks for reaching out.

You're right that the code in src/build.rs isn't optimally suited to support too many formats. It builds just the few formats that are then used, for example, by movegen.rs in this same repo.

At the moment, I don't understand the benefits of the other formats enough to want to replace the format that build.rs and movegen.rs respectively build and use.

If you find src/build.rs in Rust useful to experiment with your formats, you can certainly fork this repo and build on it. Alternatively, if you're not familiar with Rust, there is a reimplementation of build.rs in C that you may find more helpful instead: https://github.com/andy-k/kwgc (it may not be as good as this Rust version and it might not have full feature parity).

Feel free to link your open sourced work and maybe share tips from your fast Scrabble move finder 😄

[laeuter]

Thanks for your reply.

My point is absolutely not to replace your currently implemented formats. It's just to make it easier to implement additional formats and conduct experiments. If really successful, the code would be so modular that it could be easily mixed and matched.

I have old C code myself, but your code is much faster, and it gave me some nice ideas, so that I would be willing to change over to using your project.

I cannot be called a proficient Rust coder by any means, but I consider myself a good code reader. Your code base and a coding assistant enabled me to implement another format of mine, and it was a nice experience. (That experience doesn't count when it comes to code quality, I would certainly listen to reviews of Rust experts.) By now I have no reason to depart from the Rust implementation.

Perhaps I should go and fork your project, implement my ideas. And if you like some of them, things could become pull requests.

Concerning ideas on my move finder, some ideas are best explained using concrete data, so I come back when I have finished the implementation of the additional formats.