Open Mk-Chan opened 5 years ago
We disagree on where to draw the line, for example I think it's a good idea to at least include parsers for notation like e1h1
and Naxb3
, but a full implementation of the UCI protocol (or XBoard) definitely belongs in a seperate crate. Managing dependencies is much more comfortable with cargo than with pip.
@niklasf now how to communicate with uci chess engines via rust that beautiful way as I did in python chess? Don't want to make all dirty work and parse it myself...
Hey, I just published shakmaty-uci
. It provides an enum (UciMessage
) to write and parse UCI messages to and from the engine. It’s based on/inspired by vampirc-uci but uses Nom for parsing.
It does not (yet) handle actual communication with the engine, but I’ll probably add that in the future.
@niklasf if you’re interested, I started this crate as a module of shakmaty. I think it might be better to have this as a separate library, to not clutter shakmaty (especially if I add engine communication), but I could easily provide a PR if you would be interested in integrating this in your crate.
I can see the point here: https://github.com/jordanbray/chess/issues/6 but it also suggests putting all the engine communication stuff into a different library which I'm not too much a fan of as it may be harder to discover. Is there any consensus on this? I actually would like to help out too but my Rust is not up to the mark yet.